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!
Wenn auf einem Blockdiagramm mehrere SubVIs sind, zwischen welchen keinerlei Abhängigkeit besteht, wird dann trotzdem eines nach dem anderen ausgeführt, oder kann es auch sein, dass sie quasi parallel abgearbeitet werden?
Das ist ja genau das Prinzip des Datenflusses.
Sobald an allen Eingängen eines SubVIs Werte anliegen, wird es ausgeführt. Bei Multicore-Prozessoren z.T. richtig parallel.
Das gefällt mir so an LabVIEW: LabVIEW verteilt parallel ausführbaren Code selbstständig auf mehrere Prozessoren (sofern vorhanden) und synchronisiert die Daten wieder, sobald sie zusammen laufen.
Wenn ich da an Programmiersprachen wie C denke, wo das richtig aufwändig ist und manuell synchronisiert werden muss, ist das in LabVIEW schon klasse.
Aber genau das birgt eben auch Risiken (z.B. Race Conditions).
Grüße
26.01.2011, 09:51 (Dieser Beitrag wurde zuletzt bearbeitet: 26.01.2011 09:52 von luke.)
darf ich hier noch einmal einhaken und eine kleine Verständnisfrage stellen?
Ich muss mich mit einem Messgerät herum schlagen, dass eine ziemlich lange Latenzzeit hat vom Kommando "messe jetzt" bis ein Messwert zurück gegeben wird. Da mir das mein ganzen Programm welches schon eingermaßen gut getimed arbeiten soll, habe ich ein davon unabhängiges VI erzeugt, welches das Messgerät ausliest und das Resultat alle 5 Sekunden in eine globale Variable legt. (getaktet mit dem Metronom). Dieses VI läuft nun fröhlich munter vor sich hin, da ich es einfach in meinem Hauptprogramm starten möchte (Dieses muss mit 0,1s Auflösung laufen). Jetzt habe ich das Problem, dass all dies auf einem Kern läuft und das obwohl das VI eigentlich immer nur Däumchen dreht diesen Kern restlos auslastet und das gesamte Programm fürchterlich hakt wenn es läuft. Darum würde ich gerne das SUB-VI so konigurieren, dass es Multicore läuft. Meine Frage: Führt dies zu Problemen bei meinem Datenübergabekonzept? Oder gibt es vielleicht ein noch clevereres Konzept?
Hier ist noch eine Abbildung meiner VI-Hierarchie.
Viele Grüße
Lukas
PS: Labview 2009 auf Corei5 mit HT, einige VIs in dieser Darstellung sind nicht gefunden worden. Das liegt aber daran, dass ich auf meinem Laborrechner kein Internet habe und das VI auf einer anderen Installation gescreenshottet habe
26.01.2011, 13:40 (Dieser Beitrag wurde zuletzt bearbeitet: 26.01.2011 13:41 von aptiva.)
Ich kenne dein Programm jetzt leider nicht genau. Was spricht denn gegen eine parallele Schleifenstruktur, in der du in der einen Schleife nur das langsame Messgerät abfragst und die Werte in eine Funktionale globale Variable (FGV) schreibst und in der anderen Schleife das eigentliche Programm läuft. Die Schleife in der das eigentliche Programm läuft kann dann bei Bedarf die FGV abfragen. Somit laufen diese beiden Schleifen mit einer unterschiedlichen Geschwindigkeit.
Bsp. zu Funktionalen Globalen Variablen findest du im Forum
evlt. kannst Du das Verhalten verbessern, wenn Du die verschiedenen Aufgaben gezielt in unterschiedliche Ausführungssysteme legst.
In den VI-Eigenschaften unter "Execution" kannst Du das "Preferred Execution System" für jedes VI auswählen.
Als Default steht hier "same as caller", was dazu führt, dass alle VIs eines typischen Programms im gleichen Execution System laufen.
Probier doch mal aus, ob es besser wird, wenn Du Dein Mess-VI z.B. zu "instrument I/O" zuordnest.
Die Namen der Execution Systems haben übrigens nichts weiter zu sagen (sind nur als Anregung gedacht). Einzige Ausnahme: "user interface". Das ist der UI-Thread von LabVIEW, der in vielerlei Hinsicht eine Sonderrolle einnimmt.
Anzeige
27.01.2011, 10:34 (Dieser Beitrag wurde zuletzt bearbeitet: 27.01.2011 10:36 von IchSelbst.)
' schrieb:restlos auslastet und das gesamte Programm fürchterlich hakt wenn es läuft.
Wenn dein Programm (siehe Taskmanager) 100% CPU-Leistung (oder bei vier Kernen 25%) - dann hast du einen grundsätzlichen Struktur-Fehler.
LV-Programme, egal wie sie aufgebaut sind, brauchen normalerweise maximal 10%. Dabei ist es ganz egal, wie viele SubVIs verwendet werden etc. Der von dir beschriebene Fehler tritt auf, wenn du eine Dauerschleife ohne Wartezeit programmierst.
Nachtrag:
Dumm wäre natürlich, wenn einer der DLL-Aufrufe (??) eine Dauerlast verursachen würde.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
@ aptiva:
Das hatte ich auch zuerst realsiert. Mein Problem ist, dass mein Programm sehr zeitkritisch präzise zwischen 4 Zuständen nacheinander wechseln muss. Dazu stecken 4 dieser Doppelschleifenkonstruktionen in einer Case-Struktur. Die "schnelle" Schleife terminiert sich dazu problemlos. Die langsam verzögert den Wechselprozess leider zu lange. Daher meine Idee mit dem neuen VI. Vermutlich ist dieses Konstrukt an sich nicht sehr clever und ich sollte die Abläufe besser durch den Datenfluss an sich regeln. Nichts desto trotz habe ich diese Option für meine speziellen Bedürfnisse derzeit nicht erkannt.
@RHeil:
Das klingt sinnig. Ich werde es morgen sofort testen.
@IchSelbst:
Das ist mir bekannt. Meine sämtlichen Schleifen haben alle ein Metronom drin. Die schnelle Schleife hat 100ms, die langsame sogar 5000. Daher kann ich mir das ganze überhaupt nicht erklären. Mehr Schleifen sind nicht im Spiel.
' schrieb:LV-Programme, egal wie sie aufgebaut sind, brauchen normalerweise maximal 10%. Dabei ist es ganz egal, wie viele SubVIs verwendet werden etc. ...
Öhm... bitte was? Schlechte Programmierung kann zu (unnötig) hoher CPU-Last führen.
Der Umkehrschluss ist aber schlicht quatsch. Klar kann man komplexe Aufgaben (im Sinne von Komplex wie in Komplexitätstheorie) auch so tunen, daß sie nur 10% CPU-Zeit auf einem Zielsystem brauchen, die Verabeitungszeit wird dann halt entsprechend lang.
Zitat:@ aptiva:
Das hatte ich auch zuerst realsiert. Mein Problem ist, dass mein Programm sehr zeitkritisch präzise zwischen 4 Zuständen nacheinander wechseln muss. Dazu stecken 4 dieser Doppelschleifenkonstruktionen in einer Case-Struktur.
Na ja so meinte ich das auch nicht, weil damit du in dem Fall einen Case weiter springen kannst, müssen beide Schleifen beendet sein. Ich meinte zwei+n "unabhängige" Schleifen, wie zum Beispiel bei der Erzeuger-Verbraucher-Struktur. Kannst du das eine Messgerät nicht die ganze Zeit abfragen und die Daten über eine FGV nur abfragen, wenn du diese brauchst?
