MFreiberger
Level-3
- Beiträge
- 2.869
- Reaktionspunkte
- 760
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.Allerdings muss ich wohl die unbekannten Daten als ein Byte bewerten, da andernfalls die Telegrammlänge nicht stimmt.
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.
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.
Diesen Satz habe ich leider nicht verstanden. Meinst Du jedes der 4 misteriösen Bytes als 1 Byte zählen?Allerdings muss ich wohl die unbekannten Daten als ein Byte bewerten, da andernfalls die Telegrammlänge nicht stimmt.
[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
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?
Wir haben folgende Nummern "gesehen":
'0000r;[f9][fd]'
'0000r;[fd]>'
'0000r;[fb][f1]'
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][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
Im Zusammenhang mit INT, UINT, REAL betonst Du die fixe TelegrammLänge.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"?
OK, hast recht. Diese Stelle habe ich nur oberflächlich gelesen.Wo liest Du das denn heraus?Laut der Beschreibung dürften in dem gesamten Telegramm auch keine Buchstaben und Semikolons vorkommen, sondern ausschließlich Ziffern.
Es sind ja auch Angaben wie 'R' für Regal und 'KP' für Kommissionierplatz enthalten.
r;[fb][ff] ==> 723BFBFF ==> 1916533759
;[b1][b7]: ==> 3BB1B73A ==> 1001502522
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?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?