+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Zugriff auf Control über Referenz - paralleler Zugriff (/Thread-Zugriff-auf-Control-ueber-Referenz-paralleler-Zugriff)
Zugriff auf Control über Referenz - paralleler Zugriff - Kiesch - 28.01.2025 14:25
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
RE: Zugriff auf Control über Referenz - paralleler Zugriff - IchSelbst - Heute 08:27
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.