Hallo,
ich möchte Roh-Messdaten (Byte-Werte: 0 - 255) über die serielle COM-Schnittstelle übertragen.
An die Funktion ´VISA:Schreiben´ müssen die Daten ja in Form von ASCII-Zeichen (String) übergeben werden (=Schreibpuffer).
Gibt es unter LabVIEW eine einfache Funktion, die mir aus den Zahlen (0 .. 255) ASCII-Zeichen macht ?
Meine bisherige Lösung erscheint mir etwas umständlich: ich erschaffe mir ein 1*1-Array und initialisiere dieses permanent mit meinem Messwert (Funkton: ´Initialize Array´).
Am Ausgang dieser Funktion habe ich dann ein 1*1-Array mit dem Messwert. Daran schließe ich die Funktion ´Byte-Array to String´an und erhalte so einen einstelligen String mit dem ASCII-Zeichen, das meinem Messwert entspricht.
Diesen String kann ich dann über die VISA-Funktion aussenden.
Das klappt zwar, erscheint mit aber etwas aufwendig.
Vielen Dank für die Hilfe
Herby
Hi Herby
ein Beispiel als LV2009 VI Snippet:
[
attachment=31461]
1. Irgendeinen Datatentypen, am besten als .ctl-Typedef, in einen String casten, die Datenstringlänge davor hängen und mit VISA Write versenden.
2. Länge des Datenstrings lesen und danach die entsprechnende Anzahl an Datenbytes.
3. Typecast in den gewünschten Typdef.
Damit kannst Du die Konversion in ASCII komplett vermeiden. Du musst Dir aber über die Version des Typedefs Gedanken machen, falls du gezwungen sein solltest, in Zukunft mit verschiedenen Versionen des Typedefs zu arbeiten. Um ein solches möglichesProblem zu lösen, könnte LVOOP in Frage kommen.
Gruß Holger
Hallo Holger,
vielen Dank ür die Antwort.
Deine Lösung sieht aber auch recht aufwendig aus.
Wenn ich z.B. einen einfachen Meßwert habe, z.B. den Wert 70, so muß ich daraus ja eigentlich nur das ASCII-Zeichen ´F´ machen, das ich dann mit ´VISA: Schreiben´ aussende.
Mehr will ich eigentlich nicht machen.
Ich dachte, es gäbe irgendwo versteckt eine ganz einfache Funktion: ´Byte-Zahlenwert rein --> ASCII-Zeichen (String) raus´, die ich dann direkt an die VISA-Funktion anschließen kann.
Viele Grüße
Herby
Hi Herby,
der Typecast ist genau da was Du suchst. Ich habe in meinem Beispiel nur illustrieren wollen, was möglich ist, und welche Probleme auftauchen können, wenn man komplexe Daten mit variabler Länge übertragen will.
Du kannst in Deinem Fall natürlich der einen Seite nur den U8 in den String casten und auch der anderen Seite genau ein Byte(Character) lesen und wieder in den U8 zurück casten. Fertig.
Gruß Holger
Hallo Herby,
es geht auch ohne ArrayInit:
[
attachment=31463]
Erscheint mir kürzer als das TypeCast - und wenn man nur einzelne Bytes bearbeitet, dürfte beides ähnlich (in)effizient sein...
Hallo GerdW,
vielen Dank für Deine Hilfe.
So etwas habe ich gesucht.
Da ich allerdings noch nicht allzu fit bin in LabVIEW, kenne ich die erste Funktion nach der U8-Konstanten noch nicht.
Wo kann ich diese finden ? (bzw. wie macht man aus solch einem Bild ein Blockdiagramm (dann könnte ich die Funktion ja ermitteln).
Das Rest ist mir klar.
Viele Grüße
Herby
Verstehe nur nicht, warum die Beispiele alle so künstlich verumständlicht sind. Hier mal drei einfache Vorschläge:
[
attachment=31464]
Das funktioniert mit anderen Zahlenformaten ebenso, als z.B mit I32, oder wenn eine Gleitkommazahll als String über der Serielle Schnitstelle gesendet werden soll. Die Rückkonvertierung ist ähnlich einfach.
Hallo Herby,
das ist ein BuildArray - eine der an die Anzahl der eingänge anpassbaren Funktionen...
Hallo Lucki,
vielen Dank für diese sehr kompakte Lösung.
Was mich hier allerdings wieder einmal verblüfft ist die Tatsache, daß am Anschluß ´Typ´ von der Typumwandlungsfunktion keine "Ziel-Typ-Festlegung" angeschlossen werden muß.
Auch in der Hilfebeschreibung zu dieser Funktion steht eigentlich nicht, was passiert, wenn man diesen Anschluß offen läßt.
Aber es funktioniert ja (irgendwie).
Vielen Dank
Herby
' schrieb:Was mich hier allerdings wieder einmal verblüfft ist die Tatsache, daß am Anschluß ´Typ´ von der Typumwandlungsfunktion keine "Ziel-Typ-Festlegung" angeschlossen werden muß.
Das ist ja öfters so, daß bei Nicht-Anschluß ein Default-Wert gilt. Mit Kontext-Menü "Erstellen/Konstante" erzeugt man eine leere String-Konstante, also könnte man davon ausgehen, daß dieser Typ der default-Wert ist. Du hast aber Recht, da sollte auch in der Hilfe so angegeben werden - ist es aber nicht. Im Gegenteil: Es gibt einen Unterschied zwischen Kontext-Hilfe und ausführlicher Hilfe. In der Kontext-Hilfe ist am "Typ"-Eingang ein String-Draht angeschlossen, in der ausführlichen Hilfe ein Gleitzahl-Draht.
Also ich kann letztlich nur dieses sagen: Es hat sich bewährt, bei Konvertierung nach String den Typ nicht anzuschließen. Möglicherweise war es sogar genau dieser fehlende Anschluß, der Dich veranlasste, meinen Vorschlag wegen seine besonderen Einfachheit zu loben.
