While-Schleife aus zweiter Schleife steuern

Hallo Labview-Forum!

Da dies mein erster Beitrag ist, kurz etwas zu mir. Ich bin Maschinenbau-Student und hatte bisher nicht viel mit Labview zu tun. Da Labview aber häufig bei Mess- und Regelanwendungen zum Einsatz kommt, dachte ich mir ich erweitere mein Wissen indem ich eine Projektarbeit wähle, die mit Labview zu tun hat.

Leider besteht das Projekt darin, mehrere bestehende Labview-Vi's (die einzeln für dich einigermaßen funktionieren) in einem Programm zusammen zu fassen. Ich hab nun bereits viel gelesen und ausprobiert und mir eiige Basics anzueignen. In der Denk-Struktur von Labview bin ich leider noch nicht wirklich drin (Komme eher aus dem C bzw. Visual Basics Bereich).

So, nun aber mal zu meinem Anliegen. Problem das ich habe ist, dass durch die verschiedenen Vis mehrere While-Schleifen in SubVis parallel laufen müssen (zb zur Datenerfassung per RS232 Schnittstelle).

Habe auch bereits einiges zum Thema Datenaustausch zwischen While Schleifen gelesen. Stichpunkte Globale Variablen, Notifier oder Queues.

Die Messwerte kann ich ganz gut per globaler Variable übergeben.
Was ich nun gerne erreichen möchte ist, dass ich die Elemente meines SubVis (Buttons, Schalter usw) aus meinem Main-Vi steuern kann. Macht man das auch per Queues? Habe zwar verstanden wie eine Nachricht übermittelt wird, aber wie diese Nachricht dann einen zb Button auslöst, hab ich noch nicht verstanden.

Um zu verdeutlichen was ich versuche, habe ich mal ein ganz primitives Beispiel in LV2014 erstellt. Im Subvi zählt ein Zähler hoch, wenn ein Schalter "Ein" ist. Der Wert wird per Globaler Variable an an des Main Vi Übertragen.

Wie erreiche ich es nun, mit einem Schalter im Main-Vi den Schalter im Sub-Vi zu betätigen und den Zähler zu aktivieren??? (Stop Bedingungen sind zwecks Einfachheit nicht verknüpft.)

Steh ich nur gedanklich auf dem Schlauch oder geht das so in Labview nicht. Wie würde man so etwas elegant lösen ??
Bitte nicht zu hart sein zu einem Labview-Anfänger

Danke schon mal für eure Hilfe und viele Grüße

Philipp


  MainVi.vi (Größe: 8,71 KB / Downloads: 222)

  SubVi - mit While-Schleife.vi (Größe: 9,11 KB / Downloads: 226)

  Globale-Variablen.vi (Größe: 4,1 KB / Downloads: 212)

Anzeige

Moin Philipp,

eigentlich mag ich keine Quick-n-dirty-antworten. Aber weil immer noch keiner geantwortet hat, kriegste jetzt trotz akuten Zeitmangels eine Antwort. Nur eben "kurz" und ohne Beispiele.

Bei Meldern und Queues kannst Du über VI-Grenzen hinweg die Daten in Schleifen reinbringen, wenn Du
a) im übergeordneten VI den Melder / die Queue definierst und die "Leitung" danach auf verschiedene VIs verteilst. (Die Frontpanel-Elemente dazu kannst Du am besten im Blockdiagramm mit Rechtsklick auf die Anschlüsse erzeugen. Dann "passt" gleich alles.) oder
b) in allen VIs denselben Namen vergibst.

"Aktionen" lassen sich per Melder übergeben, indem auf der anderen Seite auf eine neue Nachricht gewartet wird. Und solange passiert dann nichts.

Stop-Funktionen werden üblicherweise durch löoschen von Queue/Melder und Auswertung des Error-Anschlusses bei den übrigen Teilnehmern realisiert. Dazu gibt es auch schöne mitgelieferte Beispiele.

Eine weitere Möglichkeit wäre, die Referenzen von den betreffenden Bedienelementen zu übergeben. Dann hast Du quasi vollen Zugriff auf alles was Du auch im Ursprungs-VI mit den Bedienelementen machen kannst.
Für die verarbeitung in Ereignis-Strukturen musst Du sie aber zuerst an dem entsprechenden Erignis-Struktur-Anschluß "registrieren". Die Hilfe hilft dabei ;-)

Hth

Kleine Ergänzung zum Thema Datenübergabe:
Selbst innerhalb eines VIs, also bei der Datenübergabe von einer in eine andere Schleife, sind globale oder lokale Veriablen keine gute Idee.
Denn wenn Du denkst, die Schleifen synchronisieren sich, in dem Du dieselbe Wait-Zeit in beiden Schleifen vorgibst, so irrst Du dich. Die Waits sind nur auf 1ms genau, außerdem kommt es zu zusätzlichen Unterbrechungen, da Windows kein Echtzeitsystem ist. Es werden also Werte doppelt gelesen oder es gehen Werte verloren, ohne dass Du das merkst.
Theoretisch kann man sich natürlich ein Handshake-System ausdenken, damit so etwas nicht passiert. Praktisch aber wird man das nicht machen - denn es gibt ja die Queues, mit denen das Problem ideal gelöst ist.

Hingegen wenn es nicht so auf Synchronisation ankommt, Starten and Stoppen eines Sub-VIs, oder um irgendwelche Einstellungen zu verändern - da sind lokale/globale Varable schon eher geeignet.

Gruß Ludwig

Hallo Labview-Forum,

ich hatte in diesem Beitrag bereits mein Problem geschildert und nach weiterem rum probieren habe ich entschieden doch noch einen Schritt zurück zu gehen.
Noch mal in kürze: Ich soll an der Uni mehrere Vi's zu einem großen Programm zusammen fügen. Leider bin ich ziemlicher Labviewneuling und der Datenaustausch über mehrere While-Schleifen hinweg ist für mich noch ziemlich undurchsichtig. Gelesen über Globale Variablen, Notifier und Queues hab ich schon viel. Nur das Verständnis wann ich am besten was anwende konnte ich noch nicht gewinnen. Darum auch der Schritt zurück um euch zu fragen, welche Programm-Struktur für mich die sinnvollste wäre. Dazu stell ich kurz dar, was mein Programm im Endeffekt tun soll und was ich mir dazu bereits überlegt habe bzw. wo meine Probleme sind.

Programmfunktionen (Hauptfunktionen):

1. Steuerung der Oberfläche
- Nicht immer soll alles angezeigt werden.
- Anzeige- und Bedienelemente sind auf verschiedenen Tabs angeordnet, die per Button geschaltet werden

2. Aufnahme von Daten über den Serial-Port im 50Hz / 100HZ / 500Hz / 1000Hz (Frequenz einstellbar)
- Genaue Initialisierungsstruktur notwendig für die Kommunikation mit einer Maschine
- Verarbeiten der Daten und Anzeige von verschiedenen Informationen
- Einige Bedeinelemente um Daten zu bearbeiten
- Bei Bedarf speichern der Daten
Diese Funktion soll ständig geschehen, egal welche sonstigen Programmfunktionen aktiv sind

3. Anzeigen eines Kamerabildes
- Nach Bedarf anzeige eines Kamerabildes und Verarbeitung der Daten
- Wieder mit einigen Anzeige und Bedienelemente

So, das sind mal die Hauptfunktionen. Nach dem studieren von etlichen Tutorials und Labview-Büchern seh ich leider den Wald vor lauter Bäumen nicht. Was wäre jetzt eine gute Struktur das Programm auf zu bauen??

Ideen zur Umsetzung:

Drei parallele While-Schleifen, wo die Bedienelemente auf dem Frontpanal frei positioniert werden
Probleme
- Synchronisierung der Schleifen
- Frage ob man Bedienelemente so frei Positionieren kann

Übergeben alle Daten per Globaler Variable
- Auch hier synchronisationsproblem
- Ich kann mir nicht vorstellen das 20-30 Elemente in der Globalen Variable effizient sind

Synchronisation und Datenübermittlung mittels Notifiern und Queues
- Problem: Struktur wird nur ausgeführt, wenn sich was ändert. Es müssen aber immer die Daten am Com-Port empfangen werden
( würde man dazu die Queue in bestimmten intervallen automatisch auslösen ? )

Sorry für die vielen Fragen und den vielen Text. Ich hab leider die Arbeitsweise von Labview noch nicht richtig verstanden. Habe sonst nur kleinere Programme in C oder VisualBasic geschrieben.

Vielen Dank für eure Hilfe und liebe Grüße

Philipp

Hallo ihr beiden,

danke euch für die Antworten.

Leider bin ich auch mit eurer Hilfe nur noch verwirrter. Hab mich daher entschieden, noch einen Schritt zurück zu gehen und euch erstmal um Hilfe bei dem grundsätzlichen Aufbau für mein Programm zu bitten. Ich habe dafür hier einen neuen Beitrag erstellt. Sollte das nicht in Ordnung sein, kann ein Moderator auch die beiden Themen zusammen legen.

LG Philipp

Edit GerdW: Themen zusammengefügt!

Hallo Philipp,

Zitat:Ich hab leider die Arbeitsweise von Labview noch nicht richtig verstanden.

THINK DATAFLOW!
Dazu gibt es ein Kapitel in der LabVIEW-Hilfe (s. Links in meiner Signatur)!

DATAFLOW:
- Ein Node (Funktion/Programmteil/Code-Struktur) wird ausgeführt, wenn die dafür nötigen Daten bereitstehen.
- Nodes ohne Datenabhängigkeit werden parallel ausgeführt.

Anzeige

Moin Philipp,

wieder nur schnell (immer noch im Stress) zwei Tipps....

Ein allgemeiner:
Teste und verstehe das Verhalten erstmal mit einfachen Test-VIs! Also keine Kamera, keine serielle Kommunikation, sondern nur der "interne" Datenaustausch.
Datenquelle kann ein Zufallsgenerator, ein Iterationszähler oder z.B. ein Bedienelement sein. Ggf. die Debugging-Funktion (Glühbirne im Blockdiagramm) einschalten.
Dann erstmal testen was wie wo welche Daten überträgt. Bedienelemente die irgendwelche Aktionen auslösen kommen in eine Eventstruktur in einer eigenen Schleife.

Genauso "unabhäng" die anderen Sachen (Kamera, RS232, ... testen) und erst nachdem(!) verstanden ist wie alles zusammenhängt, die endgültige Programmstruktur entwerfen.

Dann noch speziell zu den Tabs:
Der aktuell gewählte Tab kann auch programmatisch abgefragt werden, so dass beim Umschalten wiederum Aktionen ausgelöst werden könnten.
Wenn Du Bedienelemente hast die auf allen Tabs erscheinen sollen (z.B. Stop-Taste), müssen diese erstmal neben der Struktur platziert werden und dann mit den Cursortasten (nicht mit der Maus!) auf die Tab-Fläche geschoben werden.

Gruß,

* mario *

So, ich hab mal versucht eure Tipps umzusetzten und alle heruntergebrochen auf simple Aufgaben.
Dazu hab eine Event-Driven State Machine konstruiert und mal das VI angehängt.

Meine Fragen dazu:

Ist dieses Grundgerüst geschickt gewählt oder sollte man die Serielle Schnittstelle (Hochzählen) besser als eigene While-Schleife laufen lassen?
Können Werte verloren gehen wenn andere States auf der Queue liegen? Vermutlich nicht, da die Serielle-Schnittsteller eher langsam ist und auf einer Queue keine Werte überschrieben werden.

Müssen alle Bedienelemente in der Eventstruktur positioniert sein?
Also wann positioniert man ein Bedienelement in der Eventstruktur und wann nur als normales Bedienelement in der entsprechenden Case-Struktur ? (s. Umschalter addieren/ multiplizieren)


Danke für eure Hilde und viele Grüße

Philipp

Moin,

im Prinzip sieht das schonmal ganz gut aus. Nur wird die untere Schleife den Case Serial-Port Run immer wieder aufrufen, weil sie den Befehl ja selber immer wieder in die Queue schreibt.

Ausserdem reicht es, die Queue nur hinter der oberen Schleife zu löschen. Die grüne Error-Leitung kannst Du unten auch direkt an den roten Punkt für's Schleifenende anschließen.

Etwas aufpassen musst Du, wenn Du an Ausgangstunnel Defaultwerte verwendest. Das sind dann nicht(!) die Werte am Eingangs-Pendant, sondern die ganz allgemeinen Default-Werte (Null bei Zahlen, leerer String, leeres Array etc.)
Man muss dann nicht zwingend alle Tunnel in allen Cases "durchverdrahten" aber zumindest diejenigen bei denen "ordentliche" Werte am Ausgang notwendig sind.

Für eine begrenzte Auswahl von Befehlen ist es recht komfortabel keine Strings zu verwenden, sondern "Enums". Die findest Du bei den Bedienelementen fürs Frontpanel und kannst sie von dort aus auch als Konstante ins Blockdiagramm kopieren. Das vermeidet Schreibfehler und bei der Case-Auswahl gibt es automatische Vorschläge.

Noch komfortabler wird es wenn man aus dem Enum eine Typdefinition macht. Denn dann werden etwaige Änderungen automatisch an allen Stellen übernommen. Aber das kannst Du Dir auch für "später" aufheben.....


Zu Deinen Fragen:

- die Queue vergisst prinzipiell nichts... das kann aber ggf. zu Überläufen oder seltsamen Wartezeiten führen

- In die Eventstruktur gehören alle Bedienelemente die ein Event auslösen sollen ;-)
Das kann auch bei Feldern mit irgendwelchen Werten der Fall sein (z.B. "Sollstrom") muss aber nicht. Wenn nicht auf eine Wertänderung, auf anklicken o.ä. reagiert werden muss, gehört es nicht in die Eventstruktur (z.B. ein Namensfeld oder Dein Umschalter).

- als Faustformel für eigene Schleifen würde ich sagen, alles was Verzögerungen verursachen kann (z.B. Benutzereingaben) oder zeitkritisch ist (z.B. Messwerterfassung) kommt in unabhängige Schleifen und wird mit Queues, Meldern etc. synchronisiert.
Alle übrigen Sachen "dürfen" zusammen abgearbeitet werden.

Hi Mario,

Zitat:Für eine begrenzte Auswahl von Befehlen ist es recht komfortabel keine Strings zu verwenden, sondern "Enums".

Enums hatte ich auch verwendet. Nur wenn ich dann einen case hinzugefügt oder entfert habe, gingen alle verbindungen zu den enqueue Elementen verloren. Darum dann die Lösung über einen string. Die Typdefinition der Enums scheint da der Tipp zu sein. Das werd ich noch mal versuchen.

Zitat:Etwas aufpassen musst Du, wenn Du an Ausgangstunnel Defaultwerte verwendest.

Ja, das hab ich schon gemerkt . Aber bei meinem ganzen geteste hat mir das erstmal so gereicht. Habs aber im Hinterkopf.

Zitat:Nur wird die untere Schleife den Case Serial-Port Run immer wieder aufrufen, weil sie den Befehl ja selber immer wieder in die Queue schreibt.

Genau das ist der entchiedende Punkt. Ich brauch ja eine Struktur, die automatisch immer wieder aufgerufen wird, um die Daten über die Serielle Schnittstelle zu empfangen.
Ist es nun sinnvoller dies mittels des Eigenaufrufes zu lösen oder ist es besser eine ganz normale while-schleife parallel laufen zu lassen?
Oder gibt es noch eine weitere Möglichkeit ?

Gruß Philipp