Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Zitat:Ich bin kein Fan davon, Referenzen auf FP-Elemente in FGVs zu verfrachten, um dann in irgendwelchen subVIs diese FP-Elemente manipulieren zu können. Dafür kann man den QMH selbst benutzen…
Ich kenne es nur so und war froh, dass ich von den Fäden weggekommen bin und sehr flexibel ohne viel Aktion damit arbeiten kann.
Was ist denn der QMH selbst ? Hast Du da vielleicht einen Code-Snippet zum Teilen ?
- QMH (QueuedMessageHandler) ist die Programmstruktur, die du aktuell schon verwendest: du schickst Messages per Queue an eine Handler-Routine…
- LabVIEW verwendet keine "Fäden", sondern Drähte. Und LabVIEW ist eine DATAFLOW-basierte Programmiersprache, die ihre Daten über eben jene Drähte transportiert. Warum willst du also von diesen Drähten "wegkommen"??? Damit wird dein Programm nicht übersichtlicher, im Gegenteil sieht man dann überhaupt nicht mehr, wo/wie/wann auf irgendwelche FP-Elemente zugegriffen wird!
Hallo GerdW,
Ich versuche mit sowenig Drähten wie möglich auszukommen. Díe FGV finde ich für verschachtelte Vis optimal.
Ich kenne ein Projekt, da wurde ein Cluster aus Referenzen als Draht durch das ganze Projekt durchgezogen.
Muss man mögen, irgendwann finde ich dass es zu viele Drähte sind.
(18.07.2024 12:03 )Hachiko schrieb: Ich glaube die LV-Profis scheinen keine FGV zu mögen
Also ich hab nichts gegen FGV's.
Kann man gut erweitern um beliebige und theoretisch beliebig viele Funktionen. Entspricht Kapselung von Daten und Programmen. Auch schön: Trennung von Blockdiagramm und User-sichtbares/zugreifbares Frontpanel. Debuggen auch gut.
Irgendwer hat mal gesagt, FGVs sind Klassen für Arme. Hab ich nichts dagegen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
18.07.2024, 13:15 (Dieser Beitrag wurde zuletzt bearbeitet: 18.07.2024 13:22 von GerdW.)
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!
Zitat:FGVs sind gut, wenn man ein (1) Datenobjekt verwalten will.
Genau 1 Datenobjekt. Nicht zwei, nicht drei. Genau 1. Außerdem: "Verwalten". Eine FGV ist nicht dazu da, primär Drähte einzusparen. Es soll vielmehr alles, was ein Datenobjekt braucht, zentral gesammelt werden.
Zitat:Werte zwischen VIs auszutauschen
Ich finde es tatsächlich eine schlechte Strategie, Daten auszutauschen per FGV. Austauschen und FGV passt einfach nicht zusammen. Austauschen, also "zur Verfügung stellen" und "Befehlen" gehört auch meiner Meinung nach in das QMH-System.
Zitat: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!
Ein "MessVI" ist ein SubVI, das (ohne FP) im Hintergrund selbständig läuft, also parallel und ohne jedwede Sequenzierung. Es ist praktisch eine selbständige Task.
FGVs sind nicht selbständig. Sie sind immer in einen Datenfluss eingebunden.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Zitat: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!
Ich glaube, ich bin nicht Profi genug, und die FGV ist einfach anzuwenden. Für meine kleinen Anwendungen ausreichend.
Danke für die Erläuterung wie du das machst. Meine Programme werden von mal zu mal besser, vielleicht komme ich irgendwann auch auf eine
saubrere Lösung.
Schöne Diskussionen in diesem Thread, bin begeistert.
