Variant entschlüsseln mit TypeDef-Speicherpfad

Gibt es eine Möglichkeit, anhand des Pfades an dem ein TypeDef gespeichert ist, dessen genauen Aufbau zu erkennen?


Ich habe 2 Eingangswerte :

- Einen Variant in dem sich ein beliebiges TypeDef befindet.
- Der Pfad an dem das im Variant befindliche Typedef gespeichert ist.


Ich möchte jetzt mit diesen beiden Informationen aus dem beliebigen Typedef im Variant einen menschen-lesbaren String erstellen.

Anzeige

Hallo D,

Gegenfrage: was willst du mit der Kenntnis des Typdefs denn anfangen?

- Der DATAFLOW mit seinen streng typisierten Daten verlangt einen eineindeutigen Draht, der aus dem FromVariant herauskommt. Mit einem einzigen FromVariant wirst du also nicht verschiedene TypDefs auflösen können...
- Du könntest mit dem (Pfad des) TypDefs eine Case-Struktur aufrufen, die je nach gewähltem TypDef die passende Wandlung vornimmt - du erhälst dann aber auch entsprechend viele Ausgangstunnel in dieser Case-Struktur...
- Du könntest dir überlegen, ob es nicht sinnvoller ist, alle nötigen Informationen in einen einzigen typdefinierten Cluster zu packen! Man muss ja nicht immer alle Elemente eines Cluster auch wirklich nutzen...

Ich habe verschiedene VI's die ich per Referenz aufrufe und die daher ein identisches Pattern haben. Unter anderem je einen Variant-Eingang und einen Variant-Ausgang. Für jedes dieser VIs definiere ich 2 Typedefs die die Eingangs- bzw. Ausgangs-Parameter darstellen und als Variant in das VI hinein bzw. aus dem VI herausgeleitet werden.

Die Applikation soll später durch weiterer dier VIs erweitert werden können. Diese haben dann jeweils wieder einen Typedef als Eingangsparameter und einen Typdef als Ausgangsparameter


Der Datenlogger der alle Aktivitäten mitschreibt sollte aber eigentlich nicht mehr angefasst werden. Deshalb hatte ich gehofft das es eine Möglichkeit gibt alle Typedefs, auch die neuen, automatisch zu entschlüsseln.

Das Einzige was mir nu einfällt ist, dass der Logger wiederum VIs per Referenz aufruft die die Wandlung vornehmen und das ich für jedes VI das ich neu schreibe auch jeweils ein zugehöriges Wandler-VI erzeuge.

Hallo D,

Zitat:Das Einzige was mir nu einfällt ist, dass der Logger wiederum VIs per Referenz aufruft die die Wandlung vornehmen und das ich für jedes VI das ich neu schreibe auch jeweils ein zugehöriges Wandler-VI erzeuge.

Dann bekommst du doch wieder einen jeweils anders typisierten Draht von diesem VI... Wie willst du damit weiterkommen?

Noch ein Vorschlag:
Verwende einen "generischen" Datentyp (wie String) und nutze eine passende Formatierung (XML? JSON?), um "beliebige" Daten zu übertragen. Dann hast du zumindest nicht das Problem, ein unbekanntes Variant wandeln zu wollen...

Ich meinte ein SubVI (pro neuen Typedef) für den Logger wo der Typdef als Variant reingeht und der zu speichernde String rauskommt.


Über das Senden von XML-Strings müsste ich mal weiter nachdenken. Aber das macht die Sache doch schon sehr komplizierter für jeden der ein neues VI schreibt oder?
Diese Umwandlung kann ich ja auch nicht in einem einzigen Support-VI machen da sie für jeden Datentyp anders ist.

Hallo D,

das kommt darauf an, was du genau vorhast...

LabVIEW hat da schon einige Funktionen: XML VIs and Functions

Zitat:Ich meinte ein SubVI (pro neuen Typedef) für den Logger wo der Typdef als Variant reingeht und der zu speichernde String rauskommt.

Dann kannst du dir das Variant doch gleich sparen und lässt dir von Anfang an den String ausgeben...

Anzeige

Hm, wenn das beides geht...was ist dann der Zweck eines Variants: denknach:


Sind da bei der XML-Variante noch irgendwelche Stolpersteine versteckt auf die ich später Stoße ?

- Geht für weniger Datentypen
- Performance-Einbruch
- etc ?

Hallo D,

deine beiden gezeigten Varianten (XML vs Variant) haben beide immer noch das selbe, schon zuvor genannte Problem: du musst die Typdefinition kennen, um wieder die Originaldaten (als Draht) in LabVIEW zu erhalten. Und dann landest du wieder bei dem schon genannten Problem der strengen Typisierung, die effektiv verhindert, dass verschiedenen TypDefs auf dem selben Draht transportiert werden (können)...

- Das XML hat den Vorteil, Menschen-lesbar zu sein, beim Variant erhälst du irgendwelche LV-internen Verwaltungsstrukturen.
- Das Variant hat den Vorteil, etwas kompakter als das XML zu sein.

Du solltest noch mal überlegen, was du wirklich haben willst. Du fängst aber (mMn) an der falschen Stelle an zu schrauben, wenn du einen (quasi) unbekannten Datentyp per Variant überträgst und diesen dann nachträglich wieder in "lesbaren" Text umwandelst...

(29.11.2013 09:13 )GerdW schrieb:  deine beiden gezeigten Varianten (XML vs Variant) haben beide immer noch das selbe, schon zuvor genannte Problem: du musst die Typdefinition kennen, um wieder die Originaldaten (als Draht) in LabVIEW zu erhalten. Und dann landest du wieder bei dem schon genannten Problem der strengen Typisierung, die effektiv verhindert, dass verschiedenen TypDefs auf dem selben Draht transportiert werden (können)...

Nein, tatsächlich glaube ich das du mein Problem gelöst hast. Ich bin nur gescheitert das Problem richtig zu erklären.


Die TypDef ist im Main und im Plugin bekannt, da sie vom Programmierer neu hinzugefügt werden. Nur der Logger weiß nichts von den neuen Typdefs, weil er im "Frame" fix integriert ist.
Wenn ich nun die Nachrichten per XML verschicke, kann der Logger sich aber alles wichtige rausziehen.

Gern geschehen!