Hallo smarties,
Zitat:Jedenfalls zeigt der Weg über Array indizieren und nach I16 konvertieren das richtige Ergebnis an. Legedlich der rote Punkt am Multiplikationsblock deutet an, dass die Datentypen noch nicht ganz stimmen. Bin aber skeptisch, ob das das der richtige Weg ist?
Wenn du auch unbedingt einen Integer mit einem DBL multiplizieren willst, ist wohl der rote Punkt erklärbar...
Wenn das gewünschte Ergebnis herauskommt, wird's wohl auch "der richtige Weg" sein! Es mag kürzere geben, aber danach hast du nicht gefragt.
Zitat:Dein Weg halte ich für nachvollziehbar, so ists auch intivitiv logisch, aber als Ergebnis wird eine 0 vom Default Eingang (Datentyp hierI16) weitergegeben.
So langsam (nach all den Fragen) müsstest du doch gemerkt haben, dass die Funktion HexadezimalStringNachZahl nach einem ASCII-kodierten Hexstring (d.h. lesbarer Text) erwartet. Wie soll bitte der String "ê(" (ASCII-Zeichen für die Bytes EA28) in eine Zahl umgesetzt werden? Siehst du da eine?
Außerdem kann man Konstanten auch bestimmten Datentypen zuordnen (Rechtsklick!), da braucht man keine extra Funktion "Zu I16" für...
Sehr gut. In der Tat - selbes Ergebnis!
Herzlichen Dank!
Manche Daten (z.B. die Drehung um die x/y Achse) werden im selben Register geliefert. Das beduetet, dass der Antworts-String im Hex Format hier z.B. E9DB 343A lautet (konstruiertes Beispiel).
Mit dem Array Indizieren Block bin ich jetzt so vorgegangen, dass ich diesen einfach auf 4 Ausgänge aufgezogen habe und die oberen respektiven unteren beiden dann über "Nummern Verbinden" und Wandlung auf I16 die richtigen Werte anzeigen.
Wie würde man dies alternativ also mit dem Typecast machen?
String splitten und für jeden gesplitteten String einmal das Verfahren mit Typecast?
@GerdW: Ich ging davon aus, dass es dem HexadezimalStringNachZahl egal ist, wie der Eingang-String kodiert ist. Dass er ASCII erwartet wusste ich nicht - wieder was gelernt!
Hallo smarties,
wenn man ein Array von I16 erwartet, dann sollte man auch in eines wandeln:
[
attachment=43227]
Zitat:Ich ging davon aus, dass es dem HexadezimalStringNachZahl egal ist, wie der Eingang-String kodiert ist.
Und ich ging davon aus, das würde die Kontexthilfe erläutern:
Zitat:Interpretiert die Zeichen 0 bis 9, A bis F und a bis f in String beginnend am Offset als eine ganze Hexadezimalzahl und zeigt diese in Zahl an.
Wenn du die Funktionen nicht kennst, warum lässt du dann die Kontexthilfe nicht offen (Ctrl-H)?
Ein Punkt ist in den letzten Beiträgen übersehen worden, nämlich die Aussage, dass dein String im "Little Endian" Format kommt:
(23.01.2013 22:24 )smarties schrieb: [ -> ]Dieser Wer ist lt. Datenblatt als 16 Bit Integer, 2er Komplement, Little Endian die eigentliche Drehrate.
Also "verschmelze" ich den 8 Bit Wert FE mit dem 8 Bit Wert EA zum 16 Bit Wert FE EA.
LabVIEW arbeitet mit Big Endian Darstellung.
Für eine korrekte Darstellung musst du also die beiden Bytes bei einer Typecast-Umwandlung noch drehen, bei deinem Vorgehen per JoinNumbers in umgekehrter Reihenfolge zusammensetzen.
Sieht dann z.B. so aus:
[
attachment=43228]
Gruß, Jens