LabVIEWForum.de
VI, das als Eingang einen unbekannten Cluster hat - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: VI, das als Eingang einen unbekannten Cluster hat (/Thread-VI-das-als-Eingang-einen-unbekannten-Cluster-hat)



VI, das als Eingang einen unbekannten Cluster hat - Matze - 16.08.2010 09:17

Hallo zusammen,

ich möchte eine Art Protokoll definieren. Dazu dachte ich mir, dass ich einen Cluster nehme (Typndefinition), der boolsche Elemente (Bit), Integer-Elemente und Double-Elemente beinhalten kann.
Da möchte ich z.B. definieren, dass bei einem Ethernetprotokoll das erste Byte aus 8 einzelnen Bits besteht, das 2. ein Int8 ist, das 3. und 4. Byte ein Int16 und Byte 5 - 8 ein Int32.
Im Endeffekt möchte ich das hier allgemein umsetzen (Quelle: ni.com):

[attachment=28762]

Da kam ich auf die Idee mit dem allgemeinen Cluster. Ich möchte nicht jedesmal ein neues SubVI erstellen müssen. Wenn das mal 100 Byte sind, wird das sonst zu komplex und ist kaum wartbar.
Nun dachte ich an ein VI, das als Eingang diesen Cluster hat und als Ausgang ein Array, das die Daten für das Protokoll aufbereitet enthält.
Nur wie kann ich denn einen ganz allgemeinen Clustereingang definieren, der jeden Cluster akzeptiert?
Diesen möchte ich dann allgemein aufschlüsseln und je nach Inhalt die entsprechenden Array-Werte zusammensetzen (wie im oben angehängten Screenshot).


VI, das als Eingang einen unbekannten Cluster hat - GerdW - 16.08.2010 12:17

Hallo Mecha,

LabVIEW arbeitet streng typisiert - und ein Cluster ist nun mal eine feststehende Typdefinition. Da kannst du nicht beliebige Cluster an den Eingang eines subVIs anschließen.

Solange die Anzahl der unterschiedlichen Cluster überschaubar bleibt, kannst du ein polymorphes VI erstellen. Ist im Grunde eine Sammlung von unterschiedlichen subVIs, die deine unterschiedlichen Clusterdefinitionen bearbeiten.

Ansonsten kannst du noch mit Variants rumprobieren oder mit "flattened strings". Vielleicht geht sowas auch mit LV-OOP, aber da muss ich mich erst noch reinarbeiten...


VI, das als Eingang einen unbekannten Cluster hat - Matze - 16.08.2010 12:57

Hallo Gerd,

das dachte ich mir schon fast. Ein polymorphes VI kommt nicht in Frage, da der Aufbau des Protokolls beliebig sein kann.

Hast du eine Idee, wie ich allgemein so ein Protokoll definieren könnte?
Also dass ich sage, das erste Byte sind 8 einzelne Bits, das zweite soll als Int8 interpretiert werden etc?

Ich möchte damit erreichen, dass ich das Protokoll möglichst einfach definieren kann ohne jedesmal umfangreiche VIs dafür schreiben zu müssen.


VI, das als Eingang einen unbekannten Cluster hat - GerdW - 16.08.2010 13:22

Hallo Mecha,

willst du jetzt einmal ein Protokoll definieren oder ständig neue entwerfen???

Wie ich es jetzt interpretiere, hast du einen Bytestream, den du interpretieren willst.
Dabei erzeugst du jedoch jedesmal einen neuen/anderen (Ausgangs-)Cluster. Und das ist ohne Weiteres (d.h. LV-Skripting) nicht möglich. Du musst also zwingend für jeden zu erzeugenden Datentyp ein subVI erstellen...


VI, das als Eingang einen unbekannten Cluster hat - Matze - 16.08.2010 13:40

Hallo Gerd,

je nach Anwendung variieren die zu übertragenden Daten.

Maschine 1 hat einen Bytestream, der anders aussieht als der von Maschine 2.

Daher muss ich das laufend machen (also alle paar Wochen). Pro LabVIEW-Anwendung ist es natürlich fest.
Wenn ich da nun 100 Bytes habe und diese jedesmal von Hand in einem neuen SubVI zerlegen und in einem weiteren SubVI zusammen fügen muss, ist das sehr aufwändig.
Im Endeffekt gehören immer 2 SubVIs zusammen. Das eine macht jedoch genau das Gegenteil vom anderen (zusammen fügen: Cluster -> Array, zerlegen: Array -> Cluster).


VI, das als Eingang einen unbekannten Cluster hat - cb - 16.08.2010 14:26

LV Scripting ist in diesem Fall vermutlich auch keine Lösung, weil Scripting zur zur Entwicklungs-Zeit zur Verfügung steht. Zur Laufzeit kann man nichts mehr scripten.

Vermutlich willst du den "anythin"-Eingang haben, an den man alles anklemmen kann, wie z.B. bei der "to Variant"-Primitive. Wenn du das haben willst, musst du dich wohl oder übel mit X-Nodes beschäftigen. Am besten schreit jetzt gleich der Rolf "Halt, ne, stop, mach das nicht, da kommst du in Teufels Küche" und vermutlich hat er rechtBig Grin... für ein Produktiv-System würde ich die auch auf keinen Fall verwenden.

Last but not least bleibt noch die Möglichkeit, alle Daten, die über das Protokoll übertragen werden sollen in einen Variant umzuwandeln, das ist der einzige, "variable" Datentyp in LabVIEW und den Variant mit einem Enum in einen Cluster zu stecken, der dem Empfänger mitteilt um was für Daten es sich handelt.

Wenn du es generisch aufbauen willst, dann eignet sich vielleicht LVOOP, ich kann jetzt aber nicht abschätzen, wieviel Arbeit das wird, das hängt hauptsächlich davon ab, wieviel unterschiedliche Datentypen du generieren willst und wieviel Override-Methoden du dazu schreiben musst ...


VI, das als Eingang einen unbekannten Cluster hat - Matze - 16.08.2010 14:51

Hallo,

mein Ansatz sieht nun wie folgt aus:

Ich habe eine Typendefinition, die das Protokoll definiert:

[attachment=28771]

Das Protokoll besteht immer aus 4-Byte-Blöcken und die Definition der Blöcke erfolgt in dem gezeigten Array. In dem Fall enthält das 0. Byte 8 einzelne Bits, das 1. und 2. Byte wird als eine I16-Zahl interpretiert und das 3. Byte als Character.

Analog dazu habe ich eine Typendefinition für die Daten erstellt. Je nachdem, was im Protokoll definiert ist, wird der entsprechende Wert bzw. die Werte ausgewertet:

[attachment=28772]

Bei der obigen Definition hier bei Byte 0 die 8 einzelnen Bits. Die nummerischen Felder werden ignoriert.

Noch bin ich mir nicht sicher, wie ich das nun in einem SubVI "verkuddeln" kann, aber ich probiere da etwas herum.