Probleme bei der Datenkommunikation mit serieller Schnittstelle

Hallo,


Ich habe vor kurzem mit der LabVIEW-Programmierng begonnen und möchte die Daten eines Detektors, der über eine RS 232 Schnittstelle Messwerte sendet, auslesen. Das Problem ist das Ansprechen des Sensors, der über ASCII kommuniziert und auch Daten in ASCII als Antwort sendet. Zum Ansprechen muss ein Telegramm gesendet werden, welches Ich in Hex Schreibweise vorliegen habe (0d 30 30 30 30 30 30 30 30 30 30 31 33 75 19 01 31 0c 30 30 30 30 0a). Dieses Telegram muss der Detektor aber in ASCII erhalten, damit er mir eine Antwort schicken kann, die ebenfalls in ASC II ist. Ich habe in LabViEW 9 mit dem aus Foreneinträgen abgeänderten Examplefinder versucht, das Hex-Telegram zunächst in ASCII umzuwandeln. Jedoch ist mir nicht gelungen, das erhaltene ASCiI-Telegramm wieder in Hex umzuwandeln. Beim Senden des Telegrams reagiert der Detektor, jedoch nicht auf die Weise, wie eigentlich solte (sollte eigentlich neu booten).
Könnt ihr mir bitte sagen, wo Ich was wie verändern muss?


Ich hoffe, ihr könnt mir helfen.


Prama

Anzeige

Hallo Prama,

du musst (eigentlich) nichts ändern. Du musst verstehen lernen, dass "Hex" und "ASCII" zwei Seiten der selben Medaille sind!
Ob du nun "0D30 3030 3030 3030 3030 3031 3375 1901 310C 3030 3030 0A" (Hex-Display), "\r000000000013u\19\011\f0000\n" (\-Codes) oder "000000000013u
10000" (teilweise ASCII) schreibst: es bleibt die gleiche Byte-Reihenfolge, nur deren Ansicht ändert sich!

Genauso beim Datenempfang: du kannst es beliebig darstellen lassen, musst aber trotzdem wissen, welches Byte welche Bedeutung hat...

Hallo Gerd,


Danke für Deine schnelle Antwort.
Verstehe Ich Dich richtig, dass der Sensor bei der Hex von 0d 30 30 30 30 30 30 30 30 30 30 31 33 75 19 01 31 0c 30 30 30 30 0a
das Telegram (nach dieser Version des VI) in ASCII erhält?
Das Problem ist, dass der Sensor bei Senden dieses Telegrams und ohne Sendung eines Telegrams bei der Ausführung auf die gleiche Weise reagiert.


Prama

Hallo Prama,

das Telegramm sind erstmal "nur" 23 beliebige Bytes. Wie der Empfänger diese interpretiert, ist ihm überlassen. Wenn er sie nach "ASCII" auswertet: schön...

Zitat:nach dieser Version des VI

Dein VI verwendet ein String-Control in HEX-Display-Darstellung, wenn du also den HEX-String wie gezeigt eintippst, wird er auch so versendet...

Hast du eine Doku deines Sensors/Detektors, die du hier hochladen oder verlinken kannst?

Gruß, Jens

Hallo,


Leider darf Ich aus firmentechnischen Gründen, die Dokumentation des Sensors nicht hochladen. Ich kann euch den Aufbau der Telegrammstruktur kurz zusammenfassen.


Telegramstruktur:

TS DID TID Data DE CRC TE

TS (0x0D): Telegram start charcter, 1Byte

DID: Device-ID number, u32, transferred in ASCII-Hex
Example: ID 1234 -> 0x000004D2
Transferred Data: 0x30 0x30 0x30 0x30 0x30 0x34 0x44 0x32

TID: Telegram-ID number, word, transferred in ASCII-Hex
Example: TID_ACK -> 0x0001
Transferred Data: 0x30 0x30 0x30 0x31 (always 4 Byte)
the telegram ID defines the structure of the following data area. All possible telegram IDs are defined in the header file tele.h.

Data (0x31011975): Payload data in binary format
The maximum data size that can be sent to the sensor is determined by sending a GETAPPINFO oder GETBOOTINFO telegram. Depending
which mode the sensor is in. The sensors maximum sent data is 64 Byte

DE (0x0C): Data end character, 1 Byte

CRC: Checksum, word, transferred in ASCII-HEX; CRC-16 with polynom 0x8005
Example: crc = 0xA5B3
Transferred Data: 0x41 0x35 0x42 0x33 (always 4 Bytes)
The CRC is calculated starting with the telegram start character up to the end of data. For ease development a CRC of 0 is always accepted.

TE (0x0A): Telegram end character, 1 Byte


Die TID ist in der Dokumentation für verschiedene Angelegenheiten, z.B. Senden von Daten, Start der Messung, angegeben.

Bei der DID kann 0 (in 8 Bytes) angegeben werden.

Das von mir gesendete Telegram ist, wie gesagt, in Hex.


Prasanna

Anzeige

Es ist immer wieder das Gleiche (will sagen: bin schon fast genervt)
Der Datenaustausch über die serielle Schnittstelle erfolgt fast immer in ASCII-Hex. Man braucht dann zwar doppelt so viele Bytes wir in einem binären Modus (1 Byte in ASCII-Hex = 2 Zeichen [0..9, A..F]), aber der Vorteil ist ( - neben der direkten Darstellbarkeit als normales Text -) gewaltig:
Man hat nicht benutzte Ascii-Zeichen als Steuerungszeichen übrig und kann in einfachster Weise eine hochstabile und schnellstmögliche Übertragung herstellen. Insbesondere ist es das Zeilende-Zeichen, welches als Markierung für das Ende eines Datensatzes in beiden Richtungen benutzt wird - so auch hier. Aber leider nur im Protokoll, nicht in deinem VI.
VI-Read wartet im Falle der Aktivierung der Zeilenende-Erkennung, bis der vollständige Datensatz im Puffer ist uns liest den dann aus. Man braucht dann nicht solchen Schnulli wir "Warten" und "Bytes at Board".

Hallo Lucki,


Danke für deine Antwort.
Tur mir leid, wenn Ich dich damit nerve. Ich habe in meinem VI die "überflüssigen" Elemente entfernt. Die Zeilenende-Erkennung müsste der Sensor doch durch den Code 0x0A erkennen oder muss Ich das im VI durch ein Element bestimmen?


Entschuldigt, wenn euch diese Fragen zu einfach erscheinen. Ich habe vor kurzem erst angefangen und bin dringend auf eure Hilfe angewiesen.


Prama

Die Umstellung geht in die richtige Richtung, ist aber noch nicht komplett. Es fehlt:
1.) Die Konstante "Enable TermChar" in der Konfiguration muß True sein (oder weggelassen werden, weil default)
2.) Als "Byte-Anzahl" bei dem Read-VI muss eine Konstante angeschlossen werden, die garantiert größer ist als die Länge des erwartenden Datensatzes.

Mein "genervt sein" war a) nicht wirklich, sondern rein rhetorisch , und b) überhaupt nicht wegen Dir, sonderen weil ich unter den versammelten Super-Gurus bei solchen Threads immer der Einzige bin, der auf diese komfortable Steuerungsmöglichkleit mit Zeilenende-Zeichen hinweist.

Gruß Ludwig

Hallo Ludwig,

Danke für deine Ratschläge.
Ich habe deine Tipps eingearbeitet und erhalte bei der Version ohne die Pause einen Zeitüberschreitungsfehler. Mit Pause vor VISA READ erhalte Ich keine Fehlermeldung, aber die Reaktion des Sensors ist unverändert.

Hat der Sensor das Zeichenende-Zeichen nicht erhalten?
Gibt es eine andere Möglichkeit den Sensor mit LabVIEW anzusprechen oder bin ich mit meiner Version nicht weit entfernt vom Ziel?


Prama