Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Bin mir nicht sicher ob ich hier im richtigen Forum bin, habe schon ein paar Threads gelesen, aber da ging es meist um Synchronisierung.
Meine Frage/Problem:
Ich habe 2 SubVis bei denen ich will, dass sie parallel starten, wenn eines von beiden länger dauert stört mich das nicht, da es eh erst aus der case schleife weiter geht wenn beide fertig sind.
Zumindest gehe ich davon aus, dass es erst dann weiter geht, traue der Highlight Funktion nicht immer...
Insgesamt will ich einfach, dass diese Case schleife so schnell es geht ausgeführt wird, was in meinen Augen dann der Fall ist, wenn die SubVis parallel laufen und nicht, wie bei der Highlight funktion, erst das eine SubVi und dann das andere SubVi ausgeführt wird. Richtig?
Ich hoffe ihr könnt mir helfen, wenn ihr noch Infos braucht gebt bescheid.
Allein vom Datenfluss her können beide VI-Aufrufe parallel laufen. Vorraussetzung ist, dass du dieses VI auch ablaufinvariant (reentrant) einstellst. Aus deiner Beschreibung des Verhaltens beim debugging würde ich aber davon ausgehen, dass du es noch nich so konfiguriert hast. Aus der Case-Struktur geht er erst raus wenn der komplette Inhalt ausgeführt ist, in deinem Fall auch das beide VI-Aufrufe fertig sind.
07.03.2015, 22:01 (Dieser Beitrag wurde zuletzt bearbeitet: 07.03.2015 22:03 von Slev1n.)
danke für die schnelle Antwort.
Ja, während ich hier auf ne Antwort gewartet hab, hab ich noch bissl weitergesucht und das auch gemacht, hab also das SubVi (sind ja beides dieselben) auf AblaufINvariant gestellt. Die Highlightfunktion zeigt es immernoch so an als ob es sukzessiv ablaufen würde, aber vielleicht zeigt sie es einfach nur falsch an.
Hier ein Bild ob alles richtig eingestellt ist?
Gruß Slev1n
07.03.2015, 22:04 (Dieser Beitrag wurde zuletzt bearbeitet: 07.03.2015 22:06 von BNT.)
Hast du eigentlich hier ein Zeitproblem in der Ausführung? Von den gesamten Namen her wird hier scheinbar je ein einzelner CAN-Frame in Signale konvertiert. Das sind Operationen die bezogen auf Systemressourcen und Ausführungszeit quasi zu vernachlässigen sind. Falls hier nicht konkrete Probleme bestehen, würde ich diese noch nichtmal parallel aufrufen.
Alle genannten Optimierungen führen zu bestimmten Einschränkungen (z.B. Debugging nicht mehr möglich etc.) bzw. können bei unsachgemäßer Verwendung Probleme verursachen (Änderung Prioritäten). Mal davon abgesehen, dass der Quellcode damit unnötig an Komplexität zunimmt und die Verständlichkeit leidet.
Die Highlight-Funktion kann aufgrund der Art und Weise der jeweiligen Ausführung ein komplett anderes Zeitverhalten als eine normale Ausführung haben.
08.03.2015, 08:51 (Dieser Beitrag wurde zuletzt bearbeitet: 08.03.2015 08:54 von Slev1n.)
@ holy:
Ich lese einen CAN Bus aus und möchte die Frames mit einer DBC File konvertieren. Da ich als Hardware die USB 8473s Karte habe geht nur FRAME-API und ich nutze außerdem die "conversion-library". Da es unterschiedlich viele Nachrichten IDs geben kann, habe ich auch für 1-3 Nachrichten IDs cases erstellt in denen 1-3 mal parallel dieses Conversion SubVi aufgerufen wird und in jedem subvi ein Frame, mit der jeweiligen Nachrichten ID, konvertiert wird.
Das wäre in meinen Augen schon zeitkritisch, da je länger die Konvertierung braucht umso mehr Frames sammeln sich am Bus bzw. im Read Puffer an. Folglich muss er dann auch wieder mehr Frames nach der jeweiligen ID durchsuchen, weil ich immer alle Frames vom Bus lese, diese Frames alle in ner For Schleife indiziere und nur die mit der passenden ID konvertiere.
@BNT:
Soll ich jedes subvi in eine eigene for schleife packen oder gemeinsam in eine?
Da es vll mal vorkommt, dass es 5 SubVis sind die parallel laufen sollen kann ich denen ja nicht allen einen Prozessorkern zuteilen oder verstehe ich hier was falsch und ihr meint multithreading.
Alle SubVIs in eine For-Schleife, denn die Angabe, wieviele Cores benutz werden sollen, bezieht sich auf den Inhalt der jeweilige Schleife. Wenn es mehr SubVIs sind als Core zur Verfügung stehen, müssen halt einige SubVIs warten.
Anmerkung zur Performance: Wenn ich mich recht erinnere kam der CAN-Bus maximal 1 MBaud. Wie schnell ist Deine CPU?
Ich stimme holy zu. Lass den ganzen Klamauk mit de Performance-Optimierung und vertrau dem LV-Compiler. Wenn Du Zweifel hast, kannst Du ja die Zeiten messen und überwachen. Dann hast Du Klarheit.
Deswegen ja genau meine Frage. In der Theorie ist die Konvertierung zeitkritisch aber ist es denn in der Praxis aktuell ein Problem? Dauert die Konvertierung der Frames denn zu lange? Du has ja sicher auch noch einige andere Aufgaben im Programm zu realisieren. Einige lassen sich davon nicht parallelisieren (Abfrage vom CAN, Weitergabe der Daten in der richtigen Reihenfolge,...). Ich würde schätzen, dass die Konvertierung der Frames wenig Zeit benötigt und der Overhead durch Multithreading den potentiellen Zeitgewinn evtl. sogar ins Gegenteil verkehrt.
Ich würde vorschlagen das du es erstmal ausprobierst und bei Problemen hinsichtlich Parallelisierung optimierst.
Hinsichtlich der For-Schleife bin ich mir nicht sicher was BNT erreichen möchte. Prinzipiell gibt es die For-Schleifen Parallelisierung. D.h. wenn die einzelnen Iterationen keine direkten Datenabhängigkeiten besitzen, werden die einzelnen Iterationen auf mehrere Kerne verteilt. Das würde für deinen konkreten Fall was bringen wenn du N Frames reingibst und dann durchiterierst und durch LabVIEW die Iterationen auf mehrere Kerne verteilen lässt.
Bei einer Schleife mit N=1 erfolgt keine Parallelisierung durch die genannte For-Schleifen Parallelisierung.
For-Schleifen Parallelisierung: @holy Du hast recht. Es war schon spät gestern Abend.
Ich habe dieses Feature noch nicht wirklich benutzt und falsch in Erinnerung behalten.
1 Mbaud ist richtig. Ich bin Student und an meinem PC, der fürs gamen ausgelegt ist, ist das Ganze kein Problem: i5-4670k (3,4GHz). Für das Labor für welches ich diese VIs schreibe vielleicht schon eher. Aber ihr habt recht, erstmal ausprobieren.
Grundsätzlich soll ich nur ein Programm schreiben, dass ohne große Einarbeitungszeit benutzbar ist und Sensorwerte ausliest. Wichtig ist Stabilität und Zuverlässigkeit des Programms, da es vielleicht auch mal über Nacht durchlaufen soll und es zu keinem Überlauf bzw. Datenverlust kommen soll.
Die Ablaufinvarianz sollte kein Problem darstellen oder? Da nicht gerade viel Speicher für dieses SubVi benötigt wird, sollten auch mehrere bereitgestellte Speicherbereiche keine Gefahr sein?
Stimmen diese Aussagen? Ich versuche gleich mal was für die Zukunft zu lernen
Ich versuche gleich mal was für die Zukunft zu lernen