Sub-VIs in Subpanel laden

Hallo liebe LV-Gemeinde,

ich sitze gerade an einem größeren Messaufbau, für den ich schon einige VIs geschrieben habe, die alle für sich eigenständig funktionieren, genauer gesagt, sie haben alle irgendwelche While-Schleifen, Stop-Tasten, Eventstrukturen, Visa-Anweisungen und Fehlercluster.
Jetzt würde ich diese VIs gerne in ein großes main.vi packen, damit man sie nicht immer alle einzeln öffnen und schließen muss. Das Problem ist nämlich, dass die meisten VIs nicht gleichzeitig laufen dürfen, da sie auf den gleichen COM-Port zugreifen.
Daher würde ich gerne eine große Registerkarte aufmachen und die einzelnen VIs dort in Subpanel setzen.
Leider fehlt mir aber anscheinend noch das richtige KnowHow um mit VI-Referenzen und VI-Aufrufen umzugehen.
Geladen werden die VIs zwar, aber ich kann nicht wirklich auf sie zugreifen. Außerdem denke ich, dass das VI auf einer Registerkarte einfach weiterläuft, auch wenn ich eine andere Registerkarte anklicke und das soll es ja eben nicht machen.
Ich hab schon versucht alle anderen VIs mittels Methodenknoten abzubrechen bevor ich in einem bestimmten Case ein neues VI lade, aber das gab nur Fehlermeldungen.

Ich hab mal exemplarisch drei kleine VIs erstellt, die das Problem verdeutlichen sollen. Meine eigentlichen VIs darf ich leider nicht hochladen.

Meine konkrete Frage lautet also: wie schaffe ich es, jeweils nur ein VI auf einer Registerkarte laufen zu lassen und dieses VI abzubrechen wenn ich eine neue Registerkarte anwähle?

Dein Ansatz ist IMHO einerseits zu kompliziert, andererseits zu einfach.

Zu kompliziert ist die Verwendung mehrerer Subpanels. Wenn sowieso zwecks Zugriff auf dieselben Hardware-Resourcen immer nur 1 VI laufen darf, dann nimm nur 1 Subpanel, dann bist du an dieser Stelle schon auf der sicheren Seite. Der NI Example Finder liefert hierzu ein gutes Beispiel, den "Subpanel Viewer.vi" ( LabVIEW xxx\examples\general\controls\subpanel.llb\Subpanel Viewer.vi ). Schau dir dieses Beispiel an, dann solltest du schon deutlich weiter kommen als wie bisher.

Andererseits ist es bei dir zu einfach, genauso vorzugehen wie im gerade beschriebenen Beispiel. Dort wird das gerade laufende VI gnadenlos abgebrochen. Das dürfte bei dir nicht so gut sein. Im einfachsten Fall bleibt nur die VISA-Schnittstelle offen und das nächste VI kann sie dann beim Starten nicht öffnen. Du brauchst also noch ein Konzept, wie die deinen Subpanel-VIs Kommandos schicken kannst (wie z.B. Beenden o.ä.). Und erst wenn das entsprechende VI beendet ist, erst dann darf das nächste Subpanel-VI gestartet werden.

Gruß, Jens

Hi,

großen Dank schonmal für den Tip. Das Beispiel VI entspricht genau dem was ich gesucht habe. Nur leider klappt es bei mir nicht genauso.
Ich habe lediglich den Methodenknoten zum Abruch der VIs geändert. Hier verwende ich jetzt anstatt "VI abbrechen" "Elementwert festlegen" und übergebe an den Quitbutton meiner VIs ein True.
Damit das vor dem Aufruf des nächsten VIs passiert, habe ich noch einen Fehlercluster und Wartezeit gelegt.

Allerdings bekomme ich beim Starten des VIs zuallererst eine Fehlermeldung, dass die VI-Referenz ungültig ist. Wenn ich dann auf "Weiter" klicke läuft das VI weiter und ich kann 2 von den 3 Sub-VIs bedienen. Das VI, welches aber beim Starten in der Case-Struktur ins Subpanel geladen werden sollte, läuft gar nicht mehr, bzw. lässt sich nicht bedienen.

Hab das mit allen drei Sub-VIs beim Starten probiert..

Komisch, dass es bei dem LabView Beispiel keine Fehlermeldung am Anfang gibt.

Was mach ich falsch?

Hier nochmal das main.vi allerdings leider ohne sub-VIs



sry, weiß nich genau, ob in dieser version die wartezeit schon vorhanden ist. sollten aber 200 ms zwischen liegen..

THINK Dataflow:
Auch im Init-Fall (also bei Start deines VIs) versuchst du, einen Quit-Button zu setzen, gehst aber hier mit einer ungültigen VI-Referenz an die "Elementwert setzen" Methode. Folge: Es kommt ein Fehler zurück, und diesen Fehler gibst du jetzt an die "Run-VI" Methode weiter. Somit wird diese Methode nicht ausgeführt.

Lösung:
1) bei ungültiger VI-Refnum erst gar nicht die "Elementwert setzen" Methode ausführen.
oder
2) einfach ein Clear Error nach "Elementwert setzen"
oder oder oder....

Gruß, Jens

Hallo Scuba,

Zitat:Was mach ich falsch?

Du hast nicht mal grundlegendes Debugging betrieben!

Nach einem schnellen Blick: in der ersten Iteration arbeitest du mit einer generischen Referenz. Auf welche FP-Elemente willst du da zugreifen?
Vielleicht wäre es doch besser, erst einmal eine VI-Referenz zu öffnen, bevor man damit arbeiten will!
Oder alternativ auf eine gültige Referenz prüfen!
Oder alternativ den Fehler programmatisch abfangen…

Alles Klar! Vielen Dank für die schnellen Antworten!!

Ja hatte mir schon gedacht, dass das an der generischen Referenz am Anfang liegt. Aber drauf spekuliert, dass der folgende Mtehodenknoten dann einfach "ignoriert" wird wie beim LV-Beispiel VI. Außerdem hats mich gewundert dass die Referenz dann auch komplett ungültig bleibt, obwohl ja eigentlich bei jedem Case-Wechsel eine neue Refernez generiert wird..

Na wie auch immer. Habs jetzt mal mit Fehler löschen gemacht, obwohl das wahrscheinlich nicht die eleganteste Lösung ist ^^

Also vielen Dank nochmal für die Tipps! Klappt super!

Zumindest auf meinem Laptop....der Laborrechner, der schon ein paar Jahre auf dem Buckel hat, geht schon ziemlich in die Knie...

Kanns sein, dass die Sub-VIs mit dem Subpanel-Aufruf extrem viel Arbeitsspeicher fressen?

Anzeige

Hallo Scuba,

dein MainVI ist es jedenfalls nicht, was die Rechenlast verursacht: 100ms Wartezeit, wenn nichts passiert und 500ms, wenn etwas gemacht werden soll…

Wie sieht es mit der Prozesorlast aus, wenn du nur das Subpanel VI auf deinem Labor Rechner ausführst? Wie Gerd schon sagt, das Subpanel selber ist nicht die Ursache.

Gruß, Jens

Ja die 500 ms waren nur zu Testzwecken. Werd das noch runter schrauben. Aber will natürlich sicherstellen, dass alle VISA-Schnittstellen richtig geschlossen werden und noch alle Berechnungen nach den Hauptschleifen durchgeführt werden.
Wär wahrscheinlich auch keine schlechte Idee open und close VISA ebenfalls ins main.vi zu verlagern. Dann kann ich die Sub-VIs aber nicht mehr unabhängig verwenden, bzw. muss mir nochmal eigenständige Versionen erstellen.
Kann es sein, dass sich die Schleifen des main.vi und die Schleifen des sub.vi gegenseitig ausbremsen, bzw. überlagern. Die laufen ja dann parallel..

Prozessorlast der Sub-VIs alleine ist deutlich geringer. Aber die werden ja normalerweise auch nur einmal in den Speicher geladen und verbleiben da erstmal.
Kann auch sein, dass ich mich grad einfach zu wild durch die einzelnen Panels geklickt hab und der Prozessor das dauernde Öffnen und Schließen nicht mochte

(27.08.2014 14:28 )Scuba schrieb:  Ja hatte mir schon gedacht, dass das an der generischen Referenz am Anfang liegt. Aber drauf spekuliert, dass der folgende Mtehodenknoten dann einfach "ignoriert" wird wie beim LV-Beispiel VI.

Im Beispiel wird der Fehler nach Close Refnum aber auch nicht weitergeführt...

(27.08.2014 14:28 )Scuba schrieb:  Außerdem hats mich gewundert dass die Referenz dann auch komplett ungültig bleibt, obwohl ja eigentlich bei jedem Case-Wechsel eine neue Refernez generiert wird..

Aber durch deine Fehlerweiterführung (in diesem Fall war der Datenfluss einmal störend) wurde die VI-Refnum beim Aufruf ungültig...

(27.08.2014 15:38 )Scuba schrieb:  Ja die 500 ms waren nur zu Testzwecken. Werd das noch runter schrauben. Aber will natürlich sicherstellen, dass alle VISA-Schnittstellen richtig geschlossen werden und noch alle Berechnungen nach den Hauptschleifen durchgeführt werden.
Wär wahrscheinlich auch keine schlechte Idee open und close VISA ebenfalls ins main.vi zu verlagern.

Dann erstelle dir eine saubere Kommunikation zwischen Main-VI und deinen Subpanel-VIs, z.B. über Queues oder Notifiers.
Deine Subpanel-VIs könnten z.B. über eine Queue melden, wenn sie beendet sind. Darauf wartest du im Main-VI (anstatt der 500 ms) und dann geht es weiter mit dem Wechsel im Subpanel.

Gruß, Jens