Aufbau Frontpanel mit sehr vielen Tabs, speichern aller Parameter in XML

(15.02.2011 10:50 )mikeee schrieb:  Gut, es muss also nicht reentrant sein.

es darf nicht ...

Zitat:Scheint mir klar, da sonst das VI mehrfach gleichzeitig laufen kann und dadurch der Trick entfällt

Letztendlich hast du recht. Nur: was meinst du hier mit Trick?

Zitat:Habe in diesem Zusammenhang nochmals über die Semaphore nachgedacht und festgestellt, dass es so wie ich wollte völliger quatsch ist.

Zitat:(d.h. ich kann direkt eine Untermenge der Daten ändern ohne davor Daten lesen zu müssen)

Das läuft auf "atomar gekapselt" hinaus.

Zitat:Ein VI mit einem Eingang für jeden dieser Sätze (COMOptionen, CANOptionen)

Nachteil: Beschränkung durch Anzahl der Eingänge.

Zitat:Ein polymorphes VI (eigene Abhandlung für COMOptionen Cluster und für CANOptionen Cluster) das dann wieder auf immer die selbe FGV zugreift

Nachteil: im (polymorphen) VI muss das FGV aufgerufen werden => Variante 1

Zitat:Ein VI mit Variant als Eingang für die Datensätze und einem Eingang um die Funktion zu steuern.

Zitat:Jetzt frage ich mich bei Variant: ...

Die einfachste Lösung ist Version 3: Variant + Fkt.
Alle anderen Versionen sind mit Mehraufwand verbunden. Du müsstest, grob gesagt, den Datencluster und den Typ des Datencluster zu einem neuen Typ zusammenfassen und dieses dann als Variant übergeben. Auf der anderen Seite (der Schnittstelle) müsstest du per Case-Anweisung den Eingangsvariant wieder decodieren. Besonders letzteres ist mit relativ viel Aufwand verbunden. Mit Fkt wird der "Typ der Daten" quasi explizit übergeben.
Vorteil der Funktion ohne Fkt: Vom Grundsatz scheinbar besser scalierbar. Nur ein Parameter.
Vorteil der Funktion mit Fkt: wesentlich einfacher - vor allem aber ausreichend für die Anwendung. In wie weit diese Version gut scalierbar ist, ist eine andere Frage.

Zitat:Den Datenausgang halte ich wohl als Cluster, gebe immer alles aus und trenne dann mit "Unbundle by name".

Anzeige