HEX Länge ermitteln

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
sparrow
User
Beiträge: 4621
Registriert: Freitag 17. April 2009, 10:28

kiaralle hat geschrieben: Sonntag 11. Januar 2026, 16:05 Das ist doch das, was ich vom Geber zurück bekomme.
Laut Beschreibung "Pos.abfragen" Befehl 42

40 42 00 00 4d 8e c1

40 = Geräteadresse
42 = Befehl, Position abfragen
00+00+46+8e = Position = int.from_bytes(response[2:6],'big',signed=False)
c1 sollte, ist Checksum

Im Fehlerfall sollte ich doch soetwas bekommen

40 42 c1
Wo steht das?
Ich habe dir doch sogar den Quote aus der Dokumentation gepostet.


Die Prüfung auf das 8. Bit (Warnungen liegen vor) hat Sirius3 übrigens in seinem Code schon berücksichtigt.
Wenn du seinen Code nimmst, bist du schon einmal Lichtjahre weiter. Da noch die Prüfung für den Fehlerfall rein (also nicht das Errorbit->Warnungen, weil das schon drin ist), dann ist das hoffentlich robust.
kiaralle
User
Beiträge: 163
Registriert: Donnerstag 19. August 2021, 19:11

Laut Dokumentation lesen wir doch 1 Byte aus.

Start | 1| 2 | 3 | 4| 5| 6| 7 | 8 Errorbit| ...

1-6 ist 6Bit Command

das 6 Bit Command ist unterschiedlich lang. Je nach Befehl kommt es unterschiedlich lang zurück.

Errorbit ist immer die Nr.8

Wir lesen ser.read(7) weil wir von 0 -7 = 8 lesen.

Geht ihr da mit?

Im Fehlerfall wird nur ein kurzes Datenbit mit der Fehlernummer gesendet. es sollte dann reichen nur das erste Bit vom den 6Bit zu lesen.
Benutzeravatar
sparrow
User
Beiträge: 4621
Registriert: Freitag 17. April 2009, 10:28

Nein, da gehe ich nicht mit.
Bitte trenn dich mal von deinem Errorbit. Du hast dich da verbissen und bist auf dem falschen Weg.

Noch einmal die Quote aus der Dokumentation:
https://www.audin.fr/pdf/documentations/sick/codeurs/HIPERFACE.pdf hat geschrieben:Commands which cannot be processed (protocol errors, command arguments or internal MFB errors) lead to
the command processing being cancelled and the MFB responding with an error protocol
(see command 50h)
Und falls das mit den Englisch schwierig ist:
Befehle, die nicht ausgeführt weredn können (Proktollfehler, Befehlsargumente oder wegen eines internen MFB Fehlers) führen dazu, dass die Ausführung abgebrochen wird und das MFB mit einem Error-Protkoll antwortet (siehe Kommand 50h)
Das steht nichs von einem Errorbit.
Dein Errorbit gibt es nur bei Warnungen. Es tritt in deinem Beispiel aber ein _Fehler_ auf. Und das ist etwas anderes als eine _Warnung_. Deshalb ist das in der Dokumentation auch getrennt.

Und diesen Fehlerfall hast du präsentiert und er passt zur Dokumentation.
Zuletzt geändert von sparrow am Sonntag 11. Januar 2026, 16:27, insgesamt 1-mal geändert.
kiaralle
User
Beiträge: 163
Registriert: Donnerstag 19. August 2021, 19:11

sparrow hat geschrieben: Sonntag 11. Januar 2026, 15:52
kiaralle hat geschrieben: Sonntag 11. Januar 2026, 15:41 '\x40\x50\x0c\x1c'

Hab ich wo stehen?

Ich bekomme im Fehlerfall nur b'@P\x0c\x1c'
Weißt du was HEX ist? Also Hexadezimaldarstellung?
Falls nicht, musst du dir das jetzt anlesen. Denn darauf basiert deine Dokumentation.

Code: Alles auswählen

>>> b'@P' == b'\x40\x50'
True
>>> b'@P\x0c\x1c'.hex()
'40500c1c'
Danke @sparrow

mit einem response.hex() erhalte ich natürlich die Adresse 40, mit der Fehlermeldung 50 und dem Fehlercode 0c

Danke. Huch war das jetzt wieder wild für mich :-)
Antworten