TIA LOpenUserComm_Tcp Offset von 14 Bytes bei rcvData

[HF_SPSler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe ein seltsames Phänomen bei der TCP Kommunikation zwischen einer S7 1212 DC/DC/DC Firmware 4.7.0 und einem externen, per TCP angebundenen Datenlogger. Der Datenlogger wird im eigenen Haus entwickelt und ich stehe in Kontakt mit dem C-Programmierer der die Firmware des Loggers betreut. Die eingelesenen Daten haben immer einen Offset von 14 im Array der empfangenen Daten.

REGION OpenUserCommunication
    
    #LOpenUserComm_Tcp(enable := #E_ENABLE,
                       sendRequest := #locals.sendRequest,
                       rcvLen := #RCV_LEN,
                       sendLen := #SND_LEN,
                       adhocMode := FALSE,
                       tcpConnParam := #tcpConnParam,
                       connectionEstablished => #tmp_con_estab,
                       error => #locals.error,
                       statusID => #locals.statusID,
                       status => #locals.statusWRD,
                       sendData := #DB_SENDDATA,
                       rcvData := #DB_RECEIVEDATA);
    
    IF NOT #E_ENABLE THEN
        FOR #i := 0 TO 65 DO
            #DB_RECEIVEDATA[#i] := 0;
        END_FOR;
    END_IF;
    
END_REGION

Die von TRCV emfpangenen Daten werden immer mit einem Offset von 14 eingelesen:



Ich hab jetzt zwei verschieden lange Datenbereiche getestet. Eigentlich benötige ich nur 16 Byte als rcv Daten auf der SPS Seite, daher starteten wir zunächst mit 16 Byte. Da in der Doku der TRCV empfohlen wird Lese- und Sendedaten gleich lang zu gestalten und dem Datenlogger 66 Byte Daten gesendet werden haben wir nun auch die von SPS Seite zu empfangenen Daten auf 66 Byte erhöht. Der Offset von 14 bleibt.

Ein Screenshot aus Wireshark sollte belegen, dass es in den am Datenlogger ausgehenden Daten keinen Offset gibt:



Kann das möglichweise an einer Fehlkonfiguration meinerseits an der Nutzung der Siemens Bibliothek "LOpenUserComm_Tcp" liegen? Wir können uns nicht erklären woher dieser Offset kommt.

 

[UDP]

Wenn ich mir jetzt nur mal die Daten bei dir im Empfangspuffer anschaue, sieht es aus als ob die Werte von 0-15 noch vom vorherigen Telegramm stammen (also in Fach 0 steht Dez 52 und aufsteigend).

Ich kenne das Problem manchmal, wenn mit der Verbindungslänge einer aktiven Verbindung "gespielt" wurde, dass dann die Telegramm nicht mehr sauber zusammen gesetzt werden. Hier werden also die 66 Byte aus dem vorletzten und dem letzten Telegramm zusammen gesetzt.

Verbindung mal sauber abbauen und wieder aufbauen, ansonsten mal SPS spannungslos versuchen haben mir da schon häufig geholfen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich tippe auch darauf, dass da mal beim Spielen zu wenig Zeichen abgeholt wurden und nun dauerhaft Zeichen abgeholt werden, die eigentlich zur vorherigen Nachricht gehören. Lösung: Verbindung abbauen, damit der Empfangspuffer gelöscht wird, oder einzelzeichenweise die zu vielen Zeichen aus dem Empfangspuffer holen. TCP ist ein Datenstream, in dem die Anfänge der einzelnen Datenpakete (im Nachhinein) nicht zu erkennen sind. Bei Bedarf muss man Rahmenzeichen in das Protokoll einbauen.

Da in der Doku der TRCV empfohlen wird Lese- und Sendedaten gleich lang zu gestalten

Habe ich noch nie gehört. Wo wird das empfohlen?
Ich weiß nur, dass es vorteilhaft ist, alle zu sendenden Nachrichten gleich lang zu machen, damit sich der Empfänger nicht einzelzeichenweise auf Rahmenzeichen im Protokoll synchronisieren muss.

 

[HF_SPSler]

Verbindung mal sauber abbauen und wieder aufbauen, ansonsten mal SPS spannungslos versuchen haben mir da schon häufig geholfen.

Danke für die super schnelle Rückmeldung! Ich hab im Eröffnungspost nicht erwähnt, dass der Datenlogger testweise gerade 66 Inkremente schickt. Diese Information wollte ich hiermit noch nachreichen, sorry.

Ein Trennen der Verbindung und auch ein spannungslos schalten der SPS brachte hier keine Abhilfe.

Ich kenne das Problem manchmal, wenn mit der Verbindungslänge einer aktiven Verbindung "gespielt" wurde, dass dann die Telegramm nicht mehr sauber zusammen gesetzt werden. Hier werden also die 66 Byte aus dem vorletzten und dem letzten Telegramm zusammen gesetzt.

Sind die zu übertragenden Daten von 66 Byte nicht laut Wireshark alle im gleichen Telegramm?

Habe ich noch nie gehört. Wo wird das empfohlen?

Auszug aus der TIA Hilfe zu TRCV: Daten über Kommunikationsverbindung empfangen

Verbindung abbauen, damit der Empfangspuffer gelöscht wird, oder einzelzeichenweise die zu vielen Zeichen aus dem Empfangspuffer holen.

Wie ich schon erwähnte, Verbindung abbauen und/oder Spannungsunterbrechung brachten kein Erfolg. Ich bin auf dem Gebiet noch nicht so bewandert, wie holt man denn dann einzelzeichenweise die "zu vielen Zeichen" aus dem Eingangspuffer?

Wobei mich hierbei irritiert, dass die Daten immer wieder so aussehen wie in meinem Eröffnungspost geschrieben. Demnach wären dann immer wieder "zu viele" bzw. veraltete Daten im Eingangspuffer?

 

[UDP]

Rein aus Interesse, kannst du von dem Datenlogger mal nur ein Telegramm schicken lassen? Oder geht das nicht? Falls nein, speichere dir mal die Daten vom aller ersten Empfanden weg in einen anderen Bereich (und nur beim ersten Mal empfangen), um zu prüfen ob der Fehler schon beim ersten Mal passiert und dann schau dir das Verhalten eine Weile an.

Vorher mal den Bausteinaufruf ein zweites Mal im Programm aufrufen (mit der "korrekten" Länge) und einer neuen Verbindungs-ID? Ist das Verhalten dann identisch?

 

[Rabi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie bereits die anderen gesagt haben, es sieht so aus, als wäre durch das Testen irgendwie ein Versatz bei der Länge passiert.
Trotz Neustart bzw. Rücksetzen der Verbindung, finde ich es dann allerdings merkwürdig, dass es nicht funktioniert.

Eventuell kannst du einmal den ADHoc Modus aktivieren und die Länge auf 0 konfigurieren?
Wenn der Datenlogger nicht zu schnell arbeitet, solltest du dann saubere Telegramme erhalten.

Ggf. kannst du danach wieder die Länge aktivieren und den Modus abschalten.

 

[PN/DP]

Da in der Doku der TRCV empfohlen wird Lese- und Sendedaten gleich lang zu gestalten

Habe ich noch nie gehört. Wo wird das empfohlen?

Auszug aus der TIA Hilfe zu TRCV: Daten über Kommunikationsverbindung empfangen

Anhang anzeigen 86281

Da steht nichts von "Empfangsdaten gleich lang wie Sendedaten", sondern der Empfangspuffer sollte die gleiche Länge wie die vom Partner gesendeten Daten (genau eine Nachricht) haben.

Kann das möglichweise an einer Fehlkonfiguration meinerseits an der Nutzung der Siemens Bibliothek "LOpenUserComm_Tcp" liegen?

Ich kenne die Bibliothek "LOpenUserComm_Tcp" nicht. Könnte es sein, dass die noch zusätzliche Zeichen liefert?

Haben die ersten 14 Zeichen immer den gleichen Inhalt, oder ist unsere Vermutung richtig, dass das die letzten Zeichen von der jeweils vorherigen Nachricht sind?

Beginnt der Datensender nach Verbindungsaufbau neu mit kompletten Nachrichten, oder sendet der "stur" weiter seinen Datenstrom, mit einem zufälligen Anfang oder da wo er zuletzt aufgehört hat?

Vermutlich ist die beste Lösung, (einmalig oder immer, wenn die Lage der Nachricht im Empfangspuffer nicht stimmt) solange einzelzeichenweise die Zeichen abzuholen, bis die Lage/Ausrichtung passt.
Oder wird womöglich beim Abholen ein Zeiger mitgegeben, ab welcher Position die empfangenen Zeichen im Empfangspuffer abgelegt werden sollen? Muss vielleicht dieser Zeiger bei Verbindungsaufbau auf den Anfang des Empfangspuffers gesetzt werden?

 

[UDP]

Kannst du sonst in den Baustein mal reinschauen ob da irgendwo noch im IDB etc. noch alte Daten hängen und der Datenversatz deswegen auch nach Spannungsreset noch ansteht?

Wobei das natürlich auch keine Implementierung sein dürfte, die in den meisten Fällen gewünscht ist.

 

[HF_SPSler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Könnte es sein, dass die noch zusätzliche Zeichen liefert?

Das kann ich aktuell nicht beantworten, ich bin in der Nutzung der Datenübertragung via TCP / IP nicht so bewandert und habe also auch mit der Bibliothek noch zu wenig Erfahrung.

Haben die ersten 14 Zeichen immer den gleichen Inhalt, oder ist unsere Vermutung richtig, dass das die letzten Zeichen von der jeweils vorherigen Nachricht sind?

Es werden aktuell zur Überprüfung einer stabilen Kommunikation seitens des Datenloggers statisch 66 Bytes übermittelt, es stehen also Werte drin die stumpf inkrementiert sind. Byte0 = 0; Byte1=1; Byte2=2 usw. Daher kann ich nicht sagen ob die ersten 14 Byte noch alte Daten aus einem letzten Paket sind. Du stellst mir eine Reihe Fragen bei denen ich denke, wenn ich die beantworten könnte hätte ich das Problem womöglich bereits gefunden und behoben.

Beginnt der Datensender nach Verbindungsaufbau neu mit kompletten Nachrichten, oder sendet der "stur" weiter seinen Datenstrom, mit einem zufälligen Anfang oder da wo er zuletzt aufgehört hat?

Also, über die Bibliothek wird eine TCP Verbindung zum Datenlogger aufgebaut und gehalten bis da Enable flag wieder entzogen wird. Gesendet oder empfangen wird hiermit erst mal noch nichts. Erst mit einer positiven Flanke an "sendRequest" werden Daten gesendet und gelesen, einmalig bis zur nächsten positiven Flanke. Ich lasse diesen Trigger aktuell alle 100ms den "sendRequest" triggern. Ein Datenstrom und damit ein kontinuierliches Senden findet nicht statt.

Oder wird womöglich beim Abholen ein Zeiger mitgegeben, ab welcher Position die empfangenen Zeichen im Empfangspuffer abgelegt werden sollen? Muss vielleicht dieser Zeiger bei Verbindungsaufbau auf den Anfang des Empfangspuffers gesetzt werden?

Zumindest in den Funktionsparametern der Bibliotheksfunktion gibt es keinen Hinweis auf einen Zeiger der z.B. einer Start- oder Endadresse hinweist.

Kannst du sonst in den Baustein mal reinschauen ob da irgendwo noch im IDB etc. noch alte Daten hängen und der Datenversatz deswegen auch nach Spannungsreset noch ansteht?

Wobei das natürlich auch keine Implementierung sein dürfte, die in den meisten Fällen gewünscht ist.

Wir haben in diesem Zusammenhang mal gestestet welcher Inhalt auf SPS Seite ankommt wenn der Datenlogger genau nur ein mal seine Daten sendet. Der Offset bleibt der Gleiche, auch nach einem Powercycle der SPS und Neuverbindung. Daraus würde ich jetzt schließen das es sich nicht um Daten handelt die älter sind als alle ab Byte 14.

 

[UDP]

Schau mal in den Instanz-DB, was dort im Empfangsfach des TRC zu sehen ist, sollte sich unter StatDataBufferRCV finden lassen.

Steht dort auch etwas, wenn die Verbindung deaktiviert ist? Beobachte gerne mal den Teil und schau ob die Daten dort korrekt sind. Bzw. schreib dir die Daten aus dem Fach beim ersten Mal empfangen mit einer Flanke weg und schau, ob es dann zu dem Datenlogger passt.

Testweise könntet ihr ja auch den Inhalt der 66 Bytes mal ändern (z.B. je +66 drauf rechnen) und dann schauen, was beim ersten empfangenen Telegramm im Puffer steht.

 

[PN/DP]

Wenn der Kommunikationspartner nur einmal Daten sendet nach Aufforderung, dann lässt es sich recht einfach feststellen, ob der eigene Empfangsbaustein den Offset verursacht und ob die vorderen Daten aus einem vorhergehenden Telegramm stammen:
1) die Leitung zum Kommunikationspartner unterbrechen (am Partner oder an einem Switch das Netzwerkkabel abziehen) oder den Partner ausschalten (Power off)
2) den Empfangspuffer löschen (mit 0-Bytes überschreiben)
3) am Baustein das enable aktivieren
4) sind jetzt Daten im Empfangspuffer? Dann kommen die aus einem internen Puffer des eigenen Empfangssystems
5) enable deaktivieren
ggf. die Schritte 2 bis 5 so lange wiederholen, bis keine Daten mehr kommen

6) den Empfangspuffer löschen (mit 0-Bytes überschreiben)
7) Netzwerkverbindung wieder herstellen bzw. Partner einschalten
8) enable aktivieren
9) welche Daten sind jetzt im Empfangspuffer? Sind die auch wieder versetzt?

 

[HF_SPSler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also, ich bin deiner schrittweisen Anleitung mal gefolgt.

1. Verbindung physikalisch zum Datenlogger unterbrochen.
2. Empfangspuffer ist vollständig 0 auch ohne ihn bewusst geleert zu haben
3. Enable aktiviert
4. Eingangspuffer ist noch immer leer, also komplett 0
5. Enable entzogen
6. physikalische Verbindung zum Datenlogger wieder hergestellt
7. Enable wieder gesetzt (lese-request aber noch FALSE, hardcodiert)
8. Enable entfernt
9. lese-request (zyklisch alle 100ms) wieder aktiviert
10. Enable wieder gesetzt
11. Daten im Eingangspuffer wieder mit 14 Byte offset

Steht dort auch etwas, wenn die Verbindung deaktiviert ist?

Ja, wenn die Verbindung getrennt wurde bleiben die Daten erhalten.

Die Vorgehensweise mit dem flankengetriggerten Wegspeichern bin ich gerade am Umsetzen.

 

[PN/DP]

9. lese-request (zyklisch alle 100ms) wieder aktiviert

zum testen solltest du aber nur ein einziges mal lesen

11. Daten im Eingangspuffer wieder mit 14 Byte offset

und vor den 14 Byte steht irgendwas <> 0 ? wo du aber nicht weißt, wann und wo das herkam?

Mache nochmal den Test und lese diesmal nur ein einziges Mal in den sicher gelöschten und gelehrten Empfangspuffer

Vielleicht sendet das Gerät direkt nach Verbindungsaufbau erst noch eine 14 Byte lange zusätzliche Nachricht? Vielleicht irgendeine Art "Welcome" oder Gerätename/-status oder irgendwas?
Vielleicht bringt auch mitsniffern des Datenverkehrs etwas Licht ins Dunkel.

 

[NBerger]

Dir ist schon bekannt das bei TCP/IP und fester Empfangslänge stumpf gewartet wird bis die Empfangene Datenlänge erreicht ist, egal ob da noch was kommt oder nicht.

Mir scheint das da ein erstes Telegramm mit 14 Byte kommt was dann zu dem Offset führt.

Synchronisieren muss dann der Anwender selber.

Teste doch mal Empfang mit unbestimmter Länge (adhock) und schau was da so kommt.

 

[HF_SPSler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bzw. schreib dir die Daten aus dem Fach beim ersten Mal empfangen mit einer Flanke weg und schau, ob es dann zu dem Datenlogger passt.

Beim flankengesteuerten Wegschreiben der Daten in einen externen DB steht nach einem Zyklus noch gar nichts drin.

und vor den 14 Byte steht irgendwas <> 0 ? wo du aber nicht weißt, wann und wo das herkam?

Ja richtig, da steht irgendwas.

Teste doch mal Empfang mit unbestimmter Länge (adhock) und schau was da so kommt.

Unter Verwendung von adHoc kommt gar nichts an

 

[PN/DP]

Vielleicht sendet das Gerät direkt nach Verbindungsaufbau erst noch eine 14 Byte lange zusätzliche Nachricht? Vielleicht irgendeine Art "Welcome" oder Gerätename/-status oder irgendwas?
Vielleicht bringt auch mitsniffern des Datenverkehrs etwas Licht ins Dunkel.

Infos dazu sollten in einem Handbuch des Gerätes stehen. Steht da was?

Am einfachsten ist vermutlich, wenn du nur beim ersten Verbindungsaufbau nur 14 Bytes anforderst (und wegspeicherst zum später anschauen) und bei den folgenden Leseanforderungen immer die nominalen 66 Bytes - die sollten dann richtig liegen. Am besten beim ersten Anfordern der 14 Bytes mit einem anderen Speicherbereich für den Empfangspuffer arbeiten.

Ein Screenshot aus Wireshark sollte belegen, dass es in den am Datenlogger ausgehenden Daten keinen Offset gibt

Hast du da auch den Anfang seit Verbindungsaufbau mitgeloggt? Da sollten die unerwarteten 14 bytes drin sein.

 

[Rabi]

Kannst du ggf. die Wireshark-Dump mit uns teilen? Eventuell kann man daraus etwas erkennen.

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Problem bei TCP/IP ist das nan nicht weis wo ein Telegramm aufhört bzw. das nächste anfängt.

Daher gibt's da übliche verfahren:

a.) Daten im Ascii Format: Am Anfang ein Startzeichen und am Ende ein Endezeichen einfügen. Daten im Adhock-Modus empfangen und aneinanderreihen bis ein vollständiges Telegramm vorliegt...
b.) Daten im Binärformat: Einen Kopf mit fester Länge an den Anfang des Telegramms einfügen mit der Länge des folgenden Telegramms. Damit kannst du dann als erstes die länge des Kopfes empfangen, auswerten und das Datentelegramm mit der korrekten Länge Laden.

c.) UDP verwenden: Hat den Vorteil das immer ein vollständiges Telegramm an dein Programm übergeben wird und die Länge daher bekannt ist. Nachteil: Nur für "kurze" Telegramme bis etwa 1200 Byte. Die Übertragung ist nicht sichergestellt, das Telegramm kann verloren gehen, wenn ein Knoten (Switch,Router,...) ausgelastet ist. (Muss ggf. durch Software abgefangen werden, z.B. Zähler und Antwort auf ein Telegramm)

 

[HF_SPSler]

Kannst du ggf. die Wireshark-Dump mit uns teilen? Eventuell kann man daraus etwas erkennen.

Der Kollege hat mal ein C-Programm / Tool für Windows geschrieben um mit der SPS zu kommunizieren. Jetzt liegen uns zwei Dumps vor, der erste beinhaltet die Kommunikation zwischen PC Programm und SPS:

esponse with data in order:

0000 xx xx xx xx xx xx yy yy yy yy yy yy 08 00 45 00
0010 00 38 6f 89 40 00 80 06 00 00 c0 a8 01 73 c0 a8
0020 01 6e 07 d0 07 d0 3f c5 93 c7 a5 85 c9 9e 50 18
0030 fa 2a 84 5c 00 00 10 11 12 13 14 15 16 17 18 19
0040 1a 1b 1c 1d 1e 1f

Xx = DESTINATION MAC
Yy = SOURCE MAC

Frame 209: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface \Device\NPF_{E248155C-0376-490B-B5F4-55A9BEF021F2}, id 0
Interface id: 0 (\Device\NPF_{E248155C-0376-490B-B5F4-55A9BEF021F2})
Interface name: \Device\NPF_{E248155C-0376-490B-B5F4-55A9BEF021F2}
Interface description: Ethernet
Encapsulation type: Ethernet (1)
Arrival Time: Apr 1, 2025 11:10:20.910976000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1743498620.910976000 seconds
[Time delta from previous captured frame: 0.500730000 seconds]
[Time delta from previous displayed frame: 0.500730000 seconds]
[Time since reference or first frame: 20.824063000 seconds]
Frame Number: 209
Frame Length: 70 bytes (560 bits)
Capture Length: 70 bytes (560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]

Ethernet II, Src: WistronI_MACPEND (MACP), Dst: SiemensI_MACEND (MAC)
Destination: SiemensI_MACEND (MAC)
Address: SiemensI_ MACEND (MAC)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: WistronI_MACPEND (MACP)
Address: WistronI_ MACPEND (MACP)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)

Internet Protocol Version 4, Src: 192.168.1.115, Dst: 192.168.1.110
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 56
Identification: 0x6f89 (28553)
Flags: 0x40, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 128
Protocol: TCP (6)
Header Checksum: 0x0000 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.115
Destination Address: 192.168.1.110

Transmission Control Protocol, Src Port: 2000, Dst Port: 2000, Seq: 33, Ack: 1387, Len: 16
Source Port: 2000
Destination Port: 2000
[Stream index: 0]
[Conversation completeness: Incomplete (12)]
[TCP Segment Len: 16]
Sequence Number: 33 (relative sequence number)
Sequence Number (raw): 1069913031
[Next Sequence Number: 49 (relative sequence number)]
Acknowledgment Number: 1387 (relative ack number)
Acknowledgment number (raw): 2777008542
0101 .... = Header Length: 20 bytes (5)
Flags: 0x018 (PSH, ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 1... = Push: Set
.... .... .0.. = Reset: Not set
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
[TCP Flags: ·······AP···]
Window: 64042
[Calculated window size: 64042]
[Window size scaling factor: -1 (unknown)]
Checksum: 0x845c [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
[Timestamps]
[Time since first frame in this TCP stream: 20.824063000 seconds]
[Time since previous frame in this TCP stream: 0.576769000 seconds]
[SEQ/ACK analysis]


[Bytes in flight: 16]
[Bytes sent since last PSH flag: 16]
TCP payload (16 bytes)

Data (16 bytes)
Data: 101112131415161718191a1b1c1d1e1f
[Length: 16]

Und der zweite Dump beinhaltet die Kommunikation des Datenloggers mit der SPS:

Offset 14 data:

0000 xx xx xx xx xx xx yy yy yy yy yy yy 08 00 45 00
0010 00 38 00 27 40 00 80 06 76 67 c0 a8 01 73 c0 a8
0020 01 6e 07 d0 07 d0 72 d5 9f 78 3a ce 60 62 50 18
0030 08 00 ad ab 00 00 10 11 12 13 14 15 16 17 18 19
0040 1a 1b 1c 1d 1e 1f

Xx = DESTINATION MAC
Yy = SOURCE MAC

Frame 379: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface \Device\NPF_{E248155C-0376-490B-B5F4-55A9BEF021F2}, id 0
Interface id: 0 (\Device\NPF_{E248155C-0376-490B-B5F4-55A9BEF021F2})
Interface name: \Device\NPF_{E248155C-0376-490B-B5F4-55A9BEF021F2}
Interface description: Ethernet
Encapsulation type: Ethernet (1)
Arrival Time: Apr 1, 2025 11:46:41.571219000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1743500801.571219000 seconds
[Time delta from previous captured frame: 0.003418000 seconds]
[Time delta from previous displayed frame: 0.003418000 seconds]
[Time since reference or first frame: 31.308610000 seconds]
Frame Number: 379
Frame Length: 70 bytes (560 bits)
Capture Length: 70 bytes (560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp:data]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]

Ethernet II, Src: Wiznet_MACWEND (MACW), Dst: SiemensI_MACEND (MAC)
Destination: SiemensI_MACEND (MAC)
Address: SiemensI_ MACEND (MAC)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Wiznet_MACWEND (MACW)
Address: Wiznet_ MACWEND (MACW)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)

Internet Protocol Version 4, Src: 192.168.1.115, Dst: 192.168.1.110
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 56
Identification: 0x0027 (39)
Flags: 0x40, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 128
Protocol: TCP (6)
Header Checksum: 0x7667 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.115
Destination Address: 192.168.1.110

Transmission Control Protocol, Src Port: 2000, Dst Port: 2000, Seq: 497, Ack: 2113, Len: 16
Source Port: 2000
Destination Port: 2000
[Stream index: 0]
[Conversation completeness: Incomplete (12)]
[TCP Segment Len: 16]
Sequence Number: 497 (relative sequence number)
Sequence Number (raw): 1926602616
[Next Sequence Number: 513 (relative sequence number)]
Acknowledgment Number: 2113 (relative ack number)
Acknowledgment number (raw): 986603618
0101 .... = Header Length: 20 bytes (5)
Flags: 0x018 (PSH, ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 1... = Push: Set
.... .... .0.. = Reset: Not set
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
[TCP Flags: ·······AP···]
Window: 2048
[Calculated window size: 2048]
[Window size scaling factor: -1 (unknown)]
Checksum: 0xadab [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
[Timestamps]
[Time since first frame in this TCP stream: 31.308610000 seconds]
[Time since previous frame in this TCP stream: 0.003418000 seconds]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 378]
[The RTT to ACK the segment was: 0.003418000 seconds]
[Bytes in flight: 16]
[Bytes sent since last PSH flag: 16]
TCP payload (16 bytes)

Data (16 bytes)
Data: 101112131415161718191a1b1c1d1e1f
[Length: 16]

Diese beiden Aufzeichnungen scheinen auf den ersten Blick an den wichtigen Stellen erst mal identisch zu sein.

 

[Rabi]

Der Kollege hat mal ein C-Programm / Tool für Windows geschrieben um mit der SPS zu kommunizieren. Jetzt liegen uns zwei Dumps vor, der erste beinhaltet die Kommunikation zwischen PC Programm und SPS:



Und der zweite Dump beinhaltet die Kommunikation des Datenloggers mit der SPS:



Diese beiden Aufzeichnungen scheinen auf den ersten Blick an den wichtigen Stellen erst mal identisch zu sein.

Ist es eventuell möglich als eine Datei für Wireshark?