Schalter deaktivieren führt zu race condition, wie umgeht man das?

Guten Morgen zusammen.
Wahrscheinlich total banal, aber ich komme nicht drauf:
Ich muss einen zweiten Motor zuschalten zu einer Anlage, der ist aber an die Bedingung geknüpft, dass zwei Referenzmessstrecken (Turbinenradzähler) geöffnet sind. Jetzt baue ich mir eine race condition wenn ich den Schalter wieder deaktiviere, wenn die Bedingung nicht erfüllt ist. Die Bedingung wird in einer state machine erst generiert, dort würe ich es deaktivieren, wenn es nicht erlaubt ist. Aktuell ist es noch so:
   
Wo ich mir eine race condition einfange und es sein kann, das ich den Schalter drücke und er wieder rausspringt.

Wie macht man sowas richtig? Eventcase?

MfG Timo

Hallo Timo,

Zitat:Wo ich mir eine race condition einfange und es sein kann, das ich den Schalter drücke und er wieder rausspringt.

Deine Beschreibung kann man nur anhand eines Bildes eines Teils deines Codes nur schlecht nachvollziehen, insbesondere das "Drücken" und "Rausspringen"…

Zum Bild:
- Warum so viele lokale Variablen? (Gerade beim Thema Race-Conditions!?)
- Du vergleichst diesen "Zähler 1" einmal "<>3" und einmal "==3"!? Warum nicht nur ein Vergleich? Warum eine Case-Struktur daran knüpfen und parallel ein Select? Warum nicht beide Auswertungen dieser einen Bedingung in nur einer Case-Struktur? Warum nicht eine gemeinsame Propertynode, in der sowohl der "value" als auch das "Disabled" gesetzt werden? Bei mir sieht so ein Konstrukt in etwa so aus (wenn es denn unbedingt sein muss):
   
(Da man recht oft Controls en-/disablen muss, habe ich dafür ein kleines subVI in meiner user.lib, um das passende Enum zu generieren.)

- Race-Condition: du schreibst in eine lokale Variable von "Motor2" innerhalb der Case-Struktur, liest aber parallel dazu aus dem Terminal von Motor2!

Hallo Gerd,

danke für die Kritik.

(11.05.2021 07:48 )GerdW schrieb:  

Zitat:Wo ich mir eine race condition einfange und es sein kann, das ich den Schalter drücke und er wieder rausspringt.

Deine Beschreibung kann man nur anhand eines Bildes eines Teils deines Codes nur schlecht nachvollziehen, insbesondere das "Drücken" und "Rausspringen"…

Mir ging es nur eher generell, ich bin sicher nicht der Einzige der solche Fälle hat und überlege mir jedesmal neu um dann festzustellen, so kann das nicht richtig sein. Ich habe es hier jetzt gelöst, in dem ich es in das erste Case nach dem Umschalten gepackt habe, welches die Auswahl des Zählers bestätigt und entsprechend schaltet.

Dennoch hier: Der zweite Motor ist eine Option und kann zusätzlich eingeschalten werden (falsch formuliert in meinem ersten Beitrag). Mit "rausspringen" ist die race condition gemeint, beim Schalten des Schalters ist der state schon abgefragt und wird dann zurückgesetzt, obwohl die Bedingung erfüllt ist. Dies wollte ich mit der Case abfangen, indem ich nur bei aktivem Schalter diesen evtl. zurücksetze (FALSE-Case ist leer).

Zitat:Zum Bild:
- Warum so viele lokale Variablen? (Gerade beim Thema Race-Conditions!?)

Altes Programm, das von mir übernommen wurde, über 5 Bildschirme voller Code Und der wurde schon von mir zusammengestutzt ... Ich arbeite viel mit lokalen Variablen (ich weiß, ist schlecht), weil das in den alten Programmen so gemacht wurde und ich das damit so gelernt habe. Neue Programme von mir haben fast gar keine mehr oder zumindest keine Race Conditions.

Zitat:- Du vergleichst diesen "Zähler 1" einmal "<>3" und einmal "==3"!? Warum nicht nur ein Vergleich? Warum eine Case-Struktur daran knüpfen und parallel ein Select? Warum nicht beide Auswertungen dieser einen Bedingung in nur einer Case-Struktur?

Durch das ganze rumprobieren ist das entstanden, haste recht, habe ich behoben. (Bei FALSE soll der Schalter nicht geändert werden, der Case ist leer)

Zitat:Warum nicht eine gemeinsame Propertynode, in der sowohl der "value" als auch das "Disabled" gesetzt werden?

Auf jedenfall mal ein guter Tipp, es sind die kleinen Dinge, die einen Code besser machen.

Zitat:- Race-Condition: du schreibst in eine lokale Variable von "Motor2" innerhalb der Case-Struktur, liest aber parallel dazu aus dem Terminal von Motor2!

Ja, das will ich doch gerade richtig machen und bin deswegen hier. Um das ganze mal runter zu brechen, mein Testversuch war so:
   
Der 2te Case ist leer. Wie würde man das richtig machen? Mit oder ohne Bedienelement (de-)aktivieren.


Grüße Timo

Hallo Timo,

Zitat:Mit "rausspringen" ist die race condition gemeint, beim Schalten des Schalters ist der state schon abgefragt und wird dann zurückgesetzt, obwohl die Bedingung erfüllt ist. Dies wollte ich mit der Case abfangen, indem ich nur bei aktivem Schalter diesen evtl. zurücksetze (FALSE-Case ist leer).

Wieso kann man diesen Schalter überhaupt betätigen, wenn die Bedingungen dafür noch nicht gegeben sind?
Anders ausgedrückt: warum prüfst du diese Bedingen erst so spät, nachdem der User schon den Motor aktivieren konnte/wollte?

Zitat:Der 2te Case ist leer. Wie würde man das richtig machen? Mit oder ohne Bedienelement (de-)aktivieren.

Erstmal eine kleine Wartezeit in die Schleife.
Und dann hilft es meistens auch, wenn man Propertynodes nur (erneut) setzt, wenn sich die Property wirklich geändert hat - also die Property "Disabled" nur dann beschreiben, wenn sich "möglich" ändert.
Und wenn alles nichts hilft, kann man mit einer Sequenz noch festlegen, wann die lokale Variable geschrieben wird und wann das Terminal gelesen wird…

(11.05.2021 10:17 )GerdW schrieb:  Erstmal eine kleine Wartezeit in die Schleife.

generell ja, hier lässt sich ohne Wartezeit die race condition aber sehr gut nachvollziehen

Zitat:Und dann hilft es meistens auch, wenn man Propertynodes nur (erneut) setzt, wenn sich die Property wirklich geändert hat - also die Property "Disabled" nur dann beschreiben, wenn sich "möglich" ändert.

Also so:
   
Ja, ich glaube das war der entscheidende Punkt der mir fehlte, vielen Dank für die Unterrichtsstunde