Step 7 Cp343-1

Lipperlandstern

Lipperlandstern

Level-3
Beiträge
6.008
Reaktionspunkte
1.727
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab da mal wieder eine Frage an die Kommunikationsexperten.

Ich habe eine CP343-1. Dieser soll über den FC5/FC6 Datenblöcke von 2048 Byte senden bzw. empfangen. Das Senden funktioniert ohne Fehlermeldung des Bausteines bzw. der Baustein meldet DONE.

Jetzt behauptet der Empfänger das nur 2045 Byte ankommen. Ich kann das auf die schnelle nicht kontrollieren. Der CP343-1 ist in Belgien , der Empfänger in Österreich.

Wenn ich das nächste Mal vor Ort bin werde ich mal meinen Laptop direkt an den CP hängen und mal schauen was da rauskommt.


Aber würde es eine Erklärung für das "verschwinden" von 3 Bytes geben ? Wird an jeder Grenze ein Byte abgezogen ?


Der Empfang von 2048 Byte klappt übrigens problemlos.
 
Am AG_SEND: Ist der ANY-Pointer an SEND zu kurz? Ist an LEN tatsächlich 2048 angegeben?
Woher weiß der Empfänger, daß es nur 2045 Byte sind? Verschiebt sich die Nachricht im Empfangspuffer oder meldet AG_RECV LEN=2045? Hat der überhaupt einen CP oder was ist das für ein Empfänger? Was für eine Verbindung ist das, TCP-, ISO-on-TCP-, ...?
Ist/sind das halbwegs aktuelle CP343-1?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Am AG_SEND: Ist der ANY-Pointer an SEND zu kurz? Ist an LEN tatsächlich 2048 angegeben?
Woher weiß der Empfänger, daß es nur 2045 Byte sind? Verschiebt sich die Nachricht im Empfangspuffer oder meldet AG_RECV LEN=2045? Hat der überhaupt einen CP oder was ist das für ein Empfänger? Was für eine Verbindung ist das, TCP-, ISO-on-TCP-, ...?
Ist/sind das halbwegs aktuelle CP343-1?

Harald
Zum Vergrößern anklicken....


Any-Pointer und LEN sind 2048. Das habe ich zig Mal kontrolliert. Der Empfänger ist ein Datenbank. Also vermutlich irgendein PC. Auf die Länge sind sie mit Wireshark gekommen.

Verbindung ist TCP und der CP ist neu.
 
Bei TCP ist es nicht gesagt, dass die 2048 Bytes auch am Stück gelesen werden können. Wenn ihr eine feste Byteanzahl ausgemacht hat, muss er solange lesen bis er die Anzahl empfangen hat, und dann die Daten selber richtig hintereinander zusammensetzen. Das ist das "Problem" was bei TCP meistens überhaupt nicht beachtet wird, darum macht Iso-On-TCP so eine Kommunikation wesentlich einfacher.
 
nein. verschwinden dürften die 3 bytes natürlich nicht. eigentlich sorgt das tcp-protokoll dafür das alle daten ankommen.
https://de.wikipedia.org/wiki/Transmission_Control_Protocol schrieb:
Beispiel einer TCP-/IP-Datenübertragung

Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Byte an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3, weil es verlorengegangen ist, so kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, sofern beide Seiten die TCP-Option SACK (Selective ACK) unterstützen. Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer.
Zum Vergrößern anklicken....
https://de.wikipedia.org/wiki/Datei:Tcp_transfer.png
 
Wobei sich gerade bei einer VPN-Strecke (was ich hier mal vermute) die MTU unterwegs noch ändern kann, was dann zu einer Fragmentierung der Pakete führt.

Beim AG_SEND für einen Ethernet-CP sagen dir die Statusausgänge der Funktion übrigens nicht, dass die Daten beim Empfänger angekommen sind, sondern nur dass die Daten zum Senden an den CP erfolgreich übergeben wurden. Ich hatte das bei einem CP für die 400er mal getestet: selbst wenn ich meinen eigenen Server nachdem schon mal Daten ausgetauscht wurden beendet habe, hat AG_SEND das Senden erfolgreich bestätigt. Im Hintergrund versucht der CP entsprechend nach Ablauf von Timeouts die Daten doch noch loszuwerden. Wenn das nach einer Anzahl Versuche (Retry-Limit, üblicherweise 3) nicht klappt, dann wird intern die Verbindung als abgebaut gekennzeichnet und versucht diese neu aufzubauen. Wenn du bei einem Ethernet-CP die Verbindung nur alle paar Minuten benutzt und nur sendest, dann bekommst du davon im SPS-Programm nichts mit. Du musst die dann die Spezialdiagnose des CPs ansehen, dort gibt es Zähler für erfolgreich/fehlerhaft gesendete Daten und einen eigenen Diagnosepuffer.

Ich würde aber wenn möglich erstmal selber mit einer lokalen eigenen Anwendung als TCP-Server, ob dort wenigstens definitiv die gesendete Anzahl ankommt. Das mit den 3 Bytes ist schon seltsam.
 
Thomas_v2.1 schrieb:
Wobei sich gerade bei einer VPN-Strecke (was ich hier mal vermute) die MTU unterwegs noch ändern kann, was dann zu einer Fragmentierung der Pakete führt.

Beim AG_SEND für einen Ethernet-CP sagen dir die Statusausgänge der Funktion übrigens nicht, dass die Daten beim Empfänger angekommen sind, sondern nur dass die Daten zum Senden an den CP erfolgreich übergeben wurden. Ich hatte das bei einem CP für die 400er mal getestet: selbst wenn ich meinen eigenen Server nachdem schon mal Daten ausgetauscht wurden beendet habe, hat AG_SEND das Senden erfolgreich bestätigt. Im Hintergrund versucht der CP entsprechend nach Ablauf von Timeouts die Daten doch noch loszuwerden. Wenn das nach einer Anzahl Versuche (Retry-Limit, üblicherweise 3) nicht klappt, dann wird intern die Verbindung als abgebaut gekennzeichnet und versucht diese neu aufzubauen. Wenn du bei einem Ethernet-CP die Verbindung nur alle paar Minuten benutzt und nur sendest, dann bekommst du davon im SPS-Programm nichts mit. Du musst die dann die Spezialdiagnose des CPs ansehen, dort gibt es Zähler für erfolgreich/fehlerhaft gesendete Daten und einen eigenen Diagnosepuffer.

Ich würde aber wenn möglich erstmal selber mit einer lokalen eigenen Anwendung als TCP-Server, ob dort wenigstens definitiv die gesendete Anzahl ankommt. Das mit den 3 Bytes ist schon seltsam.
Zum Vergrößern anklicken....

Bei den ersten Sende- und Empfangstest habe ich immer die Spezialdiagnose offen. Ich habe aber noch nie den Fall gehabt das das DONE-Bit gesetzt wurde und der Zähler sich nicht erhöht hatte.
 

Similar threads

R
TIA CP343 Lean Kommunikation
2
Antworten
20
Aufrufe
3K
PN/DP
PN/DP
Betriebselektriker28
Step 7 Ethernet Kommunikation Keyence Kamerasystem mit S7-400
Antworten
13
Aufrufe
1K
Betriebselektriker28
Betriebselektriker28
V
TIA Ag_Send/Recv Daten nicht korrekt übertragen
Antworten
3
Aufrufe
781
Vex
V
M
TIA LHTTP Bausteine mit nicht unterstützten Datentypen
Antworten
10
Aufrufe
714
MaNuE
M
M
TIA S7-1500 Modbus TCP Verbindung mit Fremdgerät
2
Antworten
21
Aufrufe
5K
MaNuE
M
Zurück
Oben