Step 7 417H PN S7 Verbindungen

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Zusammen

Ich habe hier eine 417H PN/DP (6ES7417-5HT06-0AB0) CPU auf dieser sind doch mittlerweile recht viele Verbindungen mit gut Daten aufgesetzt. Soweit funktioniert auch alles. Was mich aber etwas stört ist die jetzt sehr zähe Kommunikation per PG. Ein Bausteinvergleich eines Bausteins unter 1kb geht schon einige Minuten bis ich was sehe.

Derzeit stehen pro Kopf 35 S7 Verbindungen (alle etwa 1kb Daten) plus 10 OP Verbindungen.

Denkt ihr man man könnte eine Schnellere Verbindung wählen? Ich nutze hier wie üblich BSEND/BRECV SFB12/13 und lasse die alle nebeneinander laufen. Will heissen wenn done kommt stosse ich einen neuen Auftrag an.

Alle Verbindungen laufen über die PN Schnittstelle.

mfG René

 

[ducati]

Da die 400er ja nen schnellen Rueckwandbus hat, könnte man die Kommunikation auf nen Cp auslagern. Sollte die Cpu schon entlasten... Ueber welche Schnittstelle gehst Du denn mit dem PG online?

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das hiesse ja pro Anlage zwei CPs zusätzlich. Naja das wärs mir nun nicht wert. Dachte halt man könnte die übertragung vielleicht der PG Kommunikation Prioritäten einräumen. Es wäre nicht so schlimm wenn die Anlagenkommunikation dann etwas langsamer werden würde. Aber die Kommunikation PG <-> CPU und CPU <-> PVSS OA sollte halt etwas schneller werden.

Aber ich hab echt keine Idee wie ich das bewerkstelligen soll.

mfG René

 

[ducati]

Nun ja, worüber bist Du mit dem PG auf der SPS? Ethernet oder MPI/Profibus?

Wenn Du die Daten über BSEND nicht so häufig brauchst, kannst Du die halt seltener aufrufen... alle 5 Sekunden / 10 Sekunden?

Hast Du in den BSEND DBs viele Reserven? Da kannnst Du u.U. was rausschmeissen...

In den CPU Einstellungen "Zyklusbelastung durch Kommunikation" erhöhen... dadurch steigt dann aber sicherlich die Zykluszeit

mehr fällt mir jetzt auf die Schnelle auch nicht ein.

Gruß.

 

[ducati]

Was läuft denn da noch so auf dem Netzwerk?

Evtl. ist das Netzwerk ausgelastet? Ist nen Switch für alle 35 Teilnehmer verbaut oder ist das nen LWL-Ring?

Gruß.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo René,

mit so vielen Verbindungen mit so vielen Daten hatte ich noch nicht zu tun. Doch mein Gefühl sagt mir, Du könntest die Situation verbessern wenn Du statt S7-Protokoll (BSEND/BRECV) auf ISO-on-TCP-Protokoll (TCON/TSEND/TRCV) wechselst und nicht schneller sendest als Du zur Zeit mit BSEND schaffst. Dann sollte noch genug Luft für eingestreute PG-Kommunikation sein.

Reicht es, wenn Du nur alle 200ms ... 500ms sendest? Ich vermute, schneller bist Du jetzt auch nicht.

Das (testweise) Umstellen so vieler Verbindungen ist natürlich ein dicker Batzen Programmierarbeit. Frage mal den Siemens Support bzw. Fachberatung, ob ISO-on-TCP tatsächlich besser ist.

Hier kann man ein paar typische Kommunikations-Leistungsdaten abrufen, doch auf Deine Frage sehe ich da leider keine Antwort:
Ermittlung der Übertragungszeit für typische Konfigurationen am Industrial Ethernet

Harald

 

[vollmi]

Reicht es, wenn Du nur alle 200ms ... 500ms sendest? Ich vermute, schneller bist Du jetzt auch nicht.

Je schneller je besser. Aber jetzt bin ich auch schon auf 100ms unten im Durchschnitt.

Das (testweise) Umstellen so vieler Verbindungen ist natürlich ein dicker Batzen Programmierarbeit. Frage mal den Siemens Support bzw. Fachberatung, ob ISO-on-TCP tatsächlich besser ist.

Jep das ist recht massiv. Was mich halt damals zur S7 Verbindung gebracht hat war die Einfachheit. ISn_TCP gibts halt nur Open. Und die komplette Konfiguration im Programm hat mich etwas abgeschreckt.

Wird wohl über Support laufen müssen. Oder ich bau mal n Test auf.
Muss mir mal n zweites 400er Testsystem zulegen für solche Versuche. Ne 300er als Ziel ist da leider sofort am Ende.

Ich hab mir auch schon I-Device überlegt. Aber das hab ich noch nie probiert. Und die 400H scheint das eh nicht zu können.

mfG René

 

[PN/DP]

I-Device geht nicht wegen Deiner exorbitanten Datenmengen (35kB). Deine CPU kann PN-dezentral "nur" 8kB Eingänge und 8kB Ausgänge.
Wofür muß man eigentlich hoch-zyklisch 1kB Daten austauschen?
Müssen alle Daten so häufig aktualisiert werden?

Harald

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

I-Device geht nicht wegen Deiner exorbitanten Datenmengen (35kB). Deine CPU kann PN-dezentral "nur" 8kB Eingänge und 8kB Ausgänge.
Wofür muß man eigentlich hoch-zyklisch 1kB Daten austauschen?
Müssen alle Daten so häufig aktualisiert werden?

Müssen sie nicht. Die meisten Daten kommen z.B. von AumaKlappenantrieben. Die werden von 10 315ern gesammelt und dann an die 400er übertragen.
Es ist nur im Handbetrieb recht schnell nervig wenn man eine Gruppe Klappen in der 400 z.B. auf Manuellbetrieb stellt und eine Stellung auswählt und bis dass dann zur 300er geht und die Rückmeldung der Stellung dann im 5 Sekunden takt dann zurückgemeldet wird. Ist das extrem lahmarschig. Das spielt für die echte Funktion überhaupt keine Rolle. Die 400er erwartet einfach nach 40 Sekunden die Rückmeldung der Stellung die angefordert wurde. Aber für den Bediener am Scada ist es halt mühsam wenn die einzelnen CPUs ihre Aktionen erst Sekunden nach Auswahl zurückmelden würden.

Edit: 1kb ist der maximalausbau. Die meisten CPUs bewegen sich zwischen 200 und 400 kb.

Ist halt noch n extrem altmodisches Konzept mit 20 315er CPUs an einer 400er wobei die 300er nur als reine Datenkonzetratoren dienen. Die sind ansich völlig dumm und langweilen sich. Ich würde sowas am liebsten alles direkt als RemoteIOs per PN auf die 400er ziehen, die Aumas halt als PB ring.
Die 400H steht übrigens komplett als einheit in einem Schaltschrank. sie sind nur unterschiedlich Eingespeist. Soviel zur sooo wichtigen Redundanz wo der Betreiber so drauf besteht, aber unbedingt vorschreibt wo der Hauptrechner zu verbauen ist. Nur das so als Hintergrundinfo

mfG René

 

[Thomas_v2.1]

Eine Iso-On-TCP Verbindung ist übrigens nicht vergleichbar mit einer S7-Verbindung.
Bei einer S7-Verbindung wird die erfolgreiche Datenübertragung auf Anwendungsebene bestätigt, d.h. der Partner weiß definitiv, dass die Daten im Speicher der Partner-SPS angekommen sind. Das ist bei einer TCP oder Iso-On-TCP Verbindung nicht der Fall. Ich ignoriere mittlerweile aber die vielen Posts wo die S7-Verbindung verteufelt wird, weil dort ganz einfach Äpfel mit Birnen verglichen werden. Ein Einschreiben mit Rückschein ist nicht mit einer Postkarte zu vergleichen.

Deine BSEND/BRECV Kopplung könntest du anhand der Blockgrößen noch optimieren, wenn du nicht alle deiner 1024 Bytes benötigst, sondern es z.B. auch 892 Bytes tuen würden. Die PDU-Größen sind bei einer S7-400 üblicherweise 480 Bytes, zumindest bei den 400er-CPs ist diese Größe im Handbuch auch dokumentiert. Pro Telegramm auf dem Bus hast du für deine Nettodaten noch 446 Bytes übrig. D.h. bei deinen 1024 Bytes erzeugst du 3 Telegramme inkl. 3x Quittung, bei 892 nur noch 2.

Bei Iso-On-TCP ist bei einem 400er CP die Blockgröße auf 400 Bytes festgelegt, die Segmentierung erledigt der CP automatisch. Nur hier entfallen die Quittungstelegramme auf Anwendungsebene, es gibt nur eine Quittung auf Transportebene (ebenfalls pro Telegramm).

 

[Thomas_v2.1]

Achso, wenn du von der S7-400 mit einer S7-300 kommuniziert, dann ist die Blockgröße nur noch 240 Bytes weil die 300er die 400er "runterzieht".
D.h. Netto bleiben dir bei BSEND/BRECV noch 208 Bytes pro Telegramm.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch wenn du deine Datenübertragung auf ein "schlankeres" Protokoll umstellst, aber weiterhin mit maximaler Senderate kommunizierst (d.h. immer sofort wenn ein Aufruf beendet ist einen neuen anstoßen), wird sich an der Auslastung nichts großartiges ändern. Dann ist der Sendeaufruf zwar schneller fertig, aber es wird auch schneller ein neuer angestoßen. Unter Umständen ist die Auslastung dadurch später noch größer als vorher, weil z.B. die Wartezeit auf das Quittungstelegramm entfällt.

Reserven schaffen kannst du nur wenn die die Senderate verlangsamst und ggf. die Datenübertragung optimierst.

 

[vollmi]

Eine Iso-On-TCP Verbindung ist übrigens nicht vergleichbar mit einer S7-Verbindung.
Bei einer S7-Verbindung wird die erfolgreiche Datenübertragung auf Anwendungsebene bestätigt, d.h. der Partner weiß definitiv, dass die Daten im Speicher der Partner-SPS angekommen sind.

Das könnte ich ja mit ner Quersumme noch selber überprüfen. Mit den Daten die zurückkommen.

Deine BSEND/BRECV Kopplung könntest du anhand der Blockgrößen noch optimieren, wenn du nicht alle deiner 1024 Bytes benötigst, sondern es z.B. auch 892 Bytes tuen würden. Die PDU-Größen sind bei einer S7-400 üblicherweise 480 Bytes, zumindest bei den 400er-CPs ist diese Größe im Handbuch auch dokumentiert. Pro Telegramm auf dem Bus hast du für deine Nettodaten noch 446 Bytes übrig. D.h. bei deinen 1024 Bytes erzeugst du 3 Telegramme inkl. 3x Quittung, bei 892 nur noch 2.

Das wäre ja schon möglich wenn ich die Daten zusammenstreiche. Allerdings müsste ich ja die Kommunikation dann wirklich irgendwie alternieren. Wenn ich die Daten weniger werden, wird einfach öfter kommuniziert und die Last würde ja dieselbe Bleiben. Wenn ich den Zyklus selbst definiere also 200ms pro Sendebefehl. dann werden halt 70 Sendeaufträge alle 200ms angestossen. das wird ja dann auch nicht viel ausmachen. Oder ich machs alternierend also jeder Sendeautrag wird durch Done/error vom Sendeauftrag der Station davor ausgelöst. Macht die ganze Sache aber aufwändig und dann erst richtig langsam.

mfG René

 

[ducati]

Das wäre ja schon möglich wenn ich die Daten zusammenstreiche. Allerdings müsste ich ja die Kommunikation dann wirklich irgendwie alternieren.

Ich denke, Thomas und auch ich meinten, eventuelle Reserven aus den Kommunikations-DBs zu entfernen...

Gruß

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Doch mein Gefühl sagt mir, Du könntest die Situation verbessern wenn Du statt S7-Protokoll (BSEND/BRECV) auf ISO-on-TCP-Protokoll (TCON/TSEND/TRCV) wechselst und nicht schneller sendest als Du zur Zeit mit BSEND schaffst. Dann sollte noch genug Luft für eingestreute PG-Kommunikation sein.

Hier kann man ein paar typische Kommunikations-Leistungsdaten abrufen, doch auf Deine Frage sehe ich da leider keine Antwort:
Ermittlung der Übertragungszeit für typische Konfigurationen am Industrial Ethernet

Harald

So große unterschiede gibt es zwischen BSEND/TESEND auch nicht, vor allem nicht in der TransTime_max

 

[vollmi]

Ich hab jetzt mal die BSEND/BRECV mit einer Individuellen Wartezeit beaufschlagt. Ich warte jetzt nach jeder Quittierung (done/error) 20ms bevor neu angestossen wird. Nur schon die AGLink kommunikation vom PVSS läuft spürbar schneller.

Und das obwohl ich völlig unkordiniert Kommuniziere, also die einzelnen Linien nicht staffle.

mfG René