Hallo zusammen.
Leider habe ich mit der Suchmaschine nichts dazu gefunden. Vielleicht ist es auch einfach zu banal...
Also: Via VISA-Read bekomme ich einen String eingelesen, welcher z.B. wie folgt aussieht:
DA80
Dies entspricht einer Sedezimalen (Hexadezimalen) Schreibweise von 0000 - FFFF (In diesem Fall also 55936).
Wie bekomme ich jetzt diesen String zu dieser Zahl gewandelt?
Ich habe es schon mit Hexadezimalstring nach Zahl und mit String nach Byte-Array probiert, aber es will mir nicht gelingen.
Dake für jeden Tipp!
Grüße
Hi T.,
also bei mir geht es mit Hexadecimal String to number...
Probiere es also nochmal..
Gruß
Oliver
Jetzt habe ich mir da mal was übles zusammengebastelt, was funktioniert.
Das kann aber nicht wirklich der gesunde Weg sein, oder?
Aber das mit Hex-String zu Zahl funzt einfach net.
Was mache ich denn falsch?
hi T.,
habe z.Z. nur 6.1 installiert (habe 7 und 7.1 gar nicht mehr wieder installiert - warte auf 8)
Habe für dich mal ein Beispiel in 6.1 zusammengestellt.
Wichtig ist, das du die Ansicht im String Control nicht veränderst!!!.
gruß
Oliver
Hä?
Habe ich das nicht genauso? (ich weiß - wohl nicht..)
Was ist denn der String control?
Sorry, ich bin noch unbeholfener Anfänger.
Hi T.
ich schau mal zu hause in dein VI.
Ein Control ist in der deutschen Version ein Bedienelement (glaub ich jedenfalls).
Es gibt halt auch unter uns "deutschsprachigen Nutzer" einige, die mit der englischsprachigen LabVIEW Version arbeiten. Da der größte Teil der Hilfe und Tutorials die englischen Begriffe nutzt, haben wir hier halt die englische Version...
Gruß
Oliver
Mr.T schrieb:Jetzt habe ich mir da mal was übles zusammengebastelt, was funktioniert.
ACK
Zitat:Das kann aber nicht wirklich der gesunde Weg sein, oder?
Korrekt - das nicht ganz optimal.
Zitat:Aber das mit Hex-String zu Zahl funzt einfach net.
Was mache ich denn falsch?
Nicht so viel... Nur dass Hex-String zu Zahl in deinem Fall nicht funktioniert - nicht funktionieren kann.
Das hatten wir hier schon öfter und es wird auch nicht das letzte mal sein, dass es Verwechslungen und Missverständnisse gibt zwischen der Darstellung mittels druckbarer ASCII Zeichen, der Zahl selbst und der Abbildung der Zahl im Speicher. Falls es einmal nicht zu Missverständnissen kommen würde, dann sorgen Big- und Little-Endian ggf. dafür, dass wieder etwas nicht so ist, wie es erwartet wurde.
Eine Zahl, wie in deinem Beispiel Dezimal 55936 oder Hex 0xDA80 kann mittels zweier Bytes gespeichert werden. Bei Big-Endian wird das höherwertige Byte zuerst gespeichert 0xDA gefolgt von 0x80. Bei Little-Endian wird das niederwertige Byte zuerst gespeichert 0x80 gefolgt von 0xDA.
Wird die Zahl lesbar dargestellt, dann erfolgt diese Darstellung mittels druckbarer ASCII Zeichen als "DA80" (im Speicher stehen die Bytes 0x44 0x41 0x38 0x30). Nur diese Form der Darstellung kann z.B. mittels der Funktion "Hexadecimal String to Number" in einen Integer umgewandelt werden.
In deinem Fall kommt die Zahl so wie sie ist und zu meiner Freude auch im Big-Endian Format. Die Umwandlung geht ganz einfach mittels "Type Cast" (Palette Advanced, Data Manipulation) in einen U16 (unsigned 16 Bit Integer).
Klasse!
Danke für die Erklärungen. Das sieht jetzt schon deutlich besser aus.
Noch ne Frage: Versehentlich hatte ich zuerst mittels einer Konstante nicht in u16 sondern in u32 gewandelt - dann wurde ein anderer Wert dargestellt (viel größer). Ich verstehe jetzt aber nicht, weshalb. 0xFFFF ist doch immer die gleiche Zahl?.
Eine weitere Frage noch: Wenn ich den einfachen Fehlerbehandler benutze kommt in meinem fall nach abschluss aller (Optimal funktionierenden) Vorgänge folgender Fehler:
Fehler -1073807253 ist bei VISA: Lesen in Datei-IO.vi aufgetreten
Mögliche Gründe:
VISA: (Hex 0xBFFF006B) Während der Übertragung ist ein Rahmensynchronisations-Fehler (framing error) aufgetreten
Was ist ein Rahmensynchronisationsfehler?
Gruß und Dank
Mr.T schrieb:Noch ne Frage: Versehentlich hatte ich zuerst mittels einer Konstante nicht in u16 sondern in u32 gewandelt - dann wurde ein anderer Wert dargestellt (viel größer). Ich verstehe jetzt aber nicht, weshalb. 0xFFFF ist doch immer die gleiche Zahl?.
Die "Type Cast" Funktion beginnt mit dem ersten Byte, 0xDA. Das ist das höchstwertige Byte. Als nächstes folgt das zweite Byte mit 0x80. Das dritte und vierte Byte ist nicht vorhanden und es wird dann mit 0x00 eingesetzt. Als Ergebnis bekommst du 0xDA8000 oder Dezimal 3665821696.
Bei einer internen Darstellung als Little-Endian (üblich u.a. auf Intel Prozessoren, PC) hättest du jetzt tatsächlich auch wieder die Zahl 55936 (Dezimal). Da kann LabVIEW seine Herkunft nicht verleugnen, denn Big-Endian wird von den Motorola Prozessoren (Macintosh) verwendet.
[quote]Eine weitere Frage noch: Wenn ich den einfachen Fehlerbehandler benutze kommt in meinem fall nach abschluss aller (Optimal funktionierenden) Vorgänge folgender Fehler:
Nachdem ich jetzt das Open umgesetzt hatte und die Parameter kontrolliert habe tritt der Fehler leider noch immer auf.
Jetzt habe ich das Open rausgenommen - trotzdem Fehler.
Wenn ich die Fehlermeldung immer direkt nach den einzelnen VISA - VIs anbinde (abwechselnd nacheinander) tritt der Fehler immer nur erst an der Stelle, nach dem Lesen auf. Bringt uns das weiter?
Es erscheinen aber trotzdem alle gelesenen Werte richtig.
Danke, dass Du Dir so viel Mühe mit mir gibst
