Hi!
uwe111 hat geschrieben: ↑02.03.2022, 17:01
Also vorher wurden alle Datenpunkte gesammelt und hintereinander in
einem system.multicall übergeben. Jetzt habe das neue
TIMER_GET da herausgelöst und sende es als extra Datenpaket ohne Verzögerung hinterher. Damit ist die zeitliche Reihenfolge m.E. eindeutig geklärt.
Die zeitliche Reihenfolge ist ja nicht das eigentliche Problem, sondern die Race-Condition die durch erneute Änderung des Wertes entsteht.
Dein erstes TIMER_GET löst die Triggerung aus, so dass die Rega die Bedingungen des Programms prüft.
Wenn zwischen diesem Auslösen und der eigentlichen Prüfung der Wert aber wieder geändert wird, schlägt diese Prüfung eben fehl.
Ich hatte das schon vor einigen Jahren bemerkt (mit den Systemvariablen, wie in meinem Beispielprogramm) und habe daher immer eine Pause von 1s eingebaut. Das hat bisher immer gereicht.
Wenn Der CUxD Timer nun ein Programm triggert, dass ggf. etwas länger zur Ausführung braucht und der Timer ggf. noch etwas anderes triggert, kann das auch jetzt noch immer scheitern, wenn der Zeitabstand zu gering wird.
Ich bleibe daher bei meiner Empfehlung, den Zustand 0 für 1s stehen zu lassen und dann mit dem neuen Timer um eine Sekunde verkürzt wieder zu beginnen. Damit sollte es eigentlich in allen Fällen zuverlässig funktionieren.
Gruß,
Gerti