+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: sinnvolle Datenstruktur für Programmparameter (/Thread-sinnvolle-Datenstruktur-fuer-Programmparameter)
sinnvolle Datenstruktur für Programmparameter - dimitri84 - 29.10.2011 10:44
Hallo,
ich bin sehr unzufrieden mit der Datenstruktur, die ich für diverse Programmparameter verwende.
Beispiel Grenzwerte:
[attachment=36810]
Cluster of Cluster of "irdendwas" (hier Array of DBL)
Dabei entspricht der (zweite) Clustername der entsprechenden Prüfung, und so suche ich mir das richtige Element anhand des Namens raus. Soweit OK - aber auch nicht toll. In der Art speichere ich auch z.B. Prüfschrittdauer - Ablaufeigenschaften (enums) - Skalierungen usw...
Problem: Ich brauche für alles auch Eingabemasken. Da ist diese Datenstruktur vollig unpraktisch - vielleicht mache ich's auch einfach zu umständlich.
[attachment=36812]
Ich brauche also für jeden Eintrag im großen Cluster einen eigenen Case, der das entsprechende Element mit neuen Werte ausstattet. Wenn sich was ändert (Grenzwert dazu/weg), muss ich auch immer das Eingabemaske.vi anpassen und dabei tierisch aufpassen. Und beim ersten Erstellen muss ich erstmal stupide 40-50 Cases handisch anlegen. Das kanns nicht sein.
Kurz: Anforderungen - Verschiedenste Datentypen / in XML abspeicherbar / Eingabemaske sollte nicht angepasst werden müssen bei Änderung des Inhalts.
Ich tendiere jetzt immer mehr dazu einfach alles als Array of String zu speichern und dann anschließend parsen. Gefällt mir jedenfalls deutlich besser diese Variante.
Wie macht ihr sowas?
Gruß Dimitri
RE: sinnvolle Datenstruktur für Programmparameter - unicorn - 10.11.2011 22:20
Ich blicke leider noch nicht ganz durch. Vielleicht wäre eine Hilfe, wenn ein Array von Cluster von Kanalname: String, Einheit: String, Obergrenze: DBL und Untergrenze:DBL für eine Messung hätte. Eins dazu oder weg wäre über die Anzahl der Array-Elemente leicht zu verwalten. Das ließe sich auch in XML darstellen. Aber ich glaube das geht mit den LabVIEW-XML-VI nicht optimal.
Struktur müsste grob so sein:
<Prüfung No="12.7" Name="Haltfunktion">
<Kanal No="1" Typ="DBL">
<Name>S_PS</Name>
<Einheit>mm</Einheit>
<Obergrenze> ... </Obergrenze>
<Untergrenze> ... </Untergrenze>
</Kanal>
<Kanal No="2" Typ="DBL">
...
</Kanal>
...
</Prüfung>
<Prüfung No="12.8" Name="...">
...
RE: sinnvolle Datenstruktur für Programmparameter - dimitri84 - 11.11.2011 07:55
Ich poste später ein "negativ Beispiel" erkläre jetzt aber nochmals mein Problem:
Früher: Wenn sich was an den Grenzwerten ändert muss ich: 1) Die Typedef anpassen 2) die aktuelle zuständige XML-Datei löschen 3) das XML_read.vi mit der aktualisierten Konstanten den Typedef ausstatten 4) die Eingabemaske auktualisieren 5) Programm starten - dabei wird neue XML Datei erstellt
Jetzt: 4) fällt weg - aktuelle Struktur "Array of String" -> Eingabemnaske muss nicht angepasst werden
Wunsch: EINE globale Instanz die ich ändere und alles andere passt sich selbst an.
Ich ahne LVOOP könnte mir da entscheidend helfen ... muss ich mal in Angriff nehmen.
RE: sinnvolle Datenstruktur für Programmparameter - IchSelbst - 11.11.2011 10:42
(11.11.2011 07:55 )dimitri84 schrieb: Früher: Wenn sich was an den Grenzwerten ändert muss ich: 1) Die Typedef anpassenKlar, muss immer sein. Egal wie du's machst.
Zitat:2) die aktuelle zuständige XML-Datei löschenIch verwendet INI-Files. Aktuelle Files muss ich also nie löschen. Die Ini-Rd/Wr-VIs muss ich anpassen. Neue Werte ergänzen sich automatisch.
Zitat:3) das XML_read.vi mit der aktualisierten Konstanten den Typedef ausstattenDas muss automatisch gehen! Verwendest du keine stricten Typen?
Zitat:4) die Eingabemaske auktualisierenWenn du das machen musst, hast du tatsächlich ein Problem. Bei stricten Typen geht das automatisch.
Beachte:
Die "Daten" liegen in einer FGV, die zu einer "Klasse" (Methoden (= Manipulation der Daten im weitesten Sinne) über Enumerator, Daten im Schieberegister, etc.etc.) aufgebohrt ist. Die FGV muss lediglich (natürlich mit allen SubVIs) in ein neues Projekt kopiert werden - fertig. Durch die FGV ist das FP (= GUI/UI der Daten) aber von den Daten getrennt - was aber eigentlich nachteilig ist. Hier hilft möglicherweise LVOOP weiter.
RE: sinnvolle Datenstruktur für Programmparameter - IchSelbst - 11.11.2011 11:15
Nachtrag:
Zitat:Problem: Ich brauche für alles auch Eingabemasken. Da ist diese Datenstruktur vollig unpraktischIch verwendet als "Eingabemaske" direct den stricten Cluster. D.h. also: Ein Eventcase pro Cluster!
Zitat:Ich brauche also für jeden Eintrag im großen Cluster einen eigenen CaseGenau deswegen bin ich ja dazu übergegangen, alles mit dem stricten Cluster zu machen.
[*grübel*]
Ob mit LVOOP es nicht doch auch notwendig ist, pro Element einen Case (wo auch immer) zu haben, kann ich auf die schnelle nicht beantworten.
Zitat:Ich tendiere jetzt immer mehr dazu einfach alles als Array of String zu speichern und dann anschließend parsen.Das wäre den Teufel mit dem Beelzebub austreiben! Stringverarbeitung!
RE: sinnvolle Datenstruktur für Programmparameter - dimitri84 - 12.11.2011 11:35
(11.11.2011 10:42 )IchSelbst schrieb: Ich verwendet INI-Files. Aktuelle Files muss ich also nie löschen. Die Ini-Rd/Wr-VIs muss ich anpassen. Neue Werte ergänzen sich automatisch.XML stand glaub ich im Lastenheft (Größenordnung Telefonbuch).
Zitat:Das muss automatisch gehen! Verwendest du keine stricten Typen?Neue Einträge, ja. Wenn man aber Einträge löscht, "verrutschen" schonmal Standardwerte. Und viel öfter hab ich den Fall, dass die Anzahl der Elemente gleich bleibt aber der Standardwert sich ändert - und da helfen die striktesten Typedefs nix. Da müsste LVOOP helfen glaube ich.
Zitat:Ich verwendet als "Eingabemaske" direct den stricten Cluster. D.h. also: Ein Eventcase pro Cluster!
Zitat:Das wäre den Teufel mit dem Beelzebub austreiben! Stringverarbeitung!
Genau das mit dem "Ein Case pro Element" vermeide ich ja durch die Stringverarbeitung. Ist schonmal ein bisschen weniger Arbeit. Und: Ein array of String ist auch im xml-file für einem normalen Menschen lesbar, wenn er in etwa weiß was die Zahlen bedeuten.
Ich versuch mal demnächst mit NI darüber zu sprechen. Ich komme da auf keinen befriedigenden Zweig.
RE: sinnvolle Datenstruktur für Programmparameter - unicorn - 12.11.2011 23:04
Wenn Du einen die vertikal zusammengehörigen Wert in einen Cluster steckst (wie schon gesagt: Cluster von Kanalname: String, Einheit: String, Obergrenze: DBL und Untergrenze:DBL) und diese Cluster in ein Array steckst, kann Dir beim Editieren nicht mehr gegeneinander verrutschen. Da dieser Cluster über all zu finden ist, brauchst Du auf nur genau eine Eingabemaske. Mit "Blättern"-Funktion wird dann einfach das nächste Array-Element geholt angezeigt und ggf editiert. Oder sehe ich das falsch?
RE: sinnvolle Datenstruktur für Programmparameter - dimitri84 - 15.11.2011 22:33
Sorry für die späte Antwort.
(12.11.2011 23:04 )unicorn schrieb: Wenn Du einen die vertikal zusammengehörigen Wert in einen Cluster steckst (wie schon gesagt: Cluster von Kanalname: String, Einheit: String, Obergrenze: DBL und Untergrenze:DBL) und diese Cluster in ein Array steckst, kann Dir beim Editieren nicht mehr gegeneinander verrutschen. Da dieser Cluster über all zu finden ist, brauchst Du auf nur genau eine Eingabemaske. Mit "Blättern"-Funktion wird dann einfach das nächste Array-Element geholt angezeigt und ggf editiert. Oder sehe ich das falsch?Siehst du richtig. Das mit dem "Case pro Element" ist dann erledigt.
Für das globale Verstellen der Standardwerte muss ich mich langsam mit LVOOP anfreunden. Die XML müssen immer neu ... ist halt so. Nagut.
Blöd ist auch. Ich soll nur LV-Bibliotheken verwenden. Kein OpenG oder Ähnliches ... Da gibt's ja auch interessates Ini Zeugs.
RE: sinnvolle Datenstruktur für Programmparameter - unicorn - 15.11.2011 23:39
(15.11.2011 22:33 )dimitri84 schrieb: ..
Für das globale Verstellen der Standardwerte muss ich mich langsam mit LVOOP anfreunden. Die XML müssen immer neu ... ist halt so. Nagut.
Blöd ist auch. Ich soll nur LV-Bibliotheken verwenden. Kein OpenG oder Ähnliches ... Da gibt's ja auch interessates Ini Zeugs.
Du brauchst eine Möglichkeit aus dem Array die Werte in eine Datei zu schreiben (INI oder XML) und wieder zu lesen. Dann kannst Du die XML-/INI-Datei in einem Editor bearbeiten und neue Standardwerte eintragen. Alternativ kann man dann auch die Standardwerte in einem VI bearbeiten.
Anbei ein Ansatz für XML mit den XML-Parser-VIs.