LabVIEWForum.de - Programm hängt sich auf

LabVIEWForum.de

Normale Version: Programm hängt sich auf
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4 5
Guten Tag,

ich habe hier mein erstes Projekt und erweitere es von Tag zu Tag. Es ist eine Bedienoberfläche für ein Windttunnel und besteht aus mehreren Seiten. Die angehängte Datei ist die Hauptseite.


Momentan schreibe ich das Programm ohne es 100% testen zu können, da ich nicht an meinem Arbeitsplatz bin. Dadurch kommen keine Signale an und mein Programm (so denke ich) hakt oder hängt sich auf auch deswegen auf. Außerdem funktioniert die Stop Funktion nicht mehr, wenn ich den "Smoke Control ON Button" betätige. Das Programm ist sehr wahrscheinlich nicht korrekt geschrieben aber es hat zumindest funktoniert.

Kann bitte jemand nach dem Feiertag einen Blick drauf werfen und mir mit der Stop Funktion weiterhelfen? Und bitte kurz erläutern wie der Programmablauf ist? Ich dachte alle Loops laufen gleichzeitig, aber wenn keine Signale ankommen, passiert bei dem Rest nichts mehr.


Schönen Feiertag noch Big Grin
Hallo Benutzer,

herzlich willkommen im Forum!

Zitat:Dadurch kommen keine Signale an und mein Programm (so denke ich) hakt oder hängt sich auf auch deswegen auf.
Nein, es "hängt" nicht wegen fehlender Signale.
Es hängt wegen fehlendem DATAFLOW!
Tipp: THINK DATAFLOW!
Tipp: Wenn Schleifen parallel laufen sollen, dann solltest du keine DATAFLOW-Abhängigkeit programmieren!
Tipp: Einfach mal mit Highlight-Execution debuggen!

Zitat:mir mit der Stop Funktion weiterhelfen?
Simple "quick and dirty"-Lösung: verwende lokale Variablen von "Stop" statt des Drahtes.
Bessere Lösung: nimm einen Notifier oder eine (F)GV (funktionale globale Variable), dann kannst du auch vernünftige subVIs anlegen!

Zitat:bitte kurz erläutern wie der Programmablauf ist?
Das ist doch dein VI, das solltest eigentlich du uns erklären können!

Zitat:Ich dachte alle Loops laufen gleichzeitig, aber wenn keine Signale ankommen, passiert bei dem Rest nichts mehr.
Die Loops laufen nicht gleichzeitig, weil DU es so programmiert hast!
Tipp: Links in meiner Signatur, besonders THINK DATAFLOW!

Und ganz schlimm (IMHO): Wenn du eine STOP-Funktion benötigst, um dein VI zu beenden, hast du definitiv etwas falsch gemacht…
Hallo Benutzer,

noch ein paar Anmerkungen zum VI:
- mus man wirklich alle 10ms die Disabled-Property von 4 Buttons erneut setzen? Muss man dazu gleich 4mal exakt dieselbe lokale Variable abfragen??? Kann man sowas nicht direkt im entsprechenden Event erledigen, wo du den zur lokalen Variablen gehörenden Button schon abfragst?
- Wenn du AutoCleanup benutzt hättest, dann würde dein VI nicht unbedingt schöner aussehen - aber du würdest den DATAFLOW genauer erkennen!
- Benötigst du wirklich eine Case-Struktur, um die FALSE/TRUE-Konstante auszugeben, wenn du "Windspeed changes" anzeigen willst? (Hochgradig Rube-Goldberg!) Und muss man das auch alle 10ms erledigen?
- Immer, wenn du in einer Case-Struktur einfach nur je eine Konstante pro Case ausgeben willst, würde ich dir eine Select-Funktion empfehlen: viel übersichtlicher!
- "Set Smoke"-Event: Wozu benötigt man eine FOR-Loop, die exakt nur einmal iterieren soll? Wozu hier zwei Case-Strukturen? Wenn du nur in einem Case etwas auf den UDP schreiben willst, solltest du auch das UDPWrite in den Case hinein nehmen: momentan kannst du auch einen leeren String ausgeben… "RequiredSmoke" sollte ein Integer-Typ sein!
- Alle diese einzelnen Events sollten zu nur einer Event-Struktur zusammengefasst werden: die kann beliebig viele Events verwalten! (Deine Stopp-Bedingung für die Schleifen lässt sich dann auch deutlich vereinfachen!)
- Eine Wartezeit parallel zu einer Eventstruktur - die noch dazu ewig wartet - ist Blödsinn!
- Dein VI lässt sich momentan u.a. nur deswegen mit der Stop-Funktion beenden, da du die ganzen Eventstrukturen ewig warten lässt! Außerdem würde ein zweiter Druck auf den Home-Button zu einem Einfrieren deines VIs führen, da die zugehörige Eventstruktur NICHT in einer Schleife verarbeitet wird! (Nochmal: Alle Events in nur einer Schleife&Eventstruktur verarbeiten!)
Vielen Dank für die vielen Lösungsansätze und Vorschläge ! Big Grin

Klingt nach einer riesen Construction

Ich werde mich dann erstmal einlesen.


Hier noch zu den vorherigen Kommentaren:

- Ich habe keine sinnvollen SUb VI's ausgemacht. Welche Funktionen wären denn sinnvoll?

- Was benutzt man denn sonst um ein VI zu beenden?

- Die 10ms in den Schleifen waren einfach mal reingeshrieben. Ich habe mir darüber keinen Kopf gemacht. Dachte das wäre nicht so wichtig, hauptsache überhaupt eine Wait-Funktion.

- Ein zweiter klick euf den Home Button ist nicht möglich, da sich das VI schießt und sich ein anderes öffnet

- Und was heißt das ich die die Eventstrukturen EWIG warte lasse? Sind doch nur max. 10ms, oder etwa nicht? Blink
Hallo Benutzer,

Zitat:Klingt nach einer riesen Construction
Ja.

Zitat:Ich habe keine sinnvollen SUb VI's ausgemacht. Welche Funktionen wären denn sinnvoll?
Beispiele:
- Events kann man in subVIs ausführen.
- Netzwerkkommunikation kann man in subVIs ausführen.

Zitat:Was benutzt man denn sonst um ein VI zu beenden?
Ein VI wird beendet, wenn aller Code darin abgearbeitet ist. Dann braucht man keine extra STOP-Funktion, die evtl. noch irgendwelchen Code hart unterbricht…

Zitat:Die 10ms in den Schleifen waren einfach mal reingeshrieben. Ich habe mir darüber keinen Kopf gemacht.
Du programmierst also, ohne dir "einen Kopf darüber zu machen"???

Zitat:Dachte das wäre nicht so wichtig, hauptsache überhaupt eine Wait-Funktion.
Die Eventstruktur ist doch schon eine Wartefunktion…

Zitat:Ein zweiter klick euf den Home Button ist nicht möglich, da sich das VI schießt und sich ein anderes öffnet
Das konnte ich in der Eventstruktur nicht erkennen…
Edit: Jetzt doch gesehen. Aber wieso muss man ein FP programmatisch schließen, das macht doch LabVIEW bei korrekter Programmierung automatisch!?

Zitat:Und was heißt das ich die die Eventstrukturen EWIG warte lasse? Sind doch nur max. 10ms, oder etwa nicht?
Die Eventstrukturen warten nun mal EWIG auf ein Event - du hast ja das (default) Timeout-Event gelöscht…
Ich habe nun einige Änderungen vorgenommen. Es funktioniert auch...bis ich Stop drücke Ahrg1

Folgende Meldung erscheint (Siehe Screenshot)
Was bedeutet das und wie kann ich den Fehler beheben?


Zitat:
"Edit: Jetzt doch gesehen. Aber wieso muss man ein FP programmatisch schließen, das macht doch LabVIEW bei korrekter Programmierung automatisch!?"

Das war die erstbeste Lösung die ich gefunden habe.


Vielleicht noch zur Erläuterung:
Zum Schluss soll daraus eine EXE Datei entstehen wo der Benutzer keine Änderungen vornehmen kann. Mit hilfe der Button links oben kann der Benutzer das Programm beenden, die Datenspeicherung starten/anhalten oder zum vorherigen VI springen.


Zitat:
"du hast ja das (default) Timeout-Event gelöscht… "

Ist das nun wieder korrekt eingebunden?
Hallo Benutzer,

Zitat:Was bedeutet das und wie kann ich den Fehler beheben?
Der Fehler bedeutet genau das, was da steht: beim UDPClose kam eine ungültige Referenz an!

Wie kann man das nun beheben?
- Mal überlegen: Links von der Eventstruktur öffnest du 6 UDP-Verbindungen. Rechts davon gibt es aber nur noch eine UDPClose-Funktion: da passt schon mal was nicht zusammen…
- Wann wird die Schleife mit der Eventstruktur (sehr) wahrscheinlich beendet? Genau: mit einem Timeout-Event. Welche UDP-Referenz gibst du im Timeout-Event raus? Ist die gültig? Es ist IMMER sehr gefährlich, wenn man einen Tunnel auf "default if unwired" setzt und dann Referenzen darüber leitet!

Lösung: Einfach ALLE 6 UDP-Referenzen durchverdrahten!
Tipp: Den Timeout-Case verdrahten, dann alle "durchverdrahteten" Drähte am Ausgangstunnel als "offene Case erstellen&verbinden" verknüpfen!

Zum VI:
- Es ist schon deutlich besser geworden!
- Was soll der (klassische!) Rube-Goldberg "if TRUE then TRUE else FALSE"?
- Warum die lokale Variable "stop button" in der Event-Schleife? Warum kein ValueChange-Event für den Stop-Button?
- Warum eine Race-Condition mit der lokalen Variablen "Required Windspeed" im gleichnamigen Event? Warum verwendest du nicht mehr Draht?
- Das gleiche im "Required Smoke"-Event, hier sogar doppelt…
- Es gibt immer noch eine FOR-Loo, die exakt einmal durchlaufen soll. Was genau soll das bringen? Wo ist der Vorteil, wenn du die FOR-Loop auch einfach weglassen könntest???
- Warum ist das Event für den HOME-Button immer noch einzeln? Warum nicht einfach in die "große" Event-Struktur mit hinein nehmen?
- Du benutzt immer noch die Method-Node zum Schließen des FP!? Die ist unnötig!
- In der "Property-Node"-Schleife wird immer noch "Smoke Start Stop" 4mal in Enabled/Disabled umgewandelt: würde einmal umwandeln nicht ausreichen???
- Diese ganzen Propertynodes aus dieser Schleife sollten in die entsprechenden Events weiter oben verschoben werden! 2 Vorteile: weniger lokale Variablen und die Propertynodes werden exakt dann gesetzt, wenn es nötig ist!
- Die IP-Adressen müssen auch nur einmal von String nach Zahl umgewandelt werden…
Vielen Dank für die erneute schnelle Antwort Big Grin
Hat schon weit geholfen!

Nun sind aber wieder ein paar Fragen aufgetaucht.

Frage 1:
Ist es wirklich nötig das die Leitungen jetzt in jedem Event durchgezogen sind? (Siehe Foto "Frage 1") Das wird sehr unübersichtlich!
Es funktioniert gerade auch wenn ich im Timeout case nur ein oder zwei Leitungen verbinde.

Frage 1.1 /1.2:
Soll ich "connection ID" und "error out" mit der rechten Seite verbinden? Könntest du das etwas näher erläutern?

Frage 2:
Meinst du das mit dem " (klassische!) Rube-Goldberg" (Siehe Foto "Frage 2")?

Es muss der Text (true/false) versendet werden. Die angeschlossenen Komponenten benötigen dies.

Frage 3:
Zitat:
"Du benutzt immer noch die Method-Node zum Schließen des FP!?"
Was meinst du damit?

Frage 4:
Zitat:
"Die IP-Adressen müssen auch nur einmal von String nach Zahl umgewandelt werden"
Kling logisch. Aber wie setze ich das um? Ich dachte wenn die vor der Loop sind reicht das.

Frage 5:
Kann ich die Propertynodes gleich zu beginn eingrauen? Jetzt werden wie erst nach zweimaligen Betätigen der "Start Stop Schalter" eingegraut.
Hallo Benutzer,

Zitat:Frage 1:
Ist es wirklich nötig das die Leitungen jetzt in jedem Event durchgezogen sind? (Siehe Foto "Frage 1") Das wird sehr unübersichtlich!
Es funktioniert gerade auch wenn ich im Timeout case nur ein oder zwei Leitungen verbinde.
Ja, das ist nötig! Und nein, das ist nicht unübersichtlich - wenn man sein Blockdiagramm schön ausrichtet und ordnet…

Was funktioniert? Es werden alle 6 UDP-Ports, die du vorher geöffnet hast, auch wieder geschlossen? Obwohl nur 2 oder 3 Drähte gezogen wurden?
Grundregel: Jede Resource (quasi jede Art von Referenz), die du in deinem Programm explizit anforderst, musst du auch wieder schließen. Jede!
Hast du meinen Tipp oben mit den verlinkten Tunneln nachvollzogen? Dann übernimmt LabVIEW das Verdrahten!

Zitat:Frage 1.1 /1.2: Soll ich "connection ID" und "error out" mit der rechten Seite verbinden?
Die Referenz auf alle Fälle, der Error nur nach Bedarf. Wobei ein ordentliches Errorhandling ja auch nicht zu verachten ist…

Zitat:Frage 2: Meinst du das mit dem " (klassische!) Rube-Goldberg" (Siehe Foto "Frage 2")?
Nein.
Ich meine das hier: [attachment=58973] "IF true THEN true ELSE false"… Big Grin

Zitat:Frage 3: Was meinst du damit?
Das hier:
[attachment=58974]
Das FP schließt automatisch, wenn du das in den VI-Einstellungen vorgibst und das VI eben (korrekt) abgearbeitet ist! Dazu brauchst du keine Property oder InvokeNode…

Zitat:Frage 4: Kling logisch. Aber wie setze ich das um? Ich dachte wenn die vor der Loop sind reicht das.
Einfach den umgewandelten Wert zweimal verwenden (den Draht verzweigen)…

Zitat:Frage 5: Kann ich die Propertynodes gleich zu beginn eingrauen? Jetzt werden wie erst nach zweimaligen Betätigen der "Start Stop Schalter" eingegraut.
Ja. Einfach ein passendes Event erzeugen (mit einer "Value (signalling)"-Property)…
Hallo GerdW,

ZU 1
Warscheinlich wurden nicht alle Ports geschlossen. Aber es gab keine Fehlermeldung.
Den Tipp habe ich nachvollzogen.
Warum werden denn Leitungen die vorher schon von links nach rechts über UDP Write verbunden waren, noch einmal direkt rübergezogen?


ZU 2 und4
Habe ich übersehen Dodgy



Frage 1
Ich möchte beim beenden oder Fenster wechsel alle Werte auf Null setzten, diese auch noch einmal abschicken und dann abschalten (false senden).
Das Null setzten und ausschalten habe ich hinbekommen, nun fehlt noch das der Wert Null auch versendet wird. Dachte daran den Klick auf SET Value zu simulieren. Kannst du mir da einen Tipp geben?


Frage 2
Zu guter letzt möchte ich eine Auswahl treffen können welche Daten (in eine Excel Datei) gespeichert werden können. Dies soll bei klick auf Start beginnen und bei klick auf Stop beendet werden. Das beenden der Speicherung soll natürlich auch bei klick auf Home und Exit funktionieren. Könntest du mir dazu auch einen Tipp geben?


Vielen Dank für deine Unterstützung
Seiten: 1 2 3 4 5
Referenz-URLs