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