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!
bei meinem PSU-VI-Projekt häufen sich inzwischen die Probleme. Ich nutze eine QSM über die ich inzwischen nicht viel gutes gelesen habe. Zum Problem, wenn die StateMachine(SM) in den "WaitMeasurementTime"-Zustand wechselt, kann das VI währendessen nicht mehr abgebrochen werden, trotz Event Struktur. Scheint als hätte der Timer Priorität bzw. es scheint in der Natur der QSM zu liegen, erst einen Zustand abzuwarten und dann das nächste Event auszuführen, falls eins anliegt - deshalb auch der Name QSM (Queued State Machine).
Gibt es eine Möglichkeit trotz QSM, den Abbruch zu forcen und den State sofort zu verlassen?
Für eure Antworten bin ich wie immer sehr dankbar.
Grüße
Anbei das PSU-VI basierend auf LabVIEW-Version 2019
Zitat:wenn die StateMachine(SM) in den "WaitMeasurementTime"-Zustand wechselt, kann das VI währendessen nicht mehr abgebrochen werden, trotz Event Struktur. Scheint als hätte der Timer Priorität bzw. es scheint in der Natur der QSM zu liegen, erst einen Zustand abzuwarten und dann das nächste Event auszuführen, falls eins anliegt - deshalb auch der Name QSM (Queued State Machine).
Gibt es eine Möglichkeit trotz QSM, den Abbruch zu forcen und den State sofort zu verlassen?
Die QSM macht das, was du programmiert hast!
Es gibt keinen State "WaitMeasurementTime", ich vermute du meinst stattdessen "csv WaitMeasurementTime"…
Ja, es gibt eine Möglichkeit: entferne die Schleife im State "csv WaitMeasurementTime"!
Und ja, deine QSM ist schlecht programmiert: warum sendest du nur ein Kommando, aber übergibst die Parameter über die lokalen Variablen!?
Der/die Parameter gehört/-en in die Kommando-Message hinein!
Danke für deine Antwort und entschuldige die falsche State-Bezeichnung.
Ja, ich meinte den "csv WaitMeasurementTime" - State.
Ohne Schleife funktioniert der Timer nicht. Also vermute ich mal, dass ich eine Art weitere Abbruchbedingung für die Schleife brauche, um diese vorzeitig zu verlassen.
Die lokalen Parameter nutze ich, weil ich nicht weiß, wie ich die Daten von der Event-Schleife auf die Haupt-Schleife übernehmen soll und ich gelesen habe, dass man bei einer QSM in die Queure Leitung am besten gar keine States übernehmen soll und wenn doch, dann nur diese und keine weiteren Daten.
Wie sieht sowas richtig aus?
Was ist eine Kommando-Message?
Entschuldige, ist mein erstes größeres Projekt mit LabVIEW.
Zitat:Ohne Schleife funktioniert der Timer nicht. Also vermute ich mal, dass ich eine Art weitere Abbruchbedingung für die Schleife brauche, um diese vorzeitig zu verlassen.
Doch.
Wenn Timer noch nicht abgelaufen: rufe den State erneut auf.
Wenn Timer abgelaufen: rufe den nächsten State auf...
Zitat:Die lokalen Parameter nutze ich, weil ich nicht weiß, wie ich die Daten von der Event-Schleife auf die Haupt-Schleife übernehmen soll und ich gelesen habe, dass man bei einer QSM in die Queure Leitung am besten gar keine States übernehmen soll und wenn doch, dann nur diese und keine weiteren Daten.
Wie sieht sowas richtig aus?
Was ist eine Kommando-Message?
Eine "Kommando-Message" ist das, was deine Event-Schleife an den Consumer (aka Statemachine-Schleife) schickt. Aktuell besteht dein Kommando nur aus dem Enum.
Wenn du das Kommando als Cluster definierst, z.B. [Enum, DBL-Wert], dann kannst du wie oben geschrieben eben auch "Kommando + Parameter" senden!
(Wenn du zuviele unterschiedliche Parameter-Datentypen unterstützen musst, kann dein Cluster aus Enum+Variant bestehen. Jeder State muss dann das Variant für sich passend zurück umwandeln...)
Mal abgesehen davon, dass es als schlechter Programmierstil gilt, welche Nachteile bringt es mit sich Daten mittels lokaler Variable in eine andere Schleife zu bringen?
(22.04.2024 11:43 )SirTom schrieb: Ich nutze eine QSM über die ich inzwischen nicht viel gutes gelesen habe.
Was liest du denn für einen Unsinn?
Es ist nahezu vollständig egal wie das Ganze benannt wird - auch wenn in 5 Jahren irgend jemand ein "super-extra-perfect-design", oder wie immer das dann genannt wird, erfindet, wird es, falls es auch nur einigermaßen sinnvoll einsetzbar ist, im Grunde nach nichts anderes sein, als was du jetzt mit QSM bezeichnest. Das ist seit LabVIEW 2.5.1 der Fall (ältere Versionen kenne ich persönlich leider nicht) und daran wird sich auch kaum jemals etwas ändern.
Oh ..oh ... ich bitte vorsichthalber all diejenigen um Verzeihung die ein irgendwie benanntes Grunddesign liebend gerne verwenden und es für ganz exklusiv und einzigartig und perfekt halten :-)
Zitat:Die Frage über lokale Variablen zum "Datentransfer" ist noch offen. Was für Nachteile können daraus resultieren?
- Sie verhindern, dass du deinen Code modularisieren kannst: wenn du einzelne States als subVI umformen willst, wird es mit lokalen Variablen recht schwierig…
- Sie entsprechen nicht dem "Think DATAFLOW!"-Mantra: man verliert schnell den Überblick, wo auf welche Daten zugegriffen wird.
- Zu extensive Nutzung von lokalen/globalen/"Value"-Properties Variablen kann schnell zu Race-Conditions führen…
- Lokale Variablen führen zu Datenkopien, was insbesondere bei größeren Arrays problematisch sein kann.
Vorteile lokaler Variablen:
- Sie sind relativ schnell, wenn man Daten innerhalb eines VIs übertragen will…
- ???
Ah ja ... solche lustigen Diskussionen gibt es von Zeit zu Zeit.
(22.04.2024 18:08 )SirTom schrieb: Die Frage über lokale Variablen zum "Datentransfer" ist noch offen. Was für Nachteile können daraus resultieren?
1. Rrace condition (du kannst u.U. nicht mehr vorhersehen, was, wann passiert)
2. Die While-Schleife kann nichtin ein separates VI ausgelagert werden.
3. das Allerschlimmste: ich sehe aus 10m Entfernung, dass du ein blutiger Anfänger bist.
Überraschung! jetzt kommt etwas sehr Ernsthaftes: Programmiere die untere Schleife in einem separaten VI und programmiere diese so, dass du ohne den größten Unfug aller Zeiten (ohne globale Variablen) und soweit irgendwie möglich, auch ohne Referenzen auf Controls und Indicators klar kommst. Und natürlich so, dass du den Ablauf in einer für dich angemessenen Zeit immer abbrechen kannst. Das kann Schwierig sein, denn der Mensch denkt lieber linear und nur sehr widerwillig in Schleifen.
PS: ich gebe zu, ich bin gerade auf Krawall gebürstet
PPS: ich bemühe mich um Besserung
Martin Henz
24.04.2024, 12:00 (Dieser Beitrag wurde zuletzt bearbeitet: 24.04.2024 12:13 von SirTom.)
ich hab die Schleife um den Timer entfernt und eine Fallunterscheidung hinzugefügt. Aber jetzt tut die Timer-Ftn gar nichts mehr bzw. gibt lustige Zahlen aus und Verweilt im Zustand, also vermutlich eine Dauerschleife erzeugt. Die Zahl wirkt willkürlich, könnte vllt die Anzahl Sekunden seit Systemstart sein, wobei "1054666:55:58" doch etwas viel scheint.
Woran könnte es liegen?
Desweiteren habe ich noch schwerwiegenderes Problem. Ich kann alle Werte setzen, aktiviere ich aber den Output kommt an den Klemmen nur für 1 bis 2 Sekunden die eingestellte Spannung und Strom an, dann fallen beide Werte auf 0. Sieht aus als würde ich den Output deaktivieren oder aber die Werte für die beiden Einheiten auf 0 setzen. Könnte das ein Datenfluss-Problem sein?
Meine StateMachine wechselt nach aktivieren des Outputs im Zustand "SET OutputOn/Off" wieder auf den "GET Output/Limit/Mode"-Zustand. Von da aus wechselt es zwischen "GET Output/Limit/Mode" und dem Zustand "Main/Idle/WaitForEvents" hin und her.
Könnte es an der zu häufigen Abfrage von Werten liegen, sodass das PSU den Output abbricht? Es wird keine Fehlermeldung ausgegeben.
Danke für eure Hilfe und nochmals danke für die ausführlichen Antworten zum Thema "lokale Variablen".
