' schrieb:Zwei kleine Anmerkungen:
1. Wenn du Producer/Consumer mit Events einsetzt, ist es zu 95% der Fälle sauberer nicht nur das Kommando runter zu schicken und dann asynchron die Controls auszulesen, sondern direkt im Eventcase alle zum Kommando gehörenden Daten zu sammeln und als Message (Kommando + Daten (z.b. Variant)) zu senden... sonst drohen race conditions.
Hallo rbliomera, waere es Dir vielleicht moeglich, mir ein Beispiel zu zeigen oder es mir konkret am meinem Programm bitte zu zeigen? Ist dein Vorschlag bei mir gerade der Fall?
' schrieb:2. Schon bei beim "normalen" Entwickeln den Queuetimeout zu (miss-)brauchen, um zyklische Sachen zu realisieren ist nicht gut. Wenn du dich dann wirklich drauf verlassen willst, daß es halbwegs zyklisch gerufen wird, musst du ab dann immer daran denken, daß du diese Annahme/Vorgabe gilt. Solche Timeout-Spielchen haben ihre Berechtigung und das funktioniert auch meistens "irgendwie" oder kommen als Inbetriebnahme Workaround vor, aber schön sind die nicht.
' schrieb:Da hast du Recht, sauberer ist es, einen eigenen Zustand für diese Status-Abfrage vorzusehen, die dann zyklisch über die Queue getriggert werden kann.
Im StyleBook steht, man soll keine Timeouts benutzen, wie ihr es schon erwaehnt habt. Wie realisiert man bitte zyklische Sachen und was bedeutet zyklisch? Tasks, die sich staendig wiederholen?
Bin ich die ganze Sache doch schon wieder falsch angegangen?
Parallele Loops sollten moeglich sein. Das LabviewStyle Book empfiehlt, man soll ein Event Handling loop, Main State Machine, Hardware I/O, und Error Handling Loop haben. Habt ihr eventuell ein Beispiel fuer so ein LabView-Program bitte?
Danke schoen und einen Gruss
Blue
