(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 ^^
/
Zugriff auf Control über Referenz - paralleler Zugriff
