Cluster-Laufzeit Problem

Hallo,

ich habe eine Clustervariable aus dieser möchte ich lesen und schreiben. Das Ergebnis möchte ich dann wieder im Cluster haben. Dazu benutze ich eine Referenz.
Man sieht im Bsp. glaube ich gut dass der Klick auf den Schalter nicht immer angenommen wird.
Mit in der While-Schleife ist natürlich weiterer Code und das Lesen und Schreiben des Clusters ist auch etwas umfangreicher.
Hat jemand eine Erklärung dafür, oder noch besser eine Lösung parat?
Ich könnte mir auch gut vorstellen, dass es ein ganz einfaches, grundlegendes Problem mit der Referenz o. ä. ist.

Auf jeden Fall vielen Dank schon im Voraus für die Hilfe!

Mit freundlichen Grüßen

Christian Geiger

' schrieb:Man sieht im Bsp. glaube ich gut dass der Klick auf den Schalter nicht immer angenommen wird.

Das liegt aber nur an dem viel zu kurzen 1ms-Wait. Mit z.B. 50 ms funktioniert es einwandfrei.
Oder auch mit Event-Struktur, s. z.B. hier:

  Forum_Frage_JG.vi (Größe: 9,69 KB / Downloads: 228)


Gruß, Jens

P.S.:

Hi,
Profil ist aktualisiert.

Eine längere Wartezeit löst im realen Programm das Problem aber leider nicht. Im realen Programm läuft die Schleife mit 100ms. Im realen Programm sind auch drei weitere While-Schleifen die mit ähnlicher Geschwindigkeit parallel laufen.
Ich habe mal einen Screenshot einer solchen Cluster-Kette angehängt. Im realen Programm laufen 7 solcher Ketten durch die While-Schleife.

Grüße Christian

Das Setzen einer FP-Elements per Refnum und PropertyNode Value ist in LV auch nicht gerade das Schnellste, u.a., da dies im UI-Thread durchgeführt wird.
Außerdem bricht dies die goldene Regel in LV, Datenfluss.

Wo bei dir jetzt genau die Race Condition auftritt, ist schwer zu sagen.

Vielleicht hilft dir das Konzept einer FGV weiter?

Gruß, Jens

Hallo Christian,

der Fehler liegt in der Verwendung lokaler Variablen ("value"-Property ist nahezu das Gleiche) und der damit verbundenen Möglichkeit von RaceConditions...

In deinem ersten Beispiel kann es vorkommen, dass du genau dann klickst, wenn das VI schon den Status des Schalters gelesen hat, aber noch nicht die LED gesetzt hat. Dann wird der vorherige Schalterwert in die LED geschrieben und dann der ganzen Cluster überschrieben. RaceCondition aufgrund getrennter (nicht atomarer) Lese- und Schreibzugriffe auf den gleichen Cluster...

Generell:
Warum verwendest du bei deiner "Kette" nicht ein Eingabe-Element (Cluster_In) und ein Ausgabe-Element (Cluster_Out)? Warum liest du aus einer lokalen Variablen, wenn das Terminal gleich daneben unbenutzt rumliegt? Dein gezeigtes BD sollte ein subVI darstellen, welches sich den aktuellen Status des Clusters nicht zu merken braucht - dies sollte das mainVI übernehmen...