unbekannte Steuerzeichen

MFreiberger

Level-3
Beiträge
2.812
Reaktionspunkte
741
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Zusammen,

wir haben für ein RetroFit die Schnittstelle bei einem Kunden mit geschrieben.
Die meisten Daten lassen sich ja auch einfach erklären: 0-9; A-Z; Sonderzeichen entsprechen idR Bitfeldern. Das kann man alles schön analysieren.
Allerdings gibt es da auch noch unklare Daten. Ich vermute Steuerzeichen.
[STX] und [ETX] sind mir klar.

Aber was bedeuten die Daten (vielleicht Steuerzeichen?):
[fd]
[ff]
[f9]
[f1]
[b1]
[b7]

Vielleicht hat ja Jemand eine Idee? Zum normalen ASCII-Zeichensatz gehören sie jedenfalls nicht.

VG

MFreiberger
 
Also ... Steuerzeichen sind das nicht - findest du eigentlich nur im Bereich 0..31 des Bytewerts.
Ich tippe hier auf Bitmuster oder ggf. sogar Werte - dazu müßtest du eigentlich eher etwas sagen können, denn du müßtest ja wissen, was du da rausschickst bzw. erwartest (kommen die Daten oder gehen die ?).

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Larry,

also die übertragene Telegrammlänge beinhaltet immer 52 Zeichen (Byte).
Ich kann mir grundsätzlich auch vorstellen, dass es sich um ein Bitmuster handelt. Allerdings muss ich wohl die unbekannten Daten als ein Byte bewerten, da andernfalls die Telegrammlänge nicht stimmt.

In dem Bereich des Telegramms, in dem die Daten stehen, sieht das so aus:

r;[fb][ff]
;[b1][b7]:

das sollen Jeweils 4 Byte sein. ein 'r', ein ';' und ein ':' kann ich in ein Bitmuster übertragen. Aber was ist diesen Unbekannten?

Es handelt sich wohl um eine Teil einer Identifikationsnummer:
Diese ist 8-stellig. Wir haben folgende Nummern "gesehen":

'0000r;[f9][fd]'
'0000r;[fd]>'
'0000r;[fb][f1]'

Nicht verwendete Stellen werden mit '0' aufgefüllt.

Die Daten werden von der Steuerung auch nur gespiegelt. Gesendet werden die Daten von einer S5 über RS232 (RK3964r).



VG

MFreiberger
 
Zuletzt bearbeitet:
Gibt es für das Telegramm keine Dokumentation des Aufbaus und Inhalts?
Zeig doch mal das gesamte Telegramm. Vielleicht sind es schlicht binäre Daten (INT, UINT, REAL, ...) oder Teil einer Prüfsumme.

Allerdings muss ich wohl die unbekannten Daten als ein Byte bewerten, da andernfalls die Telegrammlänge nicht stimmt.
Für die Telegrammlänge spielt es keine Rolle ob das einzelne selbständige Bytes sind oder 4 aufeinanderfolgende Bytes bilden einen REAL oder ... Die Telegrammlänge wird bestimmt nicht in "Anzahl Werte im Telegramm" angegeben.

Harald
 
Moin PN/DP,


Gibt es für das Telegramm keine Dokumentation des Aufbaus und Inhalts? Zeig doch mal das gesamte Telegramm.

Doch, die gibt es.Tele1.JPGTele2.JPGTele3.JPG


Vielleicht sind es schlicht binäre Daten (INT, UINT, REAL, ...) oder Teil einer Prüfsumme.

ich denke das kann ich ausschließen. In der Dokumentation handelt es sich um einen Telegrammaufbau mit fixer Länge.


Für die Telegrammlänge spielt es keine Rolle ob das einzelne selbständige Bytes sind oder 4 aufeinanderfolgende Bytes bilden einen REAL oder ... Die Telegrammlänge wird bestimmt nicht in "Anzahl Werte im Telegramm" angegeben.

Das die Länge nicht vom Datentyp abhängig ist ist mir klar. Die Telegrammlänge ist einfach fix definiert.


VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wo genau/an welcher Stelle des Telegramms treten denn die Zeichen auf? In der Palettennummer? Laut der Beschreibung dürften in dem gesamten Telegramm auch keine Buchstaben und Semikolons vorkommen, sondern ausschließlich Ziffern. Ist das richtige Beschreibung? Stimmen die Palettennummern PPPPPPPP mit den tatsächlichen Palettennummern überein? Haben die Palettennummern vielleicht (unvorhergesehen?) Sonderzeichen oder liefert irgendein Lesegerät (fälschlicherweise?) die komischen Zeichen?
Wo hast Du die Zeichen gesehen? Auf der Kommunikationsleitung geschniffert oder beobachtest Du Speicher-Variablen in der SPS? Beobachtest Du tatsächlich den richtigen unverfälschten und gültigen/konsistenten Empfangspuffer?
Ist das Telegramm wirklich 52 Bytes lang? Dann werden wohl die Zahlen im Klartext als ASCII-Wert der Ziffern übertragen. Oder sind das nur 26 Bytes und alle Zahlen sind BCD?

Harald
 
Code:
Allerdings muss ich wohl die unbekannten Daten als ein Byte bewerten, da andernfalls die Telegrammlänge nicht stimmt.
Diesen Satz habe ich leider nicht verstanden. Meinst Du jedes der 4 misteriösen Bytes als 1 Byte zählen?

Habe mal mit Excel gespielt und folgendes probiert:
Code:
[FONT=courier new]FBFFB1B7             hex
4227838391           gewandelt in dez
42278,38391          Komma eingefügt
2015-10-01 09:12:50  und In Excel mit "JJJJ-MM-TT hh:mm:ss" formatiert
[/FONT]Sieht das denn plausibel aus???

Gruss, Heinileini
 
Moin PN/DP,

Wo genau/an welcher Stelle des Telegramms treten denn die Zeichen auf? In der Palettennummer?

ja, genau, es ist die Palettennummer.


Laut der Beschreibung dürften in dem gesamten Telegramm auch keine Buchstaben und Semikolons vorkommen, sondern ausschließlich Ziffern.

Wo liest Du das denn heraus?
Es sind ja auch Angaben wie 'R' für Regal und 'KP' für Kommissionierplatz enthalten.


Ist das richtige Beschreibung?

ja


Stimmen die Palettennummern PPPPPPPP mit den tatsächlichen Palettennummern überein? Haben die Palettennummern vielleicht (unvorhergesehen?) Sonderzeichen oder liefert irgendein Lesegerät (fälschlicherweise?) die komischen Zeichen?

Guter Hinweis. Das kann natürlich sein.


Wo hast Du die Zeichen gesehen? Auf der Kommunikationsleitung geschniffert oder beobachtest Du Speicher-Variablen in der SPS? Beobachtest Du tatsächlich den richtigen unverfälschten und gültigen/konsistenten Empfangspuffer?

Kommunikationsleitung gesniffert.


Ist das Telegramm wirklich 52 Bytes lang? Dann werden wohl die Zahlen im Klartext als ASCII-Wert der Ziffern übertragen. Oder sind das nur 26 Bytes und alle Zahlen sind BCD?

Das Telergramm IST 52 Zeichen lang. Es sind keine BCD-Zeichen. Ja, es handelt sich immer um ASCII-Zeichen.


VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir haben folgende Nummern "gesehen":

'0000r;[f9][fd]'
'0000r;[fd]>'
'0000r;[fb][f1]'

Wenn du z.B. das obige gesniffert hast ... was wurde dann tatsächlich gesendet ? Also was sollte das dann tatsächlich bedeuten ?
Ich denke mal, dass Heinileini hier schon auf dem richtigen Weg war - vielleicht wird jede der Nummern tatsächlich als Wert übertragen - es müssen also z.B. 4 aufeinanderfolgende Bytes (sinnvoll) in einen DINT übertragen werden und so bewertet werden. Wie schon von Harald geschrieben : der Inhalt (und dessen Interpretation) hat nichts mit der Telegrammlänge zu tun ...

Gruß
Larry
 
Moin Heinilein,


Meinst Du jedes der 4 misteriösen Bytes als 1 Byte zählen?

ich gehe ja davon aus, dass es sich um 1-Byte-Werte handelt. [STX], [DEL], [ETX] usw. sind ja auch nicht 5Byte lang, sondern 1Byte

Leider habe ich die Schnittstelle nicht selber mitgesniffert, sondern ein anderer Mitarbeiter. Die Hex-Werte der Bytes habe ich nicht. Daher möchte ich ja aus dem, was ich habe, Rückschlüsse auf den Wert oder die Bitfolge ziehen. Anhand der Dokumentation gehe ich von der Palettennummer aus.

Derzeit leuchtet mir der Hinweis von PN/DP am ehesten ein, dass es vom Lesegerät kommt.

Habe mal mit Excel gespielt und folgendes probiert:
Code:
[FONT=courier new]FBFFB1B7             hex
4227838391           gewandelt in dez
42278,38391          Komma eingefügt
2015-10-01 09:12:50  und In Excel mit "JJJJ-MM-TT hh:mm:ss" formatiert
[/FONT][FONT=courier new]
[/FONT]Sieht das denn plausibel aus???
[/QUOTE]

Ja, mit Excel hatte ich auch schon experimentiert. Leider ohne plausiblen Erfolg. Deinen Ansatz werde ich aber noch einmal prüfen.

Alles in Allem komme ich auch so zurecht, da ich diesen Telegrammteil höchstens spiegeln muss. Mich hätte einfach nur interessiert, was die Information bedeutet.

VG

MFreiberger
 
Es könnte z.B. so etwas heißen :
00 00 FD F9 und das ergäbe dann 65017 als Betrag.
oder :
F9 FD 00 00 und das ergäbe dann 4194107392.
oder jede weitere beliebige Byte-Reihenfolge ergäbe dann andere Zahlenwerte. Des halb hätte mich interessiert, was das RBG ausgegeben hat - dann könnte man daraus Rückschlüsse ziehen ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Larry,

ja, der Inhalt hat grundsätzlich erst einmal nichts mit der Telegrammlänge zu tun. Allerdings ist dieser auf 52 Zeichen fixiert. Daher muss ein Wert, der in eckige Klammern gesetzt ist, ein Byte lang sein. Andernfalls hätten wir ja unterschiedliche Telegrammlängen zwischen '0000r;[f9][fd]' und '0000r;[fd]>'. Diese sind aber nicht unterschiedlich (beschränken sich weiterhin auf 52 Byte).
Erschwerend kommt hinzu, dass die RBG-Steuerung, wenn eine Palette nicht identifiziert ist, eine '11111111' an die übergeordnete S5 sendet. Das sind ja auch nur acht Byte.

VG

MFreiberger
 
Moin Larry,

weil mich nichts weitergebracht hat (z.B. die Werte als Hex-Werte zu interpretieren), hatte ich ja darüber nachgedacht, ob es Steuerzeichen sein könnten. In der ASCII-Tabelle kommen sie nicht vor und ich habe diese Art Steuerzeichen bisher auch noch nirgendwo sonst gefunden.

VG

MFreiberger
 
ich denke das kann ich ausschließen. In der Dokumentation handelt es sich um einen Telegrammaufbau mit fixer Länge.
. . .
Das die Länge nicht vom Datentyp abhängig ist ist mir klar. Die Telegrammlänge ist einfach fix definiert.
Im Zusammenhang mit INT, UINT, REAL betonst Du die fixe TelegrammLänge.
Dann sagst Du, es sei Dir klar, dass die Länge nicht vom DatenTyp abhängt.
Was denn nun? Verstehe ich nicht.
Der Beschreibung nach würde ich auch nur ASCII-Zeichen erwarten.
Sind denn Sender und Sniffer bezüglich der Anzahl DatenBits und bezüglich mit/ohne Parity konform?
Sind die BaudRaten von Sender und Sniffer "genau genug" identisch? Wird vielleicht nur ein Bisschen abgewichen, sodass einzelne Bits geschlabbert oder hinzugedichtet werden? Aber "FFhex" enthält eigentlich schon zuviele aufeinander folgende Einsen, um das als plausibel erscheinen zu lassen.

Kommt im Telegramm das Zeichen DLE (10hex) vor? Sind sich Sender und Sniffer einig, dass das Zeichen doppelt gesendet wird? Wenn nur "lesbare" ASCII-Zeichen im DatenBereich übertragen werden, können wir diesen Fall wohl ausschliessen. Ausserdem wäre es ungewöhnlich, wenn das DLE-Zeichen einerseits im Telegramm verdoppelt wird, ohne im CRC doppelt zu erscheinen (oder umgekehrt) - dann sollte zumindest ein CRC-Fehler gemeldet werden.
Kannst Du beim Sender nachvollziehen, welche Daten er senden will?
Tritt Dein Phänomen sporadisch auf oder immer (an der selben Stelle des Telegramms)?
Kann es sein, dass die Beschreibung irgendwann mal korrekt war, aber dann die Belegung des Telegramms geändert wurde aber in der Doku nicht (z.B., um mehr Informationen in die 52 Byte zu packen)?
Wird die PalettenNr von einem LeseGerät übernommen und hat sich da mal etwas geändert?
Wielange das Phänomen schon auftritt, weiss vermutlich auch niemand? Es wurde anlässlich des Retrofit lediglich "entarnt"?
 
Moin Heinilein,

Im Zusammenhang mit INT, UINT, REAL betonst Du die fixe TelegrammLänge.
Dann sagst Du, es sei Dir klar, dass die Länge nicht vom DatenTyp abhängt.
Was denn nun? Verstehe ich nicht.

Ich wollte erklären, dass es sich um eine fixe Telegrammlänge handelt. Des Weiteren wollte ich erklären, dass die Länge eines Datentyps nicht davon abhängt, ob es ein DINT, REAL oder DWORD ist. Ich bin einfach davon ausgegangen, dass es sich hier nicht um unterschiedlich zu interpretierende Datentypen handelt, sondern dieser Datenbereich (egal wie er interpretiert wird), ein Byte umfasst.

Der Beschreibung nach würde ich auch nur ASCII-Zeichen erwarten.
Sind denn Sender und Sniffer bezüglich der Anzahl DatenBits und bezüglich mit/ohne Parity konform?
Sind die BaudRaten von Sender und Sniffer "genau genug" identisch? Wird vielleicht nur ein Bisschen abgewichen, sodass einzelne Bits geschlabbert oder hinzugedichtet werden? Aber "FFhex" enthält eigentlich schon zuviele aufeinander folgende Einsen, um das als plausibel erscheinen zu lassen.

Oh, das muss ich recherchieren.

Kommt im Telegramm das Zeichen DLE (10hex) vor?

ja


Sind sich Sender und Sniffer einig, dass das Zeichen doppelt gesendet wird? Wenn nur "lesbare" ASCII-Zeichen im DatenBereich übertragen werden, können wir diesen Fall wohl ausschliessen. Ausserdem wäre es ungewöhnlich, wenn das DLE-Zeichen einerseits im Telegramm verdoppelt wird, ohne im CRC doppelt zu erscheinen (oder umgekehrt) - dann sollte zumindest ein CRC-Fehler gemeldet werden.
Kannst Du beim Sender nachvollziehen, welche Daten er senden will?
Tritt Dein Phänomen sporadisch auf oder immer (an der selben Stelle des Telegramms)?
Kann es sein, dass die Beschreibung irgendwann mal korrekt war, aber dann die Belegung des Telegramms geändert wurde aber in der Doku nicht (z.B., um mehr Informationen in die 52 Byte zu packen)?

Auch wenn die Wahrscheinlichkeit gering ist, kann ich nicht ausschließen, dass sich mal was geändert hat.

Wird die PalettenNr von einem LeseGerät übernommen und hat sich da mal etwas geändert?
Wielange das Phänomen schon auftritt, weiss vermutlich auch niemand? Es wurde anlässlich des Retrofit lediglich "entarnt"?

Klar. Das ist möglich.


Hier noch ein Mitschnitt des Telegrammverkehrs, der mit zugesendet wurde:

Mitschnitte.JPG

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube nicht daß das Telegramm falsch geschniffert wurde. Ich vermute, daß irgendwann mal die Übertragung der Palettennummer gegenüber der Telegramm-Beschreibung geändert wurde, vielleicht haben 8 Ziffern nicht mehr ausgereicht und man hat kurzerhand auf binäre Codierung (z.B. DINT) umgestellt. Oder daß da nun ein Lesefehler oder Programmfehler auffällig wird.
Funktioniert die Anlage noch? Kann mal mit echten Paletten mit bekannten Palettennummern getestet werden und verglichen werden, wie die Palettennummern in dem Telegramm aussehen?

Laut der Beschreibung dürften in dem gesamten Telegramm auch keine Buchstaben und Semikolons vorkommen, sondern ausschließlich Ziffern.
Wo liest Du das denn heraus?
Es sind ja auch Angaben wie 'R' für Regal und 'KP' für Kommissionierplatz enthalten.
OK, hast recht. Diese Stelle habe ich nur oberflächlich gelesen.

Harald
 
Es scheint doch reproduzierbar zu sein und es sind anscheinend immer die letzten 6 Byte betroffen.
Das 'r' passt nicht zu den sonst ausschliesslich verwendeten GrossBuchstaben. Die ';' und ':' sind vermutlich anders zu interpretierende Bytes, die nur zufällig auch als ASCII-Zeichen deutbar sind.
Meinen Verdacht, dass Datum und Uhrzeit dahinterstecken könnten, ziehe ich zurück.
Die Daten, die ich da zusammen gepfriemelt hatte, stammen ja aus unterschiedlichen Telegrammen. Und es wäre wohl auch nicht zu erwarten, dass etwas µSoft-basiertes dahintersteckt. :ROFLMAO:
DLE im DatenBereich sehe ich nicht, sondern erst dahinter. DLE ETX sieht ganz unverdächtig aus.
Nach geschlabberten oder eingefügten Bits brauchen wir auch nicht zu forschen, da sich das Problem immer nur bei den letzten 6 Byte zeigt. Hier wurde höchstwahrscheinlich die Belegung geändert, um mehr Information in die 52 Byte der Telegramme zu quetschen.

Edit:
Code:
r;[fb][ff]  ==> 723BFBFF ==> 1916533759
;[b1][b7]:  ==> 3BB1B73A ==> 1001502522
Könnten das 10-stellige PalettenNrn sein?
Das sind die ersten 4 der letzten 6 Byte. Die beiden letzten sind in den Telegrammen anscheinend immer ASCII Nullen, evtl. Reserve seit der BelegungsÄnderung?
 
Zuletzt bearbeitet:
Moin PN/DP,

Ich glaube nicht daß das Telegramm falsch geschniffert wurde. Ich vermute, daß irgendwann mal die Übertragung der Palettennummer gegenüber der Telegramm-Beschreibung geändert wurde, vielleicht haben 8 Ziffern nicht mehr ausgereicht und man hat kurzerhand auf binäre Codierung (z.B. DINT) umgestellt. Oder daß da nun ein Lesefehler oder Programmfehler auffällig wird.

Der Meinung bin ich auch. Da ich die Daten sowieso nicht auswerte und nur weiterreiche bzw. spiegel, werde ich in das Thema jetzt nicht mehr Energie reinstecken.


Funktioniert die Anlage noch? Kann mal mit echten Paletten mit bekannten Palettennummern getestet werden und verglichen werden, wie die Palettennummern in dem Telegramm aussehen?

Ja, die Anlage funktioniert. Einen Test werden wir mal durchführen.



Vielen Dank für Eure Hilfe und Ideen/Anregungen zur Analyse!

VG

MFreiberger
 
Zurück
Oben