Seriellen Datenstrom in hierachischen Cluster parsen

Hallo Leute,
noch eine Frage:

Über die serielle Schnittstelle erhalte und sende ich einen Datenstrom (1D- U8-Array).
Diese soll in und aus einem hierachischen Cluster mit unterschiedlichen Datentypen (Float[4][6], Int32, String, Int32, UInt16[4],...) geschrieben werden.

Ich habe die Funktion flatten/unflatten schon gefunden, allerdings enthält mein Bytestrom keine Header in denen die Längen angegeben sind, somit fällt diese Variante flach.

Nun ist es ziemlich aufwendig den Datenstrom einzeln aufzudröseln bzw. zusammenzustricken und in den Cluster zu schreiben.

Gibt es eine Möglichkeit einen Bytestrom direkt in ein Cluster zu geben/nehmen, ohne diese Header mit Längenangaben?
Kann ich LV irgendwie auf schnellem Wege beibringen, wie der Bytestrom interpretiert werden soll?

Danke Danke

tank

' schrieb:Ich habe die Funktion flatten/unflatten schon gefunden, allerdings enthält mein Bytestrom keine Header in denen die Längen angegeben sind, somit fällt diese Variante flach.

Wieso fällt das flach? Flatten To String hat einen Eingang "Prepend Array Size" ( http://zone.ni.com/reference/en-XX/help/37...tten_to_string/ ). Dort ein False angeschlossen, und dein Cluster wird dir in einen U8-String umgewandelt. Jetzt musst du in der Definition des Clusters mit deinen Arrays nur auf die richtige Reihenfolge achten.

Alternativ, in der selben Palette, in der du Flatten To String gefunden hast, gibt es noch Typecast: http://zone.ni.com/reference/en-XX/help/37...lang/type_cast/

Gruß, Jens

' schrieb:Wieso fällt das flach? Flatten To String hat einen Eingang "Prepend Array Size" ( http://zone.ni.com/reference/en-XX/help/37...tten_to_string/ ). Dort ein False angeschlossen, und dein Cluster wird dir in einen U8-String umgewandelt. Jetzt musst du in der Definition des Clusters mit deinen Arrays nur auf die richtige Reihenfolge achten.

Desswegen schrieb ich auch hierachischer Cluster. Denn da wird immer die Array-Größe eingefügt.

' schrieb:Alternativ, in der selben Palette, in der du Flatten To String gefunden hast, gibt es noch Typecast: http://zone.ni.com/reference/en-XX/help/37...lang/type_cast/

Kann ich bei Typcast denn auch einen hierachischen Cluster als Umwandlungstyp angeben?

Hallo Tanka,

"Desswegen schrieb ich auch hierachischer Cluster."
Kannst du das mal genauer erläutern? Evtl. mit einem Link? Dieser Begriff (dieses Konzept) ist mir bisher noch nicht untergekommen...
Vielleicht einfach mal ein Beispiel(-CTL) anhängen?

Hallo, Tanka,

ich sehe gerade, meine Tipps waren nicht gut... Typecast mag einen solch verschachtelten Cluster nicht als Eingang, und bei FlattenToString sind trotz Eingang True doch die Array-Größen im ByteStream drin:
   

:hmm:Dann fällt mir nur auf die Schnelle ein, jedes Element des Clusters einzeln zu (Un)Flatten, und dann zusammenzusetzen.

Gruß, Jens

Also ich bin da immer ganz auf Nummer sicher gegangen und habe es so gemacht:
   
Aber wenn mir jemand nachweisen kann, daß das zu umständlich ist, würde ich demjenigen gern per Knopfdruck ein "Danke" spendieren..

  Cluster_to_RS232.vi (Größe: 9,33 KB / Downloads: 240)

Auch diese Variante enthält die Array- und String-Größen im ByteStream.
   
Genau das will tanka nicht haben.

Gruß, Jens

@lucki:
An den Variant Datentyp dachte ich auch schon, allerdings ist mir auch bei diesem Datentyp nicht ganz ersichtlich, woher LV weiß, wie der eingehende Datenstrom zu interpretieren ist.

Gut wäre wenn ich z.B per Cluster-Konstante meine Datenstruktur vorgebe und der Bytestream dann entsprechend interpretiert wird.

@Gerdw:
Hier ein Auszug aus der Hilfe zur Problematik. Was genau meinst du mit CTL?

       


PS: Ich würde ja gerne auf ein Protokoll mit Header-daten umsteigen, leider kann das meine Gegenstelle nicht.

Hallo tanka.

danke für den Hinweis zu den "hierarchischen Clustern"...

Dank der LV-Hilfe bin ich jetzt auch schlauer: Cluster sind ein sogenannter hierarchischer Datentyp.
Du hättest das also nicht extra betonen müssen - es gibt gar keine nicht-hierarchischen Cluster

CTL: Dateiendung für TypeDefinitions. Du hättest einen Cluster als Typedefinition speichern können, dabei erhälst du ein CTL-File...

' schrieb:Genau das will tanka nicht haben.

Ich interpretiere tanka aber so, daß er den Inhalt eines komplizierte Cluster mit allem Möglichen drin - drunter auch Arrays und andere Cluster - über eine serielle Schnittstelle möglichst problemlos übertragen haben möchte. Problemlos verstehe ich hier so, daß er nicht Lust hat, auf der Sendenseite einen Header zu programmieren, diesen den Daten voranzuschicken und auf der anderen Seite diesem Haeder dann erst analysieren zu müssen, damit die Daten dann interpretiert werden können.
Ja, richtig, es befinden sich Zusatzinformationen im String, von mir aus nennen wie sie Header. Aber das Entscheidende ist doch, daß niemand (Programmier-) Arbeit damit hat.
Falls Du aber Recht haben solltest, dann kann ich nur sagen: Dann ist das eine willkürliche, schikanöse Vorgabe von tanka, und ich hätte mir nie die Mühe gemacht, auf diesen Beitrag zu antworten..


Edit:

Zitat:An den Variant Datentyp dachte ich auch schon, allerdings ist mir auch bei diesem Datentyp nicht ganz ersichtlich, woher LV weiß, wie der eingehende Datenstrom zu interpretieren ist.

LV weiß das aus der Typbeschreibung. Und da diese immer gleich ist (auch bei variabler Arraylänge im Cluster usw.), muß diese nicht mit übertragen werden, es ist eine Konstante. Und wie man diese erstellt, habe ich ausführlich beschrieben. Aber trotzdem: Wenn Du dazu noch eine Frage hast, gerne..