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

Ein herzliches hallo an alle LVF-Mitglieder,

ich bin neu hier und meine LabView-Fertigkeiten sind noch lange nicht meisterhaft. Ich habe zwar schon einige Dinge in LV programmiert aber das ist schon zwei Jahre her und es waren auch nur zirka 200 Stunden Arbeit. Jetzt habe ich wieder eine grössere Arbeit in LabView vor mir und dazu mal die erste Frage.

Er geht um ein Frontpanel auf dem sehr viele Einstellungen gemacht werden sollen. Die Controls sind über mehrere Tabs verteilt, die jeweils wieder Untertabs beinhalten. Alle diese Einstellungen sollten schlussendlich in einem Cluster zusammengefasst werden, damit sie zum einen an die Steuerung der Software weitergegeben werden können und auch um die ganzen Einstellungen in einem XML zu speichern. Natürlich sollen die Einstellungen auch wieder von diesem XML geladen werden können. So, dass die Werte in den Controls stehen.

Um die Übersicht zu gewährleisten habe ich mir überlegt die Inhalte der Tabs in VIs auszulagern, die dann über "Display Sub-VI" ins Hauptprogramm eingebunden werden. All diese Sub-VIs geben dann ihre Einstellungen weiter und diese werden dann im Hauptprogramm zu einem Cluster zusammengefasst und gespeichert.

Ist das ein guter Ansatz? Oder würdet ihr etwas anderes vorschlagen?

Wie gehe ich vor um die Einstellungen wieder in die Controls zu laden? Über die "Property Node" der Controls?

Hat jemand Erfahrung damit solche Einstellungen als XML zu speichern? Was für ein Ansatz ist da zu empfehlen?

Gruss Mikeee

Anzeige

(13.02.2011 14:46 )mikeee schrieb:  Um die Übersicht zu gewährleisten habe ich mir überlegt die Inhalte der Tabs in VIs auszulagern, die dann über "Display Sub-VI" ins Hauptprogramm eingebunden werden. All diese Sub-VIs geben dann ihre Einstellungen weiter und diese werden dann im Hauptprogramm zu einem Cluster zusammengefasst und gespeichert.
Ist das ein guter Ansatz? Oder würdet ihr etwas anderes vorschlagen?

ich mach das auch so, aber SubPanels Einbinden ist deutlich mehr Aufwand als das über Tabs zu lösen. Dafür ist die Programmierung deutlich übersichtlicher und strukturierter. Aber man muss sich Gedanken drüber machen wie die Daten in die SubPanels übergeben werden. (Queues, Globale Variablen, aus Datei lesen, etc ... gibt viele Möglichkeiten ...)

(13.02.2011 14:46 )mikeee schrieb:  Wie gehe ich vor um die Einstellungen wieder in die Controls zu laden? Über die "Property Node" der Controls?

Wenn du mit dem Control sonst noch was "anstellen" willst, wie verstecken oder disablen (sry für das denglisch), dann kannst du auch gleich die Property "Value" verwenden und alles in einem Aufwasch erledigen. Wenn du nur den Wert des Controls setzen willst kannst du auch eine lokale Variable benutzen.

(13.02.2011 14:46 )mikeee schrieb:  Hat jemand Erfahrung damit solche Einstellungen als XML zu speichern? Was für ein Ansatz ist da zu empfehlen?

Ich speicher die Daten auch alle in einem Cluster und den Cluster wiederum ganz stumpf als Binär-Datei auf der Platte. XML wäre praktisch wenn man noch von anderen Programmen aus auf die Konfigurations zugreifen wollte. Wenn die Konfig nur aus LV heraus gelesen und geändert werden soll kann man die Daten auch gleich binär speichern - nimmt weniger Platz weg und man läuft nicht Gefahr, dass man Probleme mit dem Paring bekommt, etc ...

Grüße
CB

Vielen dank cb für deine Antwort.

Ich habe mal ein bisschen über Möglichkeiten des Datenaustausches mit den SubPanels gelesen. Dabei bin ich auf diesen Artikel gestossen: http://zone.ni.com/devzone/cda/epd/p/id/6249
Da werden die Daten in Objects verpackt. Tönt eigentlich ganz gut aber ich frage mich ob sich der Aufwand lohnt sich darin einzulesen. Hat jemand von euch Erfahrung damit? Oder wie würdet ihr den Datenaustausch bewerkstelligen? Ich habe immer gesagt gekriegt nie Globale Variablen zu verwenden. Höchstens Functional Globals (obschon ich nicht mal weiss was der Unterschied ist).

Die Lösung mit den SubPanel hat auch den Vorteil, dass ich alle SubPanels über einen Property Node blockieren kann sobald der Test gestartet wurde. So ist auch sichergestellt, dass nicht mehr an den Einstellungen geändert wird.

Es ist mir vorgegeben worden die Einstellungen als XML zu speichern, damit sie von Hand mit einem Editor angepasst werden können. INI müsste da eigentlich auch gehen. Das wäre allenfalls eine Alternative.

(14.02.2011 11:46 )mikeee schrieb:  Höchstens Functional Globals (obschon ich nicht mal weiss was der Unterschied ist).

Na, dann mach dich mal schlau.

Datentechnisch gesehen stellt eine FGV eine "globale Variable" dar. Programmtechnisch gesehen ist eine FGV ein SubVI, das in einem Schieberegister (auf While-Schleife) Daten enthält. Weil es ein (nicht-reentrantes) SubVI ist, können zwei Datenflüsse nicht gleichzeitig auf die Daten zugreifen - das beugt RaceConditions vor.
In einer FGV kann man auch Funktionen integrieren - wie z.B. das Speichern der Daten in einer Datei.
Eine FGV kann also hinsichtlich Funktionalität (Property etc.) und Kapselung (welche Daten außerhalb der FGV (des SubVIs) zugänglich sind, entscheidet alleine die FGV) als Klasse betrachtet werden.

Ich selbst verwende FGVs sehr gerne - eben so wie SubPanels und TabSheets. Nur XML mag ich nicht. Ich mach alles in INI.

(14.02.2011 12:20 )IchSelbst schrieb:  ... Weil es ein (nicht-reentrantes) SubVI ist, können zwei Datenflüsse nicht gleichzeitig auf die Daten zugreifen - das beugt RaceConditions vor.

Es darf bzw. muss je nach Einsatz reentrant sein und verhindern wird es RaceConditions nicht "einfach so".
Sorry, das ich so pingelig bin, aber ich lese/höre das, so oder ähnlich, schon seit Jahren und es wird einfach nicht richtiger.
FGVs haben (hatten) ihre Berechtigung, sind aber meiner Erfahrung nach, häufig "overused", falsch benutzt und/oder irgendwann die Skalierbarkeitsbremse.

Ich danke IchSelbst für die Antwort. Habe jetzt mal über Functional Globals gelesen. Gefällt mir gut!

Mein aktueller Plan lautet folgendermassen:

Ich erstelle eine Type Definition mit einem Cluster, das alle Einstellungen enthält. Dann erstelle ich einen FG mit der Type Definition als Ein- und Ausgang. Die FG hat dann folgende Funktionen:

- Daten schreiben
- Daten lesen
- Locken (man kann nur noch lesen, das ist aktiv, wenn der Test läuft, damit nichts mehr an den Einstellungen geändert werden kann. Gleichzeitig werden über diesen Zustand die Subpanels Grey-out, damit nichts geändert werden kann)
- unlock
- GetIfLocked (um damit die Subpanels greyouten)
- PendSemaphore
- ReleaseSemaphore (für denn Fall, dass es irgendwo eine critical section geben sollte)
- Daten in XML schreiben
- Daten von XML lesen

Was meint ihr zu meinem Plan?

macmarvin, das ist ein guter Hinweis. Daher habe ich auch noch die Option mit der Semaphore eingebaut. Liege ich richtig in der Annahme, dass ich damit auf der sicheren Seite bin?
Was würdest du den alternativ vorschlagen? Ich denke ja noch immer an Klassen herum. Intuitiv scheinen mir die wohl die sauberste Lösung zu sein. Aber intuitiv scheinen mir die auch nicht gerade die einfachste zu sein. FGs habe ich in ein paar Minuten verstanden (zumindest mal den Grundsatz) aber Klassen scheinen mir noch weiter weg (obschon ich die aus C++ und Java kenne und anwende)

(14.02.2011 14:08 )mikeee schrieb:  Ich erstelle eine Type Definition mit einem Cluster, das alle Einstellungen enthält.

Alle Parameter in einem Cluster hat einen Nachteil: Was tun, wenn Parameter auf unterschiedlichen TabSheets liegen ...

Ich fasse Parameter immer clusterweise so zusammen, dass z.B. ein Anzeige- oder Bedienelement direkt an der FGV hängen kann. Mehrere solche Cluster können natürlich wieder in einem Hauptcluster zusammengefasst werden.

Als Dateneingang in eine FGV nehme ich jetzt nur noch Variant. Das reduziert die Anzahl der notwendigen Eingänge auf zwei: "Daten" und "Funktion".

(14.02.2011 14:00 )macmarvin schrieb:  

(14.02.2011 12:20 )IchSelbst schrieb:  ... Weil es ein (nicht-reentrantes) SubVI ist, können zwei Datenflüsse nicht gleichzeitig auf die Daten zugreifen - das beugt RaceConditions vor.

Es darf bzw. muss je nach Einsatz reentrant sein und verhindern wird es RaceConditions nicht "einfach so".
Sorry, das ich so pingelig bin, aber ich lese/höre das, so oder ähnlich, schon seit Jahren und es wird einfach nicht richtiger.
FGVs haben (hatten) ihre Berechtigung, sind aber meiner Erfahrung nach, häufig "overused", falsch benutzt und/oder irgendwann die Skalierbarkeitsbremse.

reentrante FGVs bringen rein goa nüscht, weil für JEDES Vorkommen eines reentranten VIs im BD eine eigene Instanz erstellt wird. Dann kannst du genau die Daten an der einen Stelle im BD lesen und speichern, aber ganz bestimmt keinen Daten-Austausch zwischen unterschiedlichen VIs im Sinne einer Globalen Variablen damit bewerkstelligen.

(14.02.2011 12:20 )IchSelbst schrieb:  ... Weil es ein (nicht-reentrantes) SubVI ist, können zwei Datenflüsse nicht gleichzeitig auf die Daten zugreifen

ist auf jeden Fall richtig, darüber streiten können wir ob es tatsächlich Race Conditions verhindert, ich denke, es hilft sie durchaus zu vermeiden, 100%ig sicher ist man aber auch nicht ...

   

(14.02.2011 22:29 )cb schrieb:  reentrante FGVs bringen rein goa nüscht, weil für JEDES Vorkommen eines reentranten VIs im BD eine eigene Instanz erstellt wird. Dann kannst du genau die Daten an der einen Stelle im BD lesen und speichern, aber ganz bestimmt keinen Daten-Austausch zwischen unterschiedlichen VIs im Sinne einer Globalen Variablen damit bewerkstelligen.

...ist auf jeden Fall richtig, darüber streiten können wir ob es tatsächlich Race Conditions verhindert, ich denke, es hilft sie durchaus zu vermeiden, 100%ig sicher ist man aber auch nicht ...

Klar kann man reentrante FGVs nicht per statischer Referenzierung (VI auf Blockdiagramm) sinnvoll einsetzen. Da muss man zwingend über dyn. geöffnete VI-Referenzen und Call by Reference Node arbeiten. Das ist die eine, meiner Meinung nach schönere Möglichkeit die Skalierbarkeit von FGV basierten Stukturen/Architekturen zu erhöhen. Die wäre die FGVs intern so zu erweitern, daß sie verschiedene "Instanzdatensätze" verwalten kann, finde ich unschön und sorgt mglw. für unerwünschte bzw. unwertartete Synchronisierungspunkte.

Eine sauber aufgebaute, mit allen kritischen Funktionen atomar gekapselte FGV sorgt zu 100% für Racecondition Freiheit.
Diese Diskussion hatten wir aber galube schon (mindestens) einmal.

Gut, es muss also nicht reentrant sein. Scheint mir klar, da sonst das VI mehrfach gleichzeitig laufen kann und dadurch der Trick entfällt. Soweit klar.

Habe in diesem Zusammenhang nochmals über die Semaphore nachgedacht und festgestellt, dass es so wie ich wollte völliger quatsch ist. Ich müsste natürlich die Semaphore beantragen, dann auf die FG zugreifen und dann die Semaphore wieder freigeben. Das kann ich logischerweise nicht an die FG selbst delegieren. Gut.

Dazu aber noch folgendes: Solange ich immer eine geschlossene Einheit an Daten auf einmal schreiben kann (d.h. ich kann direkt eine Untermenge der Daten ändern ohne davor Daten lesen zu müssen) ist alles sicher. Meinst du das mit atomar gekapselte FGV?

Wenn ich für jeden Satz von Einstellungen denn ich bestimmt immer auf einmal schreiben kann (weil die entsprechenden Controlls, welche die Daten erfassen auf dem selben Tab, bzw. im selben SubPanel liegen) eine Möglichkeit haben will genau nur diese zu schreiben/ändern habe ich folgende Optionen:

- Ein VI mit einem Eingang für jeden dieser Sätze (COMOptionen, CANOptionen) und einer Funktion für jeden dieser Sätze (SchreibeCOMOptionen, SchreibeCANOptionen,...)
- Ein polymorphes VI (eigene Abhandlung für COMOptionen Cluster und für CANOptionen Cluster) das dann wieder auf immer die selbe FGV zugreift (natürliche mit Schutz dieser critical section)
- Ein VI mit Variant als Eingang für die Datensätze und einem Eingang um die Funktion zu steuern.

Jetzt frage ich mich bei Variant: Man könnte ja die Daten mit Attributen versehen (COMOptionen als Attribut und das zugehörige Cluster als Daten). Dann müsste man als Option nur noch schreiben auswählen. Intern würde dann selbst erkannt um welche Daten es sich handelt ("Get Variant Attributes"). Oder man könnte für jeden Satz (COMOptionen, CANOptionen,...) eine eigene Funktion definieren (SchreibeCANOptionen, SchreibeCOMOptionen). Dann würde intern entsprechend der type beim "Variant to Data" umgeschaltet.

Wie macht ihr das und warum?

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