LabVIEWForum.de

Heyho!

Nun knacke ich seit rund vier Stunden an dem "Problemchen" und habe rund 10 .vi's generiert, von denen ich aber nicht eines wirklich hier präsentieren mag. Am besten schildere ich mal die Aufgabenstellung, wie ich bisher ran gegangen bin und wo es klemmt. Also:

Ich habe hier ein regelbares Netzteil, dem ich gerne über RS232 Leistungsprofile vorgeben würde. Dafür muß LabVIEW leider ein wenig arbeiten, da das Gerät die Daten gerne als HEX und zudem mit einer Prüfsumme versehen haben möchte. Die Sache stellt sich wie folgt dar:

- Das erste Byte ist ein P, welches ich aber natürlich auch als 70 liefern könnte.
- Dann kommen zwei Byte, welche sich aus (Stellert*10) nach HEX konvertiert ergeben.
- Der Rest wird auf 8 Byte mit 30 (kommt von ASCII "0") aufgefüllt.
- Dann wird über alle 16 Nibble eine Quersumme gezogen.
- Das letzte Nibble der Quersumme ersetzt das letzte Nibble der 8 Byte.
- Und die 8 Byte werden - ergänzt um je ein Start und Stoppbit - an den COM-Port geschickt...

Die einzige überhaupt halbwegs brauchbare Version habe ich mal angehängt. Dort war das Hauptproblem, daß die Umwandlung des Stellwerts von Dezimal nach HEX Mist ergibt. Im ersten Anzeigefeld stimmt der Wert - z.B. 22*10 => 00DC. Leider ist das die Stringdarstellung und als HEX-Wert steckt was ganz anderes dahinter. Für die Umwandlung habe ich keine sinnvolle/einfache Lösung finden können und mich dann in die vielen hier schon zum Thema HEX geposteten vi's verrannt...

Naja, und das Thema Quersumme kann man angehen, wenn ersteres gelöst ist. Wie gesagt: Quersumme ziehen, letztes Nibble schnappen und letztes Nibble der 8 Byte durch dieses ersetzen. Dafür habe ich bisher nur ein wenig mit den hier geposteten VIs gespielt, bei denen der HEX-String zwischenzeitlich als Array dargestellt wird. Aus diesem kann man ja ganz einfach die Quersumme errechnen, leider stehe ich dann zuerst vor genau demselben Problem wie oben (aus der Dezimal-Quersumme HEX zu machen) und anschließend kommt die Nibble-Frage. Da muß dann wohl ein Array herhalten würde ich vermuten.

Vielleicht habt ihr ja den ein oder anderen Tipp, der mich weiter bringt. Für heute bin ich drauf und dran, die Netzteil-Geschichte sein zu lassen und das Ding weiterhin manuell und mit Pulsfunktion (an... warten... aus...) zu betreiben. Aber zum Glück gibt's ja das LV-Forum...

Gruß,
Dennis

' schrieb:- Das erste Byte ist ein P, welches ich aber natürlich auch als 70 liefern könnte.

Großes P oder kleines p? Großes P hat ASCII Code 50hex, 70hex ist ein kleines P.

' schrieb:- Und die 8 Byte werden - ergänzt um je ein Start und Stoppbit - an den COM-Port geschickt...

Dir ist schon klar, dass du dich bei der Zusammenstellung des Strings nicht um die Start- und Stoppbits kümmern musst?! Das erledigst du beim Öffnen der RS-232 Schnittstelle.

' schrieb:Die einzige überhaupt halbwegs brauchbare Version habe ich mal angehängt. Dort war das Hauptproblem, daß die Umwandlung des Stellwerts von Dezimal nach HEX Mist ergibt. Im ersten Anzeigefeld stimmt der Wert - z.B. 22*10 => 00DC. Leider ist das die Stringdarstellung und als HEX-Wert steckt was ganz anderes dahinter. Für die Umwandlung habe ich keine sinnvolle/einfache Lösung finden können und mich dann in die vielen hier schon zum Thema HEX geposteten vi's verrannt...

Wieso hast du bei der Funktion "Number to HexString" eine 4 bei der Breite angeschlossen?
Ich denke, es sollen 2 Byte den Stellert repräsentieren?
Bei deinem Bsp 22*10 musst du also ASCII-Zeichenmäßig DC senden und nicht 00DC.

Gruß, Jens

Wenn alles stimmt, was du erzählt hast, und ich jetzt keinen Fehler eingebaut habe, dann schau dir mal das hier an:
[attachment=16830]
Gruß, Jens

P.S.: In Zukunft bitte nicht vergessen:
http://www.LabVIEWforum.de/LV-Version-hoch...d39s-t7949.html

Hey Jens,

Danke für die schnelle Antwort . Das mit der Versionsangabe werde ich künftig befolgen. Ich war halt bisher recht selten hier unterwegs. Das wird sich aber künftig ändern, da ich meine Anlage (Reaktionskalorimeter -> studiere Chemie...) nun endlich mal in LV programmieren möchte. Auch anderswo im Arbeitskreisspürt man das LV-Feuer brodeln. Wir haben auf einer großen Chemiemesse immer einen Stand mit Cocktailmaschine. Wahrscheinlich wird die dieses Jahr auch komplett in LV geschrieben sein - unserem Ingeneur sei dank...

Nun zum Programm:

Der Tipp mit der Schnittstelle ist gut, danke dafür. Ich hätte den String wahrscheinlich von Hand ergänzt und dann gesendet.
Der Plan ist übrigens, das Ganze nachher in ein VI zu packen, dem dann nur noch ein Stellwert und ggf. ein "go" übergeben wird. Ist es dann sinnvoll, den COM-Port jedes Mal zu öffnen und zu schließen oder ist man schneller, wenn er offen bleibt? Das Gerät hat leider nur 2400 baud. Es sendet übrigens was zurück, wenn es den Wert frißt, das wollte ich aber eigentlich zwecks Zeitersparnis nicht auswerten. Muß ich mich trotzdem um den Empfangspuffer kümmern, damit er nicht überläuft?

Das mit der 4er Breite stimmt für das Beispiel, ja. Aber der Maximalwert von 300*10 ergibt BB8. Auch im Datenblatt steht glaube ich was von "4 Byte Hex". Leider darf ich hier nichts daraus posten, das mußte ich dem Hersteller versprechen. Aber es muß recht sicher 0BB8 bzw. 00DC heißen.

Btw: Es ist ein kleines p...

Leider bin ich heute nicht in der Uni, um das Programm zu testen. Morgen bin ich aber unterwegs und werde auf dem Rückweg nochmal am Labor anhalten. Ich kann mir die LV-CDs dann auch endlich mal mit nach Hause nehmen. Solange man per Putty eingewählt ist läuft es so auch zuhause und das sogar ganz legal.

Vielen Dank schonmal. Ich gebe Rückmeldung, sobald ich ein funktionierendes LV zum Testen habe.

Gruß,
Dennis


PS: Sorry, ich glaube ich verwechsele immernoch Bits und Bytes. Es müßte wohl korreckt heißen, daß die ersten zwei Byte das "p" sind und dann 4 Byte für den Wert kommen. Ob das nun insg. 8 oder 16 Byte werden muß ich morgen mal nachgucken...

' schrieb:PS: Sorry, ich glaube ich verwechsele immernoch Bits und Bytes. Es müßte wohl korreckt heißen, daß die ersten zwei Byte das "p" sind und dann 4 Byte für den Wert kommen. Ob das nun insg. 8 oder 16 Byte werden muß ich morgen mal nachgucken...

Wie bitte? Wenn du nicht Unicode beim Versenden der Befehle verwendest, dann ist 1 Buchstabe bei ASCII-Code auch 1 Byte im Speicher und nicht 2!!!

Ich glaube eher, was du durcheinander bringst, sind HEX-Code eines ASCII Buchstaben und die Übersetzung deines Stellwertes in eine HEX-Zahl (bzw. String).

Also: wenn du ein kleines "p" als ASCII-String sendest, dann sendest du 1 Byte (auch wenn der HEX-Code 70hex ist).

Was anderes bei der Zahl. Laut deiner Aussage soll eine Zahl (z.B. 255) als Hex-Zahl (das wäre bei 255 = FF) dargestellt werden und diese dann als String (in diesem Fall also wieder FF) gesendet werden. FF sind aber wieder nur 2 Byte!

Wenn die Breite immer 4 Zeichen oder, was eine idenstische Aussage bei ASCII-Code ist, 4 Byte sein soll, dann schreib das bitte auch so.

Mein VI musst du dann natürlich etwas abändern, wieder auf 4 Byte bei der Zahlwandlung verlängern, und dann nur noch 3x 0 anhängen. (Schau hier nochmal genau nach, soll das ASCII-Zeichen 0 oder der ASCII-Code 0 angehängt werden!)

Und wenn du häufig Daten sendest, dann lass die Schnittstelle offen. Zerleg das ganze in schöne kleine SubVIs (Öffen, Befehl schreiben, Rückmeldung lesen und auswerten, Schnittstelle schließen)

Gruß, Jens

Hey Jens,

ok - jetzt blicke ich da schon etwas mehr durch...

Der String setzt sich wie folgt zusammen:

1.) Steuerzeichen - bei mir das kleine "p" -> 1 Byte ASCII als 1 byte HEX
2.) Stellwert Dezimal 0-3000 -> Dezimalzahl als 2 byte HEX
3.) Auffüllen mit "00000" -> 5 Byte ASCII als 5 Byte HEX ("0" -> 0x30)
...Insgesamt also 8 Byte

Nun hast du mir mit der 7_2.vi schon ein paar tolle Tipps gegeben, insb. was die Prüfsumme angeht. Leider habe ich den ersten Teil nach wie vor nicht alleine richten können, da mich genau der Unterschied Zahl->HEX bzw. ASCII->Hex von einer einfachen Lösung abhält. M.E. gäbe es ja zwei Wege, den String zu berechnen:

- Steuerzeichen als String
- Dezimalzahl nach HEX, dies in einen String wandeln und dran hängen
- 00000 als String dran hängen

Oder aber:

- Steuerzeichen ASCII -> HEX wandeln
- Dezimalzahl nach HEX und dies dran hängen
- "00000" von ASCII nach HEX wandeln und dran hängen
- Das Ganze wieder in ASCII zurück wandeln

Ich habe mich bisher fast ausschließlich an der umständlichen zweiten Variante versucht und dabei zur Vereinfachung Steuerzeichen und "00000" als 70 bzw. 3030303030 direkt in den String eingegeben. Die 2 Byte Stellgröße auch als "2 Byte" Hex- String auszugeben hat auch noch irgendwie geklappt. Ich wußte letzlich bloß mit dem zusammengesetzten "Hex-String" nichts anzufangen, weil ich mit dem keine Prüfsumme rechnen konnte und es auch keine einfache Möglichkeit gibt, diesen wieder in Zeichen umzuwandeln.... Die erste Variante ist aber vermutlich eh einfacher, scheitert aber an einer einfachen Umwandlung der Dezimalzahl zu Hex und das zum ASCII Zeichen.

Ich schau' mal, ob ich hier noch ein nützliches sub-VI für die Wandlung ASCII->HEX finde. Vielleicht denk' ich aber auch viel zu kompliziert und es wird hier eh schon Einspruch erhoben...

Gruß,
Dennis

' schrieb:Hey Jens,

ok - jetzt blicke ich da schon etwas mehr durch...

Der String setzt sich wie folgt zusammen:

1.) Steuerzeichen - bei mir das kleine "p" -> 1 Byte ASCII als 1 byte HEX
2.) Stellwert Dezimal 0-3000 -> Dezimalzahl als 2 byte HEX
3.) Auffüllen mit "00000" -> 5 Byte ASCII als 5 Byte HEX ("0" -> 0x30)
...Insgesamt also 8 Byte

Nun hast du mir mit der 7_2.vi schon ein paar tolle Tipps gegeben, insb. was die Prüfsumme angeht. Leider habe ich den ersten Teil nach wie vor nicht alleine richten können, da mich genau der Unterschied Zahl->HEX bzw. ASCII->Hex von einer einfachen Lösung abhält. M.E. gäbe es ja zwei Wege, den String zu berechnen:

- Steuerzeichen als String
- Dezimalzahl nach HEX, dies in einen String wandeln und dran hängen
- 00000 als String dran hängen

Oder aber:

- Steuerzeichen ASCII -> HEX wandeln
- Dezimalzahl nach HEX und dies dran hängen
- "00000" von ASCII nach HEX wandeln und dran hängen
- Das Ganze wieder in ASCII zurück wandeln

Ich habe mich bisher fast ausschließlich an der umständlichen zweiten Variante versucht und dabei zur Vereinfachung Steuerzeichen und "00000" als 70 bzw. 3030303030 direkt in den String eingegeben. Die 2 Byte Stellgröße auch als "2 Byte" Hex- String auszugeben hat auch noch irgendwie geklappt. Ich wußte letzlich bloß mit dem zusammengesetzten "Hex-String" nichts anzufangen, weil ich mit dem keine Prüfsumme rechnen konnte und es auch keine einfache Möglichkeit gibt, diesen wieder in Zeichen umzuwandeln.... Die erste Variante ist aber vermutlich eh einfacher, scheitert aber an einer einfachen Umwandlung der Dezimalzahl zu Hex und das zum ASCII Zeichen.

Ich schau' mal, ob ich hier noch ein nützliches sub-VI für die Wandlung ASCII->HEX finde. Vielleicht denk' ich aber auch viel zu kompliziert und es wird hier eh schon Einspruch erhoben...

Gruß,
Dennis

Jaja, meiner Meinung nach denkst du VIEL zu kompliziert.
Ich habe das schon mal probiert, zu erklären.
Wenn du einen Buchstaben "p" per RS-232 senden willst, dann sendest du einfach das "p". Das der ASCII-Code (also die Binärdarstellung nach ASCII-Code-Tabelle) dieses Buchstaben 112dez bzw. 0x70 ist, braucht dabei nicht zu interessieren. Also ja nicht sich von dem p den Binärcode holen, diesen dann in eine Hex-Zahl wandeln und dies dann wieder in einen String wandeln. Somit machst du aus einem Byte zwei Byte.

Von dem, was du geschrieben hast, ist definitiv Variante 1 richtig, vergiss das mit Variante 2.

Oder noch mal anders gesagt:
Du musst unterscheiden zwischen einem String und seiner Darstellung im Speicher des Computer! Da wird schließlich alles binär als 1 und 0 dargestellt.
Als sinnvolle Zusammenfassung wurden dann mal 8bit zu einem Byte zusammengefasst. In 8bit kannst du 256 verschiedene Zahlen darstellen. Oder, wenn du dir die erweitere ASCII-Tabelle zur Hand nimmst, kannst du damit auch 256 Zeichen/Buchstaben codieren.
Um jetzt nicht jedes mal die Bit-Darstellung hinzuschreiben, gibt es zur Vereinfachung den HEX-Code. Denn nun kannst du mit 2 HEX-Zahlen (also 00-FF) alle möglichen Zahlen eines Byte hinschreiben.

Gruß, Jens

P.S.: Das mit Datenblatt nicht posten (dürfen) erschwert die Diskussion ungemein. Ich frage mich jedes Mal, ob du den Befehlscode wirklich richtig weitergibst oder nicht.
Bsp: Du sagst was von Stellwert 0-3000. Wobei du auch mal was von geteilt durch 10 gesagt hast. Das wäre dann 0-300.
Andererseits soll der Stellwert als HEX-Zahl (nun wieder in 2 Byte) übertragen werden. Aber in einem 2-Byte-String bekomme ich max. FF rein, also max. 255.

Hey Jens,

du hast vollkommen recht. Das mit dem sinnfreien um-10-Ecken-denken ist eines meiner größten Handicaps. Insofern bin ich mehr als froh, daß du soviel Geduld mit mir hast...

So wie es aussieht hängt das Programm also nur am Stellwert. Der wird ja dezimal eingegeben und soll dann in HEX umgerechnet werden. Wenn ich aber alles als String zusammen kopiere, müßte ich aus dem HEX wieder das zugehörige ASCII-Zeichen machen, richtig?! Und dafür gibt's im Zweifel keine einfache, sondern nur eine Lösung mit sub-VI hier aus dem Forum...?! Daß der Dezimalwert mit 10 multipliziert wird stimmt aber das lassen wir erstmal außen vor...

Hier ein Rechenbeispiel aus dem Datenblatt (ohne den Faktor 10):

0200 (dec) => 00C8 (hex)
...wird dann im kompletten String - incl. Prüfsumme - zu p <00> <C8> <30> <30> <30> <30> <38>

Daß ich das Datenblatt nicht posten darf ist in der Tat blöd. Ich mußte dem Hersteller aber mit Unterschrift besiegeln, es nicht weiter zu geben. Leider...

Liebe Grüße,
Dennis

Die Suche hier im LVF hat drei Möglichkeiten ergeben, die mir weiter helfen könnten. Ich werde mich jetzt mal mit dem TypeCast und mit FlattenToString ein wenig vertraut machen...

So, das müßte es gewesen sein...

Ich werde jetzt mal versuchen, alles unter einen Hut zu bringen und zum erstem Mal mit dem Gerät zu kommunizieren.