Frage zur Queued State Machine / Producer-Consumer-Struktur

Mal ne Frage ans LVF:

Der Vorteil einer Producer-Consumer-Architektur mit "integrierter" State Machine ist ja, dass man die eigentliche Programm-Abarbeitung in der State Machine von den Benutzereingaben (z.B. "Stop-Kommando" über Button) entkoppelt. Somit können z.B. Ressourcen gespart werden, das Programm wird insgesamt "performanter" und beim User ensteht nicht der Eindruck, ein Programm würde irgendwie "hängen", weil es noch irgend ne Aktion durchführt (Button reagiert sofort, weil in separater Schleife!).

Aber...ich hab z.B. das Problem das ich über einen Counter ein TTL-Signal erfasse. Dieses TTL-Signal wird durch ein sich drehendes Rad über einen speziellen Sensor erzeugt. Nun ist es so, dass das Rad sehr schnell drehen kann (3000 U/min, das entspricht dann einer Signalfrequenz von ca. 52 kHz)...aber auch sehr langsam (nahezu Stillstand)...die Frequenz ist dann auch SEHR niedrig. Von einem TTL-Rechteckimpuls zum nächsten kann es dann schon mal 1-2 Sekunden dauern. Die Rechteckpulse sind abhängig von verschiedenen Bedingungen unterschiedlich breit, darum wird hier über den Counter eine Pulsbreitenmessung durchgeführt. Damit ich beim DAQmx-Read des Counters keine Fehlermeldung produziere, muss eine Timeout-Zeit spezifiziert werden (entsprechend der niedrigsten möglichen Drehzahl bzw. Signalfrequenz). Wenn das DAQmx-Read dann in der Consumer-State Machine (State "Read counter") untergebracht ist, wird in diesem State dann halt entsprechend der Timeout-Zeit gewartet, bis ein neuer Puls kommt. Drückt der User in dieser Zeit (über die Producer-Event-Struktur) auf den Abbrechen-Button, wird das Programm aber nicht sofort beendet...eben weil das Read-VI noch nicht fertig ist. Der Abbrechen-Button reagiert zwar sofort und schreibt den neuen State "EXIT" in die Queue, diese wird aber erst nach der Timeout-Zeit des Read-VI im nächsten Schleifendurchlauf abgefragt...

Problem erkannt? Wie könnte man das geschickter lösen?

Gruß
Achim

Anzeige

Du kannst dein Timeout auch bei niedrigen Abtastfrequenzen klein einstellen und in einer While-Schleife warten bis kein Timeout-Fehler kommt oder eben ein Befehl zum Abbrechen kommt.

' schrieb:Du kannst dein Timeout auch bei niedrigen Abtastfrequenzen klein einstellen und in einer While-Schleife warten bis kein Timeout-Fehler kommt oder eben ein Befehl zum Abbrechen kommt.

Fränkisches Fragewort mit drei Buchstaben:

HÄH?

... man könnte auch den DAQmx Task beenden, dann bricht DAQRead mit Fehler ab.

Ab EG's Vorschlag ist denke ich besser.

' schrieb:... man könnte auch den DAQmx Task beenden, dann bricht DAQRead mit Fehler ab.

Ab EG's Vorschlag ist denke ich besser.

Ich bin gegen Gewalt

Kann man das nicht genau so lösen, wie wenn man ein großes Timeout in einer Wait-Schleife hat, und man will erreichen, daß auf Stop sofort reagiert wird?

Also: Das Timeuet sei 10sec. Es wird auf 200ms verkürzt, und es werden bis zu 50 Versuche gemacht, eine Flanke zu lesen. Wenn alls 50 Versuche vergeblich waren, dann hat man ein echtes Timout.
Der Witz des Ganzen ist, daß die Reaktionszeit auf Stop von max 10sec auf max 200ms herabgesetzt wird.

Wenn das nicht verständlich ist, dann müßte ich noch ein Beipiel machen.

Anzeige

' schrieb:Wenn das nicht verständlich ist, dann müßte ich noch ein Beipiel machen.

Das wär nett...ich blicks nämlich nicht!

Wir meinen mit Lucki das gleiche.

Ah...also im Read-Case die Queue pollen und (wie bei dir) nur gucken ob überhaupt ein neues Kommando da ist oder evtl. sogar gucken ob das nächste Kommando ein EXIT (=> Beenden...) oder irgend ein anderes Kommando ist. Klingt nicht schlecht...

Gibts noch Alternativ-Vorschläge?

Gruß
Achim

' schrieb:Ah...also im Read-Case die Queue pollen und (wie bei dir) nur gucken ob überhaupt ein neues Kommando da ist oder evtl. sogar gucken ob das nächste Kommando ein EXIT (=> Beenden...) oder irgend ein anderes Kommando ist. Klingt nicht schlecht...

Gibts noch Alternativ-Vorschläge?

Gruß
Achim

Ja, du kannst fast genauso vorgehen wie wir vorgeschlagen haben. Aber statt den Status der Queue zu pollen, kannst du in der inneren Schleife den aktuellen Befehl auslesen und wenn das ein Read ist, dann lesen und wieder Read reinschreiben. Also eine verschachtelte State Machine.

Das kann man verständlicher mit einer UML Diagramm beschreiben, als die erste Lösung.