Hallo LabVIEW-Gemeinde!
Anbei eine Prinzipdarstellung meiner Programmstruktur (bitte nicht fragen, geht momentan nicht anders).
Problem: Weder über das Hauptprogramm, noch per SubVI kann ich die Anwendung sauber beenden. Es handelt sich im Grunde um das Problem, wie beende ich 2 Parallelschleifen. Da dies von beiden Stellen möglich sein soll, habe ich mit einer globalen Variable verbunden.
Ich vermute, dass ich an dieser Stelle voll in eine dieser berüchtigten Race Conditions reinlaufe.
Als einzige Lösung zur Problematik schlägt LabVIEW die Verwendung von Funktional Globalen Variablen vor.
Ist das so? Gibt es andere (einfache) Techniken?
Was läuft in meiner Programmstruktur schief?
Zur Erläuterung: Das Programm soll (sauber) schliessen, wenn die globale Variable 'R-Global' FALSE ist, oder wenn beim UDP ein Fehler auftritt (Fehler-Cluster).
'R-Stopp' ist nur eine lokale Hilfsvariable im Hauptprogramm.
Der gestrichelte Draht ist nur eine Idee zur Verschlimmbesserung und noch nicht implementiert.
Wie erreiche ich, dass die beiden Parallelschleifen (Hauptprogramm, SubVI) sauber beenden?
Danke und Gruss!
PS: Das SubVI/UDP-Listen.. soll gewährleisten, dass andere Programmierumgebungen (z.B. Visual Basic) auf die Funktionalität des Hauptprogramms zugreifen können (Remote-Betrieb als Event des Schalters 'Remote' implementiert).
Hallo nurso,
Zitat:Das Programm soll (sauber) schliessen, wenn die globale Variable 'R-Global' FALSE ist, oder wenn beim UDP ein Fehler auftritt (Fehler-Cluster).
Du verknüpfst deine Bedingungen komisch:
- "R-Global" soll FALSE sein für einen Abbruch
- Der Fehlercluster soll TRUE sein für einen Abbruch
- beides wird OR-verknüpft und auf ein Stopp-Terminal geführt, welches bei TRUE die Schleife beendet (wenn ich dein Bild richtig deute)
Vielleicht solltest du entweder R-Global invertieren oder deine logische Verknüpfung anpassen!?
Wo wird "R-Global" initialisiert?
Wo wird "R-Global" gesetzt?
(01.09.2015 13:13 )GerdW schrieb: [ -> ]Du verknüpfst deine Bedingungen komisch:
- "R-Global" soll FALSE sein für einen Abbruch
- Der Fehlercluster soll TRUE sein für einen Abbruch
- beides wird OR-verknüpft und auf ein Stopp-Terminal geführt, welches bei TRUE die Schleife beendet (wenn ich dein Bild richtig deute)
Vielleicht solltest du entweder R-Global invertieren oder deine logische Verknüpfung anpassen!?
Wo wird "R-Global" initialisiert?
Wo wird "R-Global" gesetzt?
>>>
Es ist nur eine Prinzipdarstellung, was nicht besonders praktisch ist. Ich sehe es ein.
Muss dringend eine Internetverbindung einrichten :/
<<<
R-Global ist selbstverständlich invertiert, bevor der Wert in die ODER-Verknüpfung geht.
R-Global wird mit FALSE zu Beginn der Hauptanwendung initialisiert.
Schaltverhalten ist 'Beim Drücken schalten' (oben links in der Auswahlmatrix).
R-Global ist im Hauptprogramm direkt mit dem Schalter auf dem Frontpanel verbunden, wird dort gesetzt. Daher auch die While-Schleife im Event [Remote], um den Zustand zu checken.
R-Global wird im SubVI per UDP-Befehl String:"Stopp" gesetzt. Die While-Schleife des SubVI rauscht ohne zusätzliches Timing durch.
Die Vermutung mit der verletzten Race Condition habe ich, da bei aktiver Highlight-Funktion der Abbruch funktioniert.
Vom Gedanken her wollte ich eigentlich erreichen, dass immer erst die While-Schleife im SubVI beendet wird und dann der Event-Case verlassen.
1. Fall: UDP fordert stoppen -> SubVI endet, über lokale Variable R-Stopp wird Event-Case verlassen
2. Fall: Remote-Schalter wird FALSE -> SubVI endet, über lokale Variable R-Stopp wird Event-Case verlassen
Hallo nurso,
Zitat:Es ist nur eine Prinzipdarstellung, was nicht besonders praktisch ist. Ich sehe es ein.
Oder du solltest gleich besser erläutern.
Inzwischen wird das Bild klarer…
Zitat:R-Global ist im Hauptprogramm direkt mit dem Schalter auf dem Frontpanel verbunden, wird dort gesetzt.
R-Global wird im SubVI per UDP-Befehl String:"Stopp" gesetzt.
Klassische Race-Condition: zwei Instanzen versuchen, eine Variable unabhängig voneinander zu setzen. Schlecht. Ganz schlecht!
Zitat:Die While-Schleife des SubVI rauscht ohne zusätzliches Timing durch.
Ganz ganz schlecht. Da wird die globale Variable andauernd (im ns-Takt) geschrieben - und du wunderst dich über Probleme…
Zitat:Daher auch die While-Schleife im Event [Remote], um den Zustand zu checken.
Ach, das sollte eine Event-Struktur sein? Das solltest du aber dazu sagen…
Wieso sind da lang laufende Schleifen in einer Event-Struktur? Sowas gehört sich nicht!
Auf was hört das Event? Sind nachfolgende UI-Events durch den Event-Case blockiert?
Zitat:Muss dringend eine Internetverbindung einrichten
Ja, dann könnte man sich einiges an diesem Frage-Antwort-Spiel ersparen…
(Manche fügen ja wenigstens "echte" Bildschirmfotos hier an.
)
Oje.. jetzt bemerke ich eine Schwierigkeit, die dann am Ende doch nichts mit Race Condition zu tun hat?!?!??
Im SubVI wird nicht-signalisierend gesetzt bzw. die globale Variable 'R-Global' ist keinem Event-Case zugeordnet.
Beende ich im Hauptprogramm per Schalter, dann rufe ich ja schon wieder erneut den Event-Case [Remote] auf, den ich eigentlich verlassen will
Das muss irgendwie anders....
Sollte Schluss machen für heute.
PS: Höchstwahrscheinlich hast Du mit den "ganz ganz schlecht" Einwänden recht, dennoch geht es im 1. Ansatz darum, richtig auf die Beenden-Aktion zu reagieren. Und zwar entweder per Knöpfen im Hauptprogramm oder per Stopp via UDP. Dass dies gleichzeitig geschieht kann ich für den Moment ganz klar ausschliessen.
PPS: Die globale Variable 'R-Globale' wird nur dann im SubVI gesetzt, wenn der Befehl-String Stopp durchs UDP rauscht (nicht zu sehen; Prinzipdarstellung^^)
PPPS: Das komplette Hauptprogramm ist im Event 'Remote' blockiert. Das soll auch so sein, denn der Remote-Betrieb ist an eine andere Anwendung abgegeben worden (SubVI/UDP als einzige Schnittstelle). Nur noch der 'Remote-Button' auf dem Frontpanel ist freigegeben und wird alle 40ms abgerufen.