Hallo, ich habe eine Problem damit das BCC (Blockprüfzeichen) zu berechnen. Selbst die Suche hier und beim großen G hat wenig gebracht... darum hier. Aus der Anleitung: ...das Blockprüfzeichen BCC ist die gerade Längsparität (XOR-Verknüpfung aller Datenbytes) eines ... Blocks. Die Bildung des Blockprüfzeichens beginnt mit dem ersten Byte des Telegramm-Kerns ... und endet nach den Zeichen DLE und ETX beim Verbindungsabbau. 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... oder rechne ich falsch? Für das Beispiel bekomm ich 0x13 heraus... (mit DLE und ETX) und 0x00 ohne DLE und ETX... kann mir jemand helfen???
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.
Ne, ich hab leider eben kein Beispiel... was dabei rauskommen sollte... Yalu X.... Ne, das EKS macht keinen Mucks... ;-) bzw. nach STX bekomm ich sauber (wie im Datenblatt beschrieben) ein DLE (0x10)... aber jede weitere übertragung bekomm ich nach ca. 2 sek quittiert mit NAK (0x15).. Yalu was meinst du damit?? STX (0x02) und ETX (0x03)... ok ok, das beispiel ist schlecht gewählt weil Steuerzeichen... aber sollte ja auch nur ein Beispiel sein.... Hätt ja auch 0xA1 0xA2 0xA3 u.s.w. nehmen können... Also Ablaufen tut das so.... SENDE: STX (0x02) EMPFANGE: DLE vom Gerät (0x10) SENDE: 0x07 0x54 0x4C 0x01 0x00 0x00 0x74 (Datenbytes) SENDE: 0x10 0x03 BCC (Ende Übertragung) EMPFANGE: 0x15 (NAK) Das Datenbyte ist so gegliedert Adresse (0x07) TR (auslesen 0x54 0x4C) Adresse-gerät (0x01) Ab Speicher (0x00 0x00) Anzahl Bytes (0x74) Sprich, aktuell sieht meine Übertragung so aus... 02 07 54 4C 01 00 00 74 10 03 BCC und für den BCC rechne ich aktuell 0x79... aber das tut einfach nicht... :-(
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.
ok... es hat sich tatsächlich ein Fehler eingeschlichen... BCC war korrekt brechnet. Hab das mit nem Port Monitor rausgefunden. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.