Hallo zusammen,
Zitat:Irgendwer hat mal gesagt, FGVs sind Klassen für Arme. Hab ich nichts dagegen.
Habe ich zwar nicht (so) gesagt, kann ich aber zustimmen…
FGVs sind gut, wenn man ein (1) Datenobjekt verwalten will. Sobald man mehrere dieser Datenobjekte verwalten will wird es kompilizierter - und da kommt dann OOP ins Spiel, das von Haus dieses "mehrere Datenobjekte" abstrahiert.
Beispiel: ich brauchte eine Rampenfunktion in einem Programm. Also eine FGV erstellt, die 3 States kennt: Init (mit Rampenhöhe und -dauer), aktuellen Rampenwert (über die Zeit), Ende. Das aufrufende Programm war glücklich und der User konnte seine Rampe ablaufen lassen. 1 Woche später kommt der User: "Ich brauche eine zweite Rampe!" Ups, was nun? FGV kopieren und mit anderem Namen nochmal in Programm packen!? Also doch die Kernfunktion in eine Klasse gepackt und (schwups) beliebige viele Rampen(-Objekte) im Programm möglich…
Zitat:Wenn ich mal Zeit habe, versuche ich es mal ohne FGV.
Ich selbst nutze auch FGVs - aber nicht, um "unkontrolliert" aus irgendwelchen subVIs heraus Werte zwischen VIs auszutauschen. Das führt dann nämlich auch wieder zu RaceConditions: welches subVI ruft deine FGV schneller auf, um irgendein Element zu updaten! Und wenn es zu viele Aufrufe dieser FGV werden, dann blockieren die sich per Design gegenseitig…
(Diese Vorgehensweise ist eigentlich in keiner Programmiersprache empfohlen. Solche Programme sind nur schwer zu dokumentieren, schwerer zu debuggen, usw.)
Zitat:Ich versuche mit sowenig Drähten wie möglich auszukommen.
Dann solltest du eher eine Text-basierte Programmiersprache verwenden…
Im Ernst: auf Drähte zu verzichten führt relativ schnell zu RaceConditions…
Du hast doch einen QMH: was spricht dagegen, dass dein MessVI seine Messwerte per Message an den GUI-Handler schickt, der diese Message empfängt und die Werte auf seinem GUI anzeigt? Genauso wie der GUI-Handler Eingaben auf seinem GUI an den QMH schickt, damit der damit seine subVIs aufruft!
