Spezielles Byte nach Eingang weiterverarbeiten, RS232

Hallo,
mehr zu mir findet ihr in der Vorstellung: Klickt mich!
Ich habe noch nicht viel Erfahrung und daher teilweise sicherlich auch Fragen zu den Begriffen (wenn ich sie im Netz nicht erklärt finde). Aber trotzdem immer her damit : )
Sollte dies das falsche Unterforum sein, bitte entsprechend verschieben.

Nun zu meinem „Problem“.
Ich habe einen Stellmotor dessen Signale über einen Wandler via USB in den Rechner gelangen.
Zitat:
„Als Protokoll wird ein RS232 kompatibles Format mit 9600Baud, 1 Startbit, 1 Stoppbit, 0 Paritätsbit benutzt. Die Daten werden einmal je Sekunde ausgegeben.
Alle Daten werden in Blöcken von jeweils 7 Byte inkl. aller Steuerbytes im ASCII-Code ausgegeben.
Startbyte ist ein $, Endbyte ein Line-Feed <LF>“.

Hier ergibt sich für mich die erste Frage:
Ich habe folgende sieben Steuerbytes: H, I, J, K, L, M (kleines m bei Fehler), N
Für mich ist erst mal nur K interessant, daher werde ich alle Beispiele anhand von K schreiben.
K ist wie folgt aufgebaut:

$Kxxxx<LF>
$K – Kennung „Istposition“ des Stellmotors
xxxx - Istposition, 0x0000 bis 0x0480, (mit Begrenzung aufgrund des relativen Messsystems)
<LF> Line-Feed

Es besteht dann doch aus sieben Bits oder (<LF> (Zeilenumbruch) gilt als ein Bit?)?
Oben müsste es doch immer StartBIT und EndBIT heißen, oder?


Nun das konkrete Problem:
Ich bekomme sieben Steuerbytes je Sekunde in die Software, möchte aber nur das „$K-Byte“ verwenden (es ist das vierte, die Reihenfolge ist wie oben aufgelistet).
Wie kann ich mir dieses Byte herausfiltern, um es weiter zu verarbeiten?

Die weitere Verarbeitung nach dem erfolgreichen Herausfiltern:
Wenn ich das Byte einzeln „in den Händen halte“ möchte ich den eingehenden Wert in eine Prozenteingabe umwandeln und auf dem Panel ausgeben.
Ich könnte die Werte „0000“ bis „0480“ aufteilen und mit Schritten auf 100Prozent umrechnen.
Dies würde mir für den Anfang schon reichen!
Der Haken:
Der Stellmotor passt sich ans jeweilige Ventil an, bei dem zurzeit eingesetzten ist die maximale Öffnung z.B. „036B“. Es wäre wunderbar, wenn man sich hierfür auch eine Art „Automatik“ bzw. Einstellmöglichkeit einfallen lassen könnte. Ich erwähne es jetzt schon, da es sich ja vielleicht gleich beim Programmieren berücksichtigen ließe.

Das angehängte VI habe ich mir gebaut, um die Daten durch LabVIEW in den PC zu bekommen.
Es hat noch den Fehler, dass gelegentlich „die Daten eingelesen werden, bevor die Hardware soweit war“ (oder ähnlich, ihr wisst sicherlich was ich meine). Der Fehler ist hier im Forum auch erklärt, allerdings habe ich mich noch nicht um eine Lösung bemüht, da ich nicht sicher bin ob es überhaupt der richtige Weg ist. Testweise habe ich den Fehlerausgang auf das Beenden der While-Schleife gelegt.


Hier einmal die ganze Eingangskette (habe ich aus Hterm gezogen):
RAW/Normal Format (was ist daran „Normal“, Ist damit ASCII gemeint?):
$H138E
$É13FE
$J036B
$K0224
$L10E9
$Í5110
$N1064
O³132
Warum werden das I (zweites Byte) und das M (sechstes Byte) hier manchmal als É und Í angegeben?
Das kann ich auch in LabVIEW beobachten. („K“ war bisher wirklich immer „K“).

Hexadezimal:
2448303132410A
2449313346450A
244A303336420A
24CB303338380A
244C333637420A
244D343831300A
244E313032350A
4F333945330A0D


Auf Wunsch kann ich auch noch weitere Formate einstellen.

Es würde mich freuen, wenn wir uns gemeinsam nach und nach um meine Probleme kümmern können.

Danke

Gruß

Maxix

Hallo Maxix,

Zitat:Es besteht dann doch aus sieben Bits oder (<LF> (Zeilenumbruch) gilt als ein Bit?)?

Nicht Bit, sondern Byte. Steht doch genau so in deiner Beschreibung...

Zitat:Warum werden das I (zweites Byte) und das M (sechstes Byte) hier manchmal als É und Í angegeben?

Weil aus irgendwelchen Gründen das MSB dieser Zeichen gesetzt ist - wie man an der Hexcode-Anzeige sieht...

Zu deinem VI: man muss nicht mit jeder Iteration den seriellen Port neu initialisieren:
   
- Man muss auch nicht Standardwerte explizit vorgeben.
- Gut ist, dass du hier das TermChar voreingestellt gelassen hast - es passt zu deinem Protokoll! Dann einfach mehr Zeichen abfragen (hier: 8) als geliefert werden, da dann automatisch beim TermChar (hier: LF) die Zeichenkette geliefert wird.
- Lokale Variablen sind überbewertet und waren bei dir auch noch a la RaceCondition falsch verwendet...

Hallo,
danke für die gehaltvolle Antwort.
Ahso, ich dachte, dass ein Byte aus X Bits besteht.
Somit hätte dann der Aufbau vom K-Byte aus sieben Bit bestanden, wenn denn <LF> als ein Bit gilt.
Verstehe ich jetzt richtig, dass jedes Element von K ein Byte ist, welches durch Bits erstellt wird?
Sprich das $ Startbyte besteht aus Bits, welche das Zeichen $ ergeben?! (in der Beschreibung steht weiter oben 1 Startbit... verwirrend).

Zum VI:
-Initialisierung leuchtet ein, thx.
-Wenn du mit Standardwerte die am "seriellen Port konfigurieren" meinst, dann habe ich diese gesetzt weil ich sonst eine Fehlermeldung bekam. Diese kam eben auch wieder, aber nach neu Erstellung des Bausteins und Neustart des VI geht es nun.
-Meintest du mit den Lokalen Variablen das "Hexadezimal" und des "Fehler"?
Danke für den Hinweis, beim Hex ließ es sich ja simpel verbessern.
Beim Fehler am Stop hatte ich auch versucht mit einem ODER zu arbeiten, allerdings ohne den Baustein in dem nun "Status" steht. (Um welchen handelt es sich? Kann ihn nicht finden...). Wird dort der Fehler in etwas Boolesches verändert?

Gruß

Justus

<LF> ist auch ein Byte. Hat im ASCII-Code den Hex-Code 0x0A.
http://de.wikipedia.org/wiki/Zeilenvorschub

Ein Byte besteht übrigens IMMER aus 8 Bits!

Gruß, Jens

Hallo Justus,

Zitat:allerdings ohne den Baustein in dem nun "Status" steht. (Um welchen handelt es sich? Kann ihn nicht finden...). Wird dort der Fehler in etwas Boolesches verändert?

Das ist ein UnbundleByName aus der Cluster-Palette...
Ein "Fehler" ist übrigens ein Cluster aus bool-state, Nummer und Beschreibungstext - wie man in der Hilfe nachlesen könnte

Zitat:(in der Beschreibung steht weiter oben 1 Startbit... verwirrend).

Es scheint, du solltest dir auch mal die Grundlagen zur Datenübertragung über die serielle Schnittstelle aneignen. Zum Glück gibt es Wikipedia...

Zitat:Sprich das $ Startbyte besteht aus Bits, welche das Zeichen $ ergeben?!

Das "$"-Zeichen besteht aus den Bits 00100100b (oder auch 24h, oder auch 36d, oder auch 44o), wie man in deiner ersten Meldung gut erkennen kann...
Das Startbyte der Datenbotschaft hat übrigens nichts mit dem Startbit der seriellen Datenübertragung zu tun! Aber du wolltest ja sowieso Wikipedia konsultieren...

Hallo!

@Jens
Den Zeilenumbruch hatte ich bereits bei Wikipedia angeschaut, aber nun weiß ich, dass das 0x davor für Hexadezimal steht. Diese Zahlensysteme sind mir alle noch nicht geläufig.
Was mich irritierte ist, dass (auch bei Wikipedia) folgendes aufgeführt ist:

Freies Zitat:
[…]Was genau ein Byte bezeichnet, wird je nach Anwendungsgebiet etwas unterschiedlich definiert. Der Begriff kann stehen für:
die kleinste adressierbare Datenmenge eines bestimmten technischen Systems, z. B.:
bei ASCII: 1 Zeichen = 7 Bit […]

Das heißt ja aber nicht, dass es nicht auch aus 8 Bit bestehen kann.
Wenn ein Byte immer 8 hat und nur 7Bits verwendet werden, was passiert denn mit dem übrigen?
Für mich klingt es so, als wenn es auch ASCII Zeichen gibt, die nur 7 Bits zur Erstellung benötigen.
(Bei anderen Systemen noch weniger).

@GerdW

Cluster: Danke fürs Erinnern, ich hatte den Fehlercluster während der Übungen sogar erstellt. Das Gelernte muss sich nur richtig verknüpfen…

Startbit und Startbyte: Was würde ich ohne Wikipedia hier jetzt fragen…

Zitat:[...]Bits 00100100b[...]

Das b hast du nun für bit hingeschrieben, gell?

Ich habe das VI entsprechend um den „Status“ Baustein erweitert, funktioniert natürlich wunderbar.
Wenn ich die Konstante am Baustein „VISA Lesen“ auf 8 Bytes stelle, ergibt sich häufiger die Fehlermeldung zum Überlauffehler (lässt sich nicht gezielt reproduzieren). Bei 9 Bytes kam dieser Fehler bisher nicht. Ist es nachteilig mit 9 Bytes zu fahren?

@All
Wenden wir das gelernte an:
Ich möchte gerne die Bits des vierten Bytes aus meiner Byteansammlung, welche einmal die Sekunde im ASCII Code ins System kommt, analysieren und in eine dezimale Prozentangabe ausgeben.
Die Werte dieses Bytes laufen im Hexadezimalsystem (0x) von 0x0000 bis 0x0480 (zurzeit bis 0x036B).
Passt des so?

Gruß & Danke

Justus

Hallo Justus,

Zitat:Das b hast du nun für bit hingeschrieben, gell?

Falsch. b0binär, h=hexadezimal, o=oktal und d=dezimal...

Zitat:Wenn ich die Konstante am Baustein „VISA Lesen“ auf 8 Bytes stelle, ergibt sich häufiger die Fehlermeldung zum Überlauffehler (lässt sich nicht gezielt reproduzieren). Bei 9 Bytes kam dieser Fehler bisher nicht. Ist es nachteilig mit 9 Bytes zu fahren?

Nimm doch einfach mal diese Wartezeit aus der Schleife raus, dann bekommst du auch keine BufferOverflow-Medlungen mehr. Warum das so ist, darfst du dir selbst überlegen...

Zitat:Wenden wir das gelernte an:
Ich möchte gerne die Bits des vierten Bytes aus meiner Byteansammlung, welche einmal die Sekunde im ASCII Code ins System kommt, analysieren und in eine dezimale Prozentangabe ausgeben.
Die Werte dieses Bytes laufen im Hexadezimalsystem (0x) von 0x0000 bis 0x0480 (zurzeit bis 0x036B).
Passt des so?

Wenn du etwas gelernt haben solltest, dann das ein Byte immer gleich 8bit. Wie kann also ein Byte plötzlich Werte mit 16bit darstellen?
Vielleicht solltest du einfach diese 4 Zeichen (!) ausschneiden (Stringfunktion!) und dann von hexadezimal-String nach (Dezimal-)Zahl wandeln (Stringfunktion!)...

Hi, und danke für die Zaunpfähle ; )

Die Warteschleife nutze ich nur, damit ich die Werte betrachten kann die durchs Bild flimmern.
Später hatte ich sie nicht eingeplant. (Ohne kommt auch die Fehlermeldung nicht mehr).

Das Signal muss scheinbar einmal angeregt werden damit es funktioniert. Am Wandler ist eine LED zur Kontrolle des Sendestatus. Wenn ich das VI starte blinkt diese und ich erhalte die übliche Fehlermeldung. Wenn ich nach dem Abbruch durch den Fehler gleich wieder starte geht es normal weiter.
(Wenn ich den Fehler aus den Abbruchkriterien entferne läuft es natürlich einfach durch…)
Lässt es sich einstellen, dass die erste Fehlermeldung ignoriert wird?


Ich habe ein wenig ausprobiert und konnte mir den passenden Teil des String herausschneiden (mit „String durchsuchen und teilen“). Diesen Teil befreie ich dann vom $K und gebe nur die letzten vier Zeichen aus. Diese wandeln sich in einen Dezimalwert, mit dem kann ich aber noch nichts anfangen da es kein Zusammenhand zu einer Prozentanzeige gibt.

Ich möchte gerne erst mal, dass der „Treffer + Rest des Strings“ und der „Teil-String“ stehen bleiben und erst dann überschrieben werden, wenn ein neues Signal vom Wandler kommt.
Womit würdet ihr diesen Schritt realisieren.
(Irgendwie denke ich an FOR-Schleife, glaube aber das es damit zu kompliziert ist).

Durch meine geringe Erfahrung denke ich, dass ich alles sehr aufwändig gestallte und es dafür sicherlich irgendwo bereits eine fertige LabVIEW VI gibt.
Nehmt es mir bitte nicht übel ; )

@GerdW
Was meinst du denn jetzt mit 16Bit?


Gruß

Justus

Hallo Justus,

zum Speichern von Werten in einer Schleife nutzt man Schieberegister. Arbeite den Link meiner Signatur zum Thema durch...

Zitat:Was meinst du denn jetzt mit 16Bit?

Du hattest geschrieben:

Zitat:Die Werte dieses Bytes laufen im Hexadezimalsystem (0x) von 0x0000 bis 0x0480 (zurzeit bis 0x036B).

Werte wie 0x0480 sind üblicherweise 16bit-Werte, die durch 4 Hexziffern repräsentiert werden...
Du musst dir wirklich angewöhnen, immer genau zu beschreiben, wovon du redest! Ein Hexwert 0x0480 wird durch 16bit dargestellt - ein String "0480" dagegen durch 4 ASCII-Zeichen = 4 Byte (=32bit), obwohl er den gleichen Hexwert darstellen soll...

Habe mir das VI auch mal angesehen, es ist immer noch zu umständlich.
Außerdem: Wenn die Gegenstation laufend unaufgefordert sendet, dann hat man am Anfang, wenn man plötzlich in den Datenstrom hineinhört, Synchronisationsprobleme. Endweder man hört mitten in ein Byte hinein, dann hat man einen "Rahmenfehler", oder man hört mitten in einen Datensatz hinein, dann stimmt die Länge des Datensatzes nicht. Solche Fehler müssen behandelt werden, es besteht da kein Grund, die ganze Übertragung abzubrechen. Habe mal im VI der Einfachheit halber alle Fehler ignoriert, außerdem werden Datensätze mit unrichtiger Länge ignoriert.

   

  Dateneinlesen4.vi (Größe: 9,4 KB / Downloads: 252)


Edit: Die Überprüfung des Datensatzes auf korrekte Bytezahl ist redundant, also überflüssig. Es wir ja später geprüft, ob der Datenatz mit "$" beginnt, und enden muss er sowieso immer mit <LF>.