Dynamischer Parser

Hallo Leute,

muss binäre Packete parsen. Wäre kein Problen, wenn die Struktur der Pakete nicht variabel wäre.
Es ist so, dass der User in der Konfiguration ZUR LAUFZEIT angibt wie das binäre Paket zu interpretieren ist. Zuerst habe ich mir gedacht alles über Switch-Case zu machen. D.h. in der Konfiguration nachschauen welchen Datentyp das erste Element hat, so viele Bytes aus dem Paket holen (z.B. mit Split String) und kasten (mit Unflatten From String). Dann schauen was das nächste Element ist und wieder und wieder, bis das komplette Paket geparst ist. Das wäre auf jeden Fall eine Möglichkeit so was zu machen.

Nur geht mir der Gedanke aus dem Kopf nicht weg, dass ich da über den Datentyp Variant genausogut den Parser gestalten kann. Da gibt es doch einen Typestring. Diesen String kann ich ein Mal zusammensetzen und mit diesem String weiterhin parsen ohne jedes Mal einzelne Element getrennt zu behandeln.

Hat es schon jemand gemacht? Gibt es noch andere Varianten? Vielleicht irgendwas mit dem rekursiven Aufruf? Oder dynamisches Laden oder sonst noch was?

Danke, eg

P.S. ich habe oben geschrieben zuerst Split, dann Unflatten. Ab LV 8.0 kann man das alleine mit dem Unflatten erschlagen, denn es gibt meinen Lieblingsausgang von diesem VI namens "rest of the binary string".

Keine Ideen dazu?

Gruß, eg

' schrieb:Keine Ideen dazu?

Gruß, eg

ouha, der Type-String ja ...
da hab ich mir auch schonmal die Zähne dran ausgebissen. Es ist nicht unbedingt "schwer", aber man muss 1. viel Ahnung vom LV Daten-Management haben und 2. viel Zeit reinstecken um den Type-String zu "entschlüsseln". Ich hab mir damals aus Zeitmangel einen anderen Weg gesucht und es bleiben lassen, weil man sich damit eine Menge zu lösender Probleme einhandelt. Das Hauptproblem ist: man muss sich selbst um die integrität seiner Daten kümmern, das macht LV ja "normalerweise" von alleine. Im Endeffekt kann man damit durchaus was "Pointer-ähnliches" basteln, sprich die strikte Typenorientierung von LV dadurch umgehen, ob das nun wirklich sinnvoll ist, sei mal dahingestellt ...

Das zweite Problem ist, dass sich die Typdefinitionen unter Umständen mit dem nächsten Release von LV ändern ... dann guckt man ganz schön dumm aus der Wäsch ...

Wenn es EINFACHE Datentypen sind (z.B. Arrays von Double, oder so), dann kann man mit dem binary String durchaus was machen, ABER: man kann ihn nirgendwo anschließen! es sei denn du begibtst dich in die Tiefen der XNodes, aber die sind IMHO nur zur Entwicklungszeit dynamisch!

Eine Option wäre die Daten in "Typenklassen" aufzuteilen und für jede "klasse" ein eigenes Modul per VI Server aufzurufen, dass dann wiederum die Daten umwandelt und z.B. über eine Queue in den Hauptprogramm schaufelt, in einer Form, dass man den Draht wieder verbinden kann ...

wie gesagt: theoretisch ist das möglich, aber es gibt viele Probleme zu lösen ...

Danke für die Antwort, ich glaube ich bleibe doch bei Switch Case, sonst verbringe ich viel zu viel Zeit damit.

Eugen

Ich habe mir überlegt doch was dazu zu sagen.

' schrieb:ouha, der Type-String ja ...
da hab ich mir auch schonmal die Zähne dran ausgebissen. Es ist nicht unbedingt "schwer", aber man muss 1. viel Ahnung vom LV Daten-Management haben und 2. viel Zeit reinstecken um den Type-String zu "entschlüsseln". Ich hab mir damals aus Zeitmangel einen anderen Weg gesucht und es bleiben lassen, weil man sich damit eine Menge zu lösender Probleme einhandelt. Das Hauptproblem ist: man muss sich selbst um die integrität seiner Daten kümmern, das macht LV ja "normalerweise" von alleine. Im Endeffekt kann man damit durchaus was "Pointer-ähnliches" basteln, sprich die strikte Typenorientierung von LV dadurch umgehen, ob das nun wirklich sinnvoll ist, sei mal dahingestellt ...

Das zweite Problem ist, dass sich die Typdefinitionen unter Umständen mit dem nächsten Release von LV ändern ... dann guckt man ganz schön dumm aus der Wäsch ...

Sehr schade, dass es sich von Version zu Version ändern kann.

' schrieb:Wenn es EINFACHE Datentypen sind (z.B. Arrays von Double, oder so), dann kann man mit dem binary String durchaus was machen, ABER: man kann ihn nirgendwo anschließen! es sei denn du begibtst dich in die Tiefen der XNodes, aber die sind IMHO nur zur Entwicklungszeit dynamisch!

Normalerweise sind es bei mir zusammengesetzte Datentypen (a la Cluster mit Arrays). Mit dem Rest hast du Recht, wo soll ich denn das anschliessen. Man könnte maximal einen String daraus basteln und als Text ausgeben. Das hatte ich eigenlich auch vor: eine ASCII-Tabelle mit geparsten Daten, ohne diese irgendwo im Graphen darzustellen.

' schrieb:Eine Option wäre die Daten in "Typenklassen" aufzuteilen und für jede "klasse" ein eigenes Modul per VI Server aufzurufen, dass dann wiederum die Daten umwandelt und z.B. über eine Queue in den Hauptprogramm schaufelt, in einer Form, dass man den Draht wieder verbinden kann ...

wie gesagt: theoretisch ist das möglich, aber es gibt viele Probleme zu lösen ...

Irgendwo habe ich ein rekursives VI gesehen, das sich selbst aufruft solange der Eingansstring sich nicht aufgelöst hat. Ich poste mal ein Screenshot davon.

Ungefähr so mache ich es zur Zeit.

eg

' schrieb:Ungefähr so mache ich es zur Zeit.

eg

recht viel besser wirst du es IMHO mit vertretbarem Aufwand auch nicht hinbekommen ...

' schrieb:Eine Option wäre die Daten in "Typenklassen" aufzuteilen und für jede "klasse" ein eigenes Modul per VI Server aufzurufen, dass dann wiederum die Daten umwandelt und z.B. über eine Queue in den Hauptprogramm schaufelt, in einer Form, dass man den Draht wieder verbinden kann ...

So ich habe es mir gestern noch mal durch den Kopf laufen lassen. Ich glaube ich weiss was du meinst.

Schritt 1:
Abhängig von Usereinstellungen ein Array mit Pfaden auf Convert-VIs erstellen.
Schritt 2:
Alle Referenzen zu diesen VIs öffnen (z.B. For-Schleife)
Schritt 3:
Mit Call By Reference diese VIs nacheinander aufrufen (For-Schleife mit Schieberegister).
Die VIs werden einen binären String am Eingang und einen ASCII-String und den Rest des binären Strings am Ausgang haben. Der Rest des binären Strings wird mit dem Schieberegister wieder in das nächse VI als Eingang reingeschoben.
Schritt 4:
Somit bekomme ich von der For-Schleife einen String-Array, den ich in meiner Tabelle darstellen kann. Um die numerischen Werte darstellen zu können, könnte ich über eine oder mehrere Queues, Notifiers oder was auch immer direkt die Numerics reinschmeissen.

Ich weiss noch nicht so recht wie ich diese dynamisch Darstellen soll. Das wird aber der weitere Schritt sein, den ich mir noch überlege.

Danke wür die tollen Hinweise Christian.


Gruß, eg