Step 7 Zeitverzögerung mit TCP-Verbindung (AG SEND/RECV)

riklin

Level-1
Beiträge
24
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Ich habe ein sehr ärgerliches Problem mit der Datenübertragung mit AG_SEND / AG_RECV über eine TCP-Verbindung zwischen zwei Steuerungen.
Die Anlagen laufen schon seit vielen Jahren - vermutlich gab es das Problem schon immer, wurde aber früher nicht bemerkt.

Step7 V5.5 SP1
CPU: 416-3 DP
CP: 443-1 LEAN
Verbindung: unspezifische TCP-Verbindung. Eine CPU mit aktivem Verbindungsaufbau.
Aufruf: Kommunikationsaufruf AG_SEND und AG_RECV aus dem OB1 heraus. RECV wird immer aufgerufen, jedoch bei Error 0x8183 und 0x8304 übersprungen. AG_SEND wird angestossen (ACT), wenn die Verbindung nicht unterbrochen ist und kein Auftrag läuft (BUSY). Soweit alles klar, damit kenne ich mich aus.
Die beiden Steuerungen tauschen ein paar Werte aus (8 Byte in eine Richtung, 24 Byte in die andere Richtung). Die Werte werden in einen DB kopiert und dann rübergeschickt, also wirklich nichts Besonderes.

Beide Steuerungen hängen im gleichen Netz. Darin befinden sich auch einige WinCC flex. Bedienstationen (PC Runtime), sowie weitere S7-Steuerungen (Ebenfalls mit TCP-Kommunikation). In beiden Schaltschränken ist ein Siemens Switch, von dort führt die Verbindung jeweils zu einem Switch im Netzwerkkasten des Kunden. Diese beiden Swtich sind miteinander verbunden.

Nun zum Problem: In die eine Richtung werden die Werte umgehend übermittelt. In die andere Richtung dauert es bis zu 30 Sekunden (!!!) bis die Werte ankommen.
Setze ich ein Bit für 10 Sekunden auf 1, so sehe ich dies 30 Skeunden später auf der anderen Steuererung.
Ein Ping Test über das Netz führt innert Millisekunden zu einer Antwort.

Ich habe zwei 400er Steuerungen bei mir aufgebaut (natürlich ohne den Rest) und lasse das gleiche Programm laufen. Hier flutscht die Kommunikation reibungslos in beide Richtungen. Darum vermute ich, es liegt am Netzwerk oder an der Hardware oder...?

Hat jemand von euch schom mal etwas Änhliches erlebt oder hat eine Idee, wie ich der Ursache auf die Spur kommen kann?

Besten Dank für eure Ratschläge im Voraus.

Andreas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Andreas,

dieses Problem hatte ich auch an einer meiner Anlagen.

Das Problem ist relativ Simpel. Die eine SPS schickt die Daten schneller weg als die andere SPS die Daten verarbeiten kann.
Dadurch entsteht im Empfangspuffer der 2. SPS ein Stau.
Wenn du die Verbindung kurz unterbrichst werden deine Daten wieder relativ schnell ankommen.


Geholfen habe ich mir damit das die eine SPS wartet bis die andere SPS die Daten quittiert hat. Senden und warten auf Quittierung dauert bei mir ca. 8ms (2x Vipa 315).
Alternativ kannst du den Sendeauftrag auch mit einen Timer verzögern.


Stefan
 
Sind die Send- und Recv Bausteine aus der 400er Bibliothek genommen worden?

wären dann:

FC50, FC53, FC60, FC63 bei 400er

FC5, FC6 bei 300er
 
Kommt tatsächlich das Telegramm 30s später erst an oder prüft der Empfänger die Struktur des Telegramms und verwirft viele empfangene Telegramme?

Wartet der Empfänger auf mehr Zeichen als das Telegramm lang ist? Ist die Zugriffsbreite des ANY an RECV exakt so groß wie die erwartete Telegrammlänge?

Harald
 
Kommt tatsächlich das Telegramm 30s später erst an oder prüft der Empfänger die Struktur des Telegramms und verwirft viele empfangene Telegramme?

Wartet der Empfänger auf mehr Zeichen als das Telegramm lang ist? Ist die Zugriffsbreite des ANY an RECV exakt so groß wie die erwartete Telegrammlänge?

Harald

Hallo Harald

Ich glaube, das kommt wirklich so verspätet an. Anhand dem Status der Bausteine sehe ich nicht, dass beim Empfangen etwas verworfen wird. Die Datanlänge des ANY ist richtig.

Ich werde mal Stefans Aussage testen und den Speed etwas drosseln, bzw. über Quitierbits synchronisieren. Kann da aber erst im Oktober wieder ran.

Danke schon mal für eure Tipps!
 
Das habe ich auch bei einer Anlage, die ich leider mit einer reinen TCP-Verbindung gemacht habe. Suche mal bei Siemens, da gibt es einen FAQ zu diesem Thema. So wie ich noch mich erinnere, ist das
eine negative Spezialität einer reinen TCP-Verbindung. Daher nehme ich nur noch ISO-on-TCP, oder noch besser S7-Verbindungen.
 
Hallo Bitverbieger

Das klingt sehr interessant! Leider kann ich auf der Supportseite mit dieser FAQ ID nichts finden. Hast du mir einen Link?

Andreas
 
Siemens faq ID: 1366499
Ich vermute, dieser Beitrag ist gemeint:
Welche Eigenschaften, Vorteile und Besonderheiten bietet das TCP-Protokoll?
Wenn Daten mit dem TCP-Protokoll übertragen werden, erfolgt die Übertragung in Form eines Datenstroms. Es werden dabei weder Informationen zur Länge noch Informationen über Anfang und Ende einer Nachricht übertragen. Der Empfänger kann jedoch nicht erkennen, wo eine Nachricht im Datenstrom endet und wo die nächste im Datenstrom beginnt. Deshalb muss der Sender eine Nachrichtenstruktur festlegen, die beim Empfänger interpretiert werden kann. Die Nachrichtenstruktur kann sich z.B. aus den Daten und einem abschließenden Steuerzeichen wie "carriage return", über welches das Ende einer Nachricht signalisiert wird, zusammensetzen.

Siehe auch FAQ: Linkliste SIMATIC-Kommunikation über Ethernet, Abschnitt "Vergleich Protokolle"

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein es ist nicht der Beitrag 1366499. Ich habe den Beitag mal als Anhang angefügt. Vieleicht hilft es bei dem Problem
 

Anhänge

  • Warum kommt es bei TCP-Verbindungen unter bestimmten Umständen zu sehr langen.pdf
    102 KB · Aufrufe: 42
Hatte das Problem schon mal und bei mir lag es auch daran, dass die Sendeaufträge zu schnell nacheinander angestoßen wurden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Ich war nun endlich wieder auf den Anlage und konnte das Problem beheben!

Tatsächlich gibt es bei TCP/IP zu einem Stau bem Empfänger kommen, wenn die Sendeaufträge zu schnell hintereinander erfolgen. Ich habe nun den Sendeauftrag mit einem Taktmerker verknüpft. Will heissen, ein Sendeauftrag wird nur dann ausgelöst (ACT), wenn AG-SEND ein DONE meldet, keinen ERROR hat und der Taktmerker (1Hz) auf TRUE ist.
Nun dauert die Datenübertragung <1s statt bisher 30s.

Ich danke euch allen für eure Beiträge
Andreas
 
Zurück
Oben