Zugriff auf Control über Referenz - paralleler Zugriff

Hi,

blöde Frage, da ich das nicht ohne weiteres selbst entkoppeln kann (kompliziertes über die Zeit gewachsenes Program an dem ich Feintuning mit möglichst wenig Programmieraufwand machen muss):

Wenn ich über eine Referenz (lesend oder schreibend) auf ein Control Zugreife (Value / Value Signalling), das in anderen Prozessen ebenfalls bezüglich Value abgefragt wird, sind dann Abstürze / Aufhänger zu befürchten oder ist das Schlimmste was passieren kann die Auswirkungen einer Racing Condition zu haben?

Weils sonst wahrscheinlich wieder zu Diskussionen führt warum ichs nicht "richtig" mache:
Die Racing Condition ist mir egal, da es nicht auf sofortige richtige Anzeige beim Rücklesen ankommt, alles andere sollte die SPS im Hintergrund glatt ziehen, da die bedienten / rückgelesenen Controls alle über die SPS aktualisiert werden. Heist für die Racing Condition: Beim Lesen über Referenz kriege ich durch (mit etwa 500ms pollendes) Lesen automatisch irgendwann den richtigen Wert im Input der höchstens etwa später Verarbeitet und ans FP auf einen Indikator zurückgegeben wird. Beim Schreiben brauche ich nur das Signaling um den Befehl an die SPS zu triggern, anschließend kann der Wert zwar nochmal zurückspringen (weil in der SPS noch nicht ausgeführt), geht aber nach Ausführung der SPS auf den relevanten Wert. Der zu schreibende Wert wird auf einem völlig separaten Control eingegeben - das hin und her Springen kann also nicht auf die Eingabe zurückwirken.
Hoffe das hilft fürs ruhig schlafen

Viele Grüße,
Kiesch

Abstürze und Aufhänger, durch das Betriebssystem oder die LV-Runtime bedingt (infolge mangelhaft manipulierter Pointer (nicht-skalare Datentypen)), halte ich für unwahrscheinlich. Abstürze, die applikationsbedingt sind, sollte es auf diesem Level der Programmierung (Datensfluß) auch nicht geben.

Applikationsbedinge Aufhänger kann ich mir tatsächlich vorstellen: Wenn zwei Algorithmen unabhängig und parallel schreibend auf einen zuvor gelesenen Wert zugreifen (nämlich z.B. per Referenz), um den Wert z.B. zu regeln, kann ich mir vorstellen, dass infolge des nicht konsistenten gelesenen Wertes es zu Fehlverhalten im zu schreibenden Wert kommt. Die Sache wäre im Übrigen genauso kompliziert, wie der Satz selbst.

Wenn der neu zu schreibende neue Wert allerdings nicht vom gerade gelesenen alten Wert abhängt, also z.B. Lesen und Schreiben unabhängig und gegenseitig irrelevant sind, sollte es nicht zu Problemen kommen.

Ich halte es grundsätzlich nicht für einen guten Weg, auch in ein bestehendes "einfach strukturiertes" Programm ebensolche Algorithmen nachzurüsten - auch wenn der Chef meint "schnell und billig". Spätestens bei der ersten Nacharbeit wegen unvorhergesehenem (nicht: unvorhersehbarem) Fehler ist aus mit billig. Selbst in Tapeten oder QMH-gesteuerten Programmen kann man FGV's (also SubVI) integrieren, die gekapselten Code und gekapselte Daten enthalten. Alleine durch solche Maßnahmen kann die Wahrscheinlichkeit von applikations- bzw. strukturbedingtem Fehlverhalten minimiert werden.

Eine genaue Aussage zu Absturz- und Aufhäng-Wahrscheinlichkeit kann man aber nur bei Analyse des Programmes (also hauptsächlich seiner Struktur) sagen.

(30.01.2025 08:27 )IchSelbst schrieb:  Applikationsbedinge Aufhänger kann ich mir tatsächlich vorstellen: Wenn zwei Algorithmen unabhängig und parallel schreibend auf einen zuvor gelesenen Wert zugreifen (nämlich z.B. per Referenz), um den Wert z.B. zu regeln, kann ich mir vorstellen, dass infolge des nicht konsistenten gelesenen Wertes es zu Fehlverhalten im zu schreibenden Wert kommt. Die Sache wäre im Übrigen genauso kompliziert, wie der Satz selbst.

Wenn der neu zu schreibende neue Wert allerdings nicht vom gerade gelesenen alten Wert abhängt, also z.B. Lesen und Schreiben unabhängig und gegenseitig irrelevant sind, sollte es nicht zu Problemen kommen.

Genau - die Datenabhängigkeit zwischen setzen und lesen besteht nicht, im Hintergrund mache ich auch keine Regler kirre (der nicht versteht was vorgeht) da keiner auf den Werten arbeitet. Ich bin also - bis auf den parallelen Zugriff relativ zuversichtlich, dass die Anlage damit klarkommt.

Zitat:Ich halte es grundsätzlich nicht für einen guten Weg, auch in ein bestehendes "einfach strukturiertes" Programm ebensolche Algorithmen nachzurüsten - auch wenn der Chef meint "schnell und billig". Spätestens bei der ersten Nacharbeit wegen unvorhergesehenem (nicht: unvorhersehbarem) Fehler ist aus mit billig. Selbst in Tapeten oder QMH-gesteuerten Programmen kann man FGV's (also SubVI) integrieren, die gekapselten Code und gekapselte Daten enthalten. Alleine durch solche Maßnahmen kann die Wahrscheinlichkeit von applikations- bzw. strukturbedingtem Fehlverhalten minimiert werden.

Eine genaue Aussage zu Absturz- und Aufhäng-Wahrscheinlichkeit kann man aber nur bei Analyse des Programmes (also hauptsächlich seiner Struktur) sagen.

Ich müsste um hier FGVs einzusetzen erheblich in die Struktur des bestehenden Programs eingreifen. Das Program ist so gestrickt, dass eine GUI als Visualisierung einer SPS fungiert. Dabei wird ein automatisches Mapping von Controls auf dem Display auf "interne" Werte aus der SPS vorgenommen (anhand des Labels). Zum Aktualisieren der Controls werden Referenzen genutzt. Ein scheinbar sehr robustes System, dass bis auf einem Fehler den ich immer noch nicht verstehe (in einem SubVI (glaubt man dem was der code ausspuckt wenn ich die Referenzen in ne Datei dumpen lasse) haben 2 mal 2 Controls immer exakt die gleiche Referenznummer (die Labview beim Auslesen der Referenz zurückliefert), was zur Nichtaktualisierung der Controls führt und doppelbefüllung der anderen zwei führt) sehr gut funktioniert.
Dummerweise ist dabei der Referenzzugrif sehr elementar im System eingebaut. Ich bin dadurch gezwungen teilweise Nutzerinteraktionen in "simulierte" Nutzerinteraktionen (Value signaling) an einem anderen Control zu übersetzen. Gleiches Spielchen andersrum - ich hole mir die Daten aus einer Anzeige raus und rechne dann entsprechend der getroffenen Änderungen am System auf die "richtigen" Werte an einer Anzeige um. Wie gesagt - bisher habe ich gute Erfahrungen mit dem Konzept gemacht und auch ein ähnliches Konzept (objektorientiert) als Ansteuerung für eine andere Beschleunigeranlage aufgesetzt. Dabei verwaltet sich jeder einzelne DAQ Kanal auf den eingesetzten NI-USB 6001 /6002 selbst als Objekt und aktualisiert ein Displayelement zur Anzeige. Funktioniert seit mehreren Jahren robust im Dauerlauf :-)

Na ja, long story short. Vielen Dank für deine Antwort. Das beruhigt mich. Verlasse in 2 Monaten das Unternehmen, deswegen kommt der Zeitdruck nicht von Chef sondern von mir selbst. Nen externen einkaufen der das macht wird man sicher nicht. Uni, kein Geld. Wir müssen stümpern und hoffen das es hält. Hab jetzt schon Sorge das sich mein Chef irgendwann selbst an dem Code vergreift ^^