TIA TSend TRcv sehr langsam

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

Folgender Aufbau
1518F im Subnetz 1
315F mit cp343-1 Lean im Subnetz 1
1512F im Subnetz 2 (wird geroutet über Firmennetz)
Verbindung IsoOnTcp

Die 315 und die 1512 zählen im 100ms eine Variable hoch und senden diese an die 1518. Die 1518 schickt diese Variable direkt wieder zurück
EN_R am TRcv ist immer auf True
REQ am Send = UN DONE UN ERROR

Die gesendete Variablen zur 1518 kommen sehr schnell dort an. Die zurückgesendete Variable kommen aber in der 1512 und der 317 erst nach relativ langer Zeit zurück

Zum Bild 315 1518
Die Zeidifferenz zwischen senden aus der 315er bis zum Empfang in der 1518 gerade mal 0,4s
Die Differenz vom aktuell gesendeten zum aktuell empfangenen 3,8s
Die Differenz zum vorigen empfangenen Wert ist nur 0,2s.

Zum Bild 1512 1518
Die Zeidifferenz zwischen senden aus der 1512 bis zum Empfang in der 1518 gerade mal 0,1s
Die Differenz vom aktuell gesendeten zum aktuell empfangenen 6,0s
Die Differenz zum vorigen empfangenen Wert ist nur 0,5s.

Es scheint mir irgendwie so zu sein als ob der Empfangpuffer überfüllt wird
Ist das normal?

Ich habe mal Testweise am Send in der 1518 die PosFlanke 100ms vom Taktmerker zusätzlich an den REQ gelegt.
Dann läuft das ganze sauber

 

[Hadante]

Also die Zeiten kommen mir relativ hoch vor.

Ich habe vor einiger Zeit eine TCP Verbindung zu einem Labview System aufgebaut und dort haben wir beim Testen auch mal Taktraten von 50ms eingestellt. Bei etwa 200 Byte Daten.
Bzw PCS7 also S7 400 zu Labview habe ich im Produktiven Einsatz mit 100ms Intervall. Mit etwa 50 Byte.
Allerdings als TCP Verbindung nicht als ISOonTcp.

Das einfachste wird sein wenn du mal mit Wireshark drauf schaust wenn du dir sicher bist dass es nicht an deinem Code liegt, dazu wirst du zwischen zwei SPS etwas tricksen müssen. Entweder du hast einen Managed Switch bei welchem du eine Portreplikation machen kannst. Oder du musst dir eine Wireshark Box kaufen bzw. mit zwei USB Netzwerkkarten selber bauen.


Edit: Wer lesen kann ist klar im Vorteil.

REQ am Send = UN DONE UN ERROR

"un Done un Error" sagt der CPU bei jedem Fehler oder jedem Done Sende erneut, wenn ein Fehler bei TCP-IP auftritt bei der Übertragung wird das Paket so oder so neu gesendet.
Wenn du allerdings wirklich einen Fehler hast Versuchst du in sehr schneller Abfolge von der 1518 aus zu senden, damit wäre es sehr gut möglich das der Puffer der 317 oder 1512 vollgeschrieben wird.
z.B. 1518 Zykluszeit 0,5ms und CPU317 25ms, gut die TSend und TRcv laufen Asynchron, aber hängen indirekt was die Ansteuerung und das leeren des Puffers angeht wieder an der Zykluszeit.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Allerdings als TCP Verbindung nicht als ISOonTcp.

Ich würde eigentlich auch annehmen, dass ISOonTCP gegen das Vollaufen der internen Puffer schützen sollte, da hier schließlich jedes Telegramm auf Anwendungsebene bestätigt wird. Die Frage ist nur, ob die Siemens Bausteine bei ISOonTCP auch DONE erst dann setzen, wenn der Partner den Empfang des Telegramms wirklich bestätigt hat. Wenn das von Siemens nicht dokumentiert ist, hilft nur ausprobieren, wobei man sich dann auch nur sicher sein kann, dass es sich (vor allem bei der 1500er) zum aktuellen Firmwarestand so verhält.

Bei einer reinen TCP-Verbindung ist das nicht der Fall, hier kannst du bei einem Partner das Netzwerkkabel abziehen (möglichst so, dass keiner einen Link-Verlust mitbekommt) und die Siemens TSEND geben dir noch fröhlich bis zu 30 Sekunden lang ein DONE zurück, obwohl die Daten nur in den internen Puffer geschrieben wurde. Wenn bei einer eh schon grenzwertig ausgelasteten Verbindung so ein Zustand dazukommt, dann wird die Übertragung sehr unstetig, weil wenn sich nur ein Paket aufschiebt sich bei TCP durch die kontrollierte Reihenfolge alle folgenden auch verzögern, und währenddessen die alten abgearbeitet werden, wird der Puffer durch den festen Sendetakt noch weiter gefüllt.

Wenn eh ein beidesitiger Datenaustausch geschieht, wäre zu überlegen das Senden und Empfangen zu synchronisieren. Z.B. mit einem Telegrammzähler der von der Gegenstelle als Bestätigung wieder zurückgesendet wird, und erst bei Eintreffen der Bestätigung ein neues Telegramm abgeschickt wird.

 

[volker]

Ich hatte auch angenommen, dass tsend rcv das koordiniert. Aber dem scheint ja nicht zu sein. Schalte ich erst mal bei der 1518 das send ab. Puffer leer. Send Start. Innerhalb weniger Sekunden erhöht sich die antwortzeit auf die gewagten 6.5 sek. Ich sehe das so das die 1518 sofort den neuen send raushaut sobald ein done kommt. Vermutlich ein done bone einem früheren req. Mit der taktmerkerflanke von 100ms klappte ja. Vermutlich ginge auch ein schnellerer takt. Die zykluszeit der 1518 liegt zz bei ca 3.5ms. Die 1512 bei ca 25ms. Die 300 bei ca 15ms

 

[volker]

---

Wenn eh ein beidesitiger Datenaustausch geschieht, wäre zu überlegen das Senden und Empfangen zu synchronisieren. Z.B. mit einem Telegrammzähler der von der Gegenstelle als Bestätigung wieder zurückgesendet wird, und erst bei Eintreffen der Bestätigung ein neues Telegramm abgeschickt wird.

Darauf will ich auf jeden Fall verzichten. Möchte schon ein mehr oder weniger schnelkenzyklischen Datenaustausch.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Darauf will ich auf jeden Fall verzichten. Möchte schon ein mehr oder weniger schnelkenzyklischen Datenaustausch.

Ich würde vermuten, dass es mit einer Koordination wenn es passend programmiert wird nicht viel langsamer wird als du es jetzt hast. Evtl. sogar im Gegenteil, denn dann kannst du auf deine zusätzliche eingefügten Taktflanken verzichten und sendest eben koordiniert so schnell wie der Partner diese Daten verarbeiten kann. Das Verarbeiten der Sende- und Empfangsdaten geschieht in der SPS auch nicht parallel sondern sequentiell, und der Flaschenhals ist bei Einsatz einer Siemens-SPS meistens die SPS und nicht die Ethernet-Bandbreite.