BCC berechnen

Andi schrieb:

> Das Telegramm sieht demensprechend z.B. so aus...
> STX 0x01 0x02 0x03 0x04 0x05 0x06 0x07 DLE ETX BCC
>
> Ich seh das so das ich nun von 0x01 bis ETX alles xodern muss und das
> das BCC ist. Leider tut das nicht, auch ohne DLE, oder ohne DLE und ETX
> stimmt das BCC leider nicht...

Nimm mal probehalber das STX auch noch mit dazu.


> Für das Beispiel bekomm ich 0x13 heraus...

Weißt du, was rauskommen muss?
(Beispiel aus der Doku?)

Was tut nicht? Reagiert das Euchner-EKS nicht?

Schau mal nach, welche ASCII-Codes STX und ETX haben und vergleich das
mit deinen Datenbytes. Merkst du etwas?

Edit: Hmm, das sollte eigentlich nichts ausmachen. Nur das DLE muss
innerhalb der Nutzdaten gesondert behandelt (d.h. verdoppelt) werden.

Aber schreib doch mal, was genau nicht funktioniert.

Andi schrieb:
> SENDE:     STX (0x02)
> EMPFANGE:  DLE vom Gerät (0x10)
> SENDE:     0x07 0x54 0x4C 0x01 0x00 0x00 0x74   (Datenbytes)
> SENDE:     0x10 0x03 BCC                        (Ende Übertragung)

Das sieht gut aus, BCC=0x79 ebenfalls.

Ich nehme an, dass du nach dem Senden von STX wartest, bis das DLE vom
EKS eintrifft. Erst dann darf das nächste Byte (0x07) gesendet werden.

Nach dem Empfang des DLE müssen die restlichen Bytes (02 07 54 4C 01 00
00 74 10 03 79) in einem Rutsch gesendet werden, d.h. die Pause zwischen
zwei Bytes darv maximal 100ms betragen.

> aber jede weitere übertragung bekomm ich nach ca. 2 sek quittiert mit
> NAK (0x15).

Wann kommt das NAK vom EKS? 2s nach dem Senden des letzten Bytes (BCC)?
Wenn der BCC nicht stimmen würde, hätte ich erwartet, dass das NAK vom
EKS ohne merklichen Zeitverzug nach dem Empfang des fehlerhaften BCC
gesendet wird.

Bist du sicher, dass die Bytes tatsächlich so gesendet werden, wie du
dir das vorstellst? Du könntest testweise statt des EKS einen zweiten PC
(oder die zweite serielle Schnittstelle des sendenden PCs) anschließen
und damit prüfen, was tatsächlich zur Schnittstelle hinausgeht. Wenn du
bspw. versehentlich das XON/XOFF-Protokoll aktiviert hast, fügt der
Schnittstellentreiber zusätzliche Steuerbytes in den Datenstrom ein, von
denen du applikationsseitig nichts mitbekommst. Das darf natürlich nicht
sein.