Spezielles Byte nach Eingang weiterverarbeiten, RS232

Moin,
danke für die weiteren Ratschläge und das Erstellen des VI.


In der Anleitung des Stellmotors steht, dass die Daten im ASCII Code kommen.
Bei der Definition der Bytes steht dann:

$Kxxxx<LF>

$K Kennung Istposition
xxxx Istposition, 0x0000 bis 0x0480, (Begrenzung durch relatives Messsystem)
<LF> Line-Feed

Die Begrenzung durch das relative Messsystem sind meine (jetzt) „036C“ (Ventil geht net weiter auf). Allerdings ist dies ASCII Code (char), und nicht hex, richtig?
Das dort „0x“ vor der 0000 bzw. 0480 steht verwirrte mich, denn ich hatte gelesen, dass Hexadezimalzahlen durch die Folge von „0x“ angekündigt werden. Wenn man sich dies Ziffer für Ziffer nach der angehängten Tabelle entschlüsseln würde, kämen nur irgendwelche Befehle aber keine Werte zustande.

Zum Verständnis:
Habe ich ein ASCII Zeichen, kann ich dieses in hex, dez oder binär ummünzen. Aus jedem System lässt es sich wieder zurück ins ASCII Zeichen „holen“, oder in eines der anderen Formate ändern.
Wenn ich jetzt aber das eigentlich Zeichen als hex angebe, hat es doch eine ganz andere Bedeutung oder nicht?
Sprich:
ASCII „30“
Ist nicht
Hex „30“.

Wenn ich nun in die beiden VIs schaue und dort von einem Hexadezimal-String in eine Zahl umgewandelt wird, frage ich mich, ob das richtig ist.
Es kommt ein ASCII Code durch das VISA herein. Der Baustein nimmt dann diesen Wert und geht davon aus, dass es ein Hexwert ist. Anschließend wandelt er diesen in eine Zahl (eine Dezimalzahl nehme ich an).
Stört das gar nicht, bzw. ist das nicht „eigentlich“ falsch?
Die Bedeutung der „0“ bei Hex ist ja eine andere als wenn es sich um eine ASCII Chars „0“ handelt.
In der Hilfe steht:
„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“.
Heißt für 036C dann (C=12)*1 + 6*16 + 3*256 + 0*4096 = 876 (ist auch der ausgegebene Wert).
Nehme ich die 036C in ASCII und wandel sie in hex um, ergibt das 30 33 36 43.
Wandelt man dies in eine Dezimalzahl, ergibt es: 808662595
Im Endeffekt müsste das Verhältnis ja immer gleich bleiben und ich kann auch aus dem Wert „876“ eine Prozentangabe erzeugen. Aber ich möchte gerne ein wenig dahinter steigen und bin gut durcheinander : )

Wäre super, wenn mir das jemand erklären/bestätigen kann.

Gruß

Justus

Hallo Justus,

OMG, wat lernt die Jugend heute bloß so im Mathe-Unterricht...

In deiner Botschaft bekommst die 4 Ziffern des Hexwerte als ASCII kodiert ("human readable"). Die Funktion "Hexadezimal-String nach Zahl" wandelt dir diesen String dann wieder in eine Zahl zurück - und zwar im genannten Beispiel in 876d (oder auch 36Ch). (In welchem Zahlensystem du dir die Zahl darstellen lässt, ist übrigens vollkommen Banane und hier irrelevant.) Die Umrechnung nach Prozent musst du dann selbst machen, ich vermute mal nach der einfachen Dreisatzformel 36Ch/480h=76,042%...

Noch ein Beispiel:
Du startest Notepad und schreibst dort die schöne Zahl "876" hin und speicherst das Ganze als Textdatei. Was steht dann in der Datei? Dort stehen die Bytes 38h, 37h und 36h (und evtl. noch 0Dh und 0Ah, wenn du ein Zeilenende hinzugefügt hast) - trotzdem liest du 876, da die Zahl "human-readable" als ASCII codiert wurde.
Genauso liefert dir dein Sensor Werte: "human-readable" ASCII-kodierte Hexwerte...

(02.02.2012 09:58 )Maxix schrieb:  Die Begrenzung durch das relative Messsystem sind meine (jetzt) „036C“ (Ventil geht net weiter auf). Allerdings ist dies ASCII Code (char), und nicht hex, richtig?

Ich gehe jetzt mal nur auf diesen Satz ein, weil sich hier schon mal ein fundamentaler Irrtum offenbart.
ASCII-Code steht nicht im Widerspruch zu HEX. ASCII-Code kann in Binär-, Oktal-, Dezimal oder Hex- Darstellung sein.
Das Gegenteil von ASCII-Code ist die direkte Übertragung von Bytes.
Beispiel: Wert Dezimal "10"
Bei direktes Byte hat es die Bitfolge "00001010". Hier gibt es keinen Diffenziereung Binär, Dezimal.., das Byte selbst ist immer dasselbe. Bei VISA-Lesen werden die Zeichen aber immer als Text interpretiert. In diesem Falle wäre das ein Linefeed. Das Linefeed ist kein Linefeed, sondern der Wert 10, wenn es sich nicht im ASCII-Code handelt.

Der ASCII - Wert der Zahl 10 hängt davon ab, in welchem Zahlensystem man es Codiert. Vom gesamten ASCII-Zeichensatz werden hier nur die wenigen Zeichen von 0..9, A..D verwendet. Also:
Binär: "1010" = 8-stelliger String
Dezimal: "10" = 2-stelliger String
Hex: "A" = 1-stelliger String

Der Nachteil der direkten Wertübertragung ist, daß man die ganzen Steuerzeichen, wie z.B. <LF>, nicht mehr benutzen kann, da diese Bytes jederzeit mitten in den Zahlen vorkommen können. Der Vorteil ist natürlich offensichtlich: Für direkte Übertragung eines 32Bit Integers brauche ich 4 Byte, für die Übertragung als ASCII-HEX aber 8 Byte.

Trotzdem: Der Standard bei serieller Übertragung ist der ASCII-Code - man möchte auf die Steuerzeichen nicht verzichten. Und nur damit hast Du es in Deinem Fall zu tun. Ob es sich um HEX- oder DEC- Code handelt , das mußt Du aus dem Manual selbst herausfinden, das können wir nicht wissen.

Hiho,
bei mir ist die Schulzeit schon fast 10 Jahre zurück… ich denke die Kids von heute sind noch viel ärmer dran.
Ist schon ne Menge neues Input…

Ich habe mir nun eine Anzeige erstellt um entsprechende Werte auszulesen.
Das funktionierte auch überraschend gut und auf Anhieb. VI dazu ist im Anhang.
Als nächstes werde ich versuchen aus dem bestehenden ein SubVI zu erstellen, damit ich es einfacher dreimal gleichzeitig nutzen kann.
Ich gehe nicht davon aus, dass dies so einfach wird…
Der erste Versuch einfach das VISA Resourcename und das Stop als Eingang und die % Werte als Ausgänge zu nehmen hat nicht funktioniert : D
(Baue jetzt erst mal die Stellmotoren auf und schaue, ob es so drei Instanzen mit unterschiedlichen COM-Ports nebeneinander geben darf).

@Lucki,
dein VI dazu hat sehr geholfen. Jetzt kann ich anfangen alles zu verstehen… danke dir.


Gruß

Justus

Hallo Justus,

Zitat:Der erste Versuch einfach das VISA Resourcename und das Stop als Eingang und die % Werte als Ausgänge zu nehmen hat nicht funktioniert

Hat schon funktioniert, aber nicht so, wie von dir erwartet...
Nochmal: Link in meiner Signatur durcharbeiten. Dann immer laut wiederholen: THINK DATAFLOW!
Dataflow: Ein subVI wird gestartet, sobald alle Eingangsdaten anstehen und liefert Daten erst nach Beendigung! Wie soll dein subVI jemals mitbekommen, wann du den Stop-Knopf drückst, wenn du ihm nur den Status vom Aufruf anbietest?

Hallo,

ich habe ein wenig weiter herumgespielt und hatte noch ein paar Ideen, bei denen ich aber an der Umsetzung bzw. den Gedanken hänge…

Vorweg – natürlich versuche ich eure Ratschläge zu befolgen und lese mir die Links und Anleitungen durch, aber es ist wie eine Fremdsprache und von heut auf morgen kann ich dieses Wissen scheinbar nicht in meine Rübe prügeln, also bitte ich weiterhin um Nachsicht ; )

Nachdem ich Windows klargemacht habe, welcher Stellmotor an welchem COM-Port fungieren soll liest der PC nun alle Daten zufriedenstellend aus. Ich habe die Anzeige um eine Sollwertanzeige erweitert. Es funktioniert, aber habe ich auch einen einfachen/passenden Weg dazu genutzt? (Siehe VI).

Einer der Stellmotoren hat einen anderen Maximalwert als die anderen beiden (740 anstatt 876).
Da ich durch diesen Wert meine Prozentangabe ermittele wird bei z.B. 100% Ventilöffnung nicht 100% sondern nur ~ 85% angezeigt. Ich könnt ihn manuell ändern bzw. an den jeweiligen Motor anpassen, aber vielleicht lässt sich dafür auch eine Automatik entwickeln?
Also entweder fahre ich ein Programm in dem ich dreimal alles parallel laufen lasse (ohne SubVI) und habe somit einen einfacheren Zugriff auf die Werte (zur manuellen Änderung), oder es gibt eine Möglichkeit den maximalen Wert "automatisch" anzulernen.
Hier ist eine manuelle Lösung doch deutlich attraktiver und einfach oder?
Es geht mir dabei hauptsächlich um die Benutzerfreundlichkeit.
Zur Ermittlung des Maximalwertes eines jeden Motors müsste das Ventil ja dann einmal ganz auf gefahren werden. Die Stellmotoren werden aber auch nicht so häufig ausgetauscht…

Dann wünsche ich euch schon mal eine tolle Woche…

Justus

Anzeige

Moin,
die Arbeit trägt Früchte.
Ich habe das Programm nun bereits in einer *.exe eingebettet und es funktioniert auch so wie gewünscht.

Mal sehen, wie es weiter geht.

Gruß

Justus