Geschwindigkeiten ISO-on-TCP und S7-Kommunikation

Küffel

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

hat jemand ne Liste / Informationen darüber wie schnell die Datenübertragung mit den einzelnen FBs ablaufen kann und wie groß die Datenpakete jeweils sind? Vor allem die "gesicherten" Verbindungen wie ISO-on-TCP mit AG_LSEND und S7-Kommunikation mit BSEND sind für mich von Interesse. Also welche ist "schneller"?

Am Rande wären auch die Geschwindigkeiten von PUT/GET usw von Interesse, aber nicht so dringend.

Derzeit benutze ich AG_LSEND, aber ich will ggf. auf BSEND umstellen, da man diese Verbindungen ja online nachladen kann ohne das die CPU in den Stopp geht. (Den Befehl TSEND kann ich leider nicht nutzen, da ich den CP443-1 ..EX11.. und nicht ..EX40.. habe)

Gruß,
Der Kuffel
 
Hallo!

Mit S7-400 kann ich Dir keine Erfahrungswerte geben, aber für S7-300 + CP343-1 und CPU317-2PN/DP gibts bei mir Erfahrungswerte.

Iso_on_TCP
Generell eindeutig ist die Iso_on_TCP-Verbindung der S7-Verbindung vorzuziehen (Hotline sagt gleiches) - sind also CPs vorhanden, sollte unbedingt Iso_on_TCP verwendet werden.
Bis zu einer Datenmenge von 240 Byte ist die Verbindung sehr schnell - abhängig von SPS-Zykluszeit und Netzkomponenten. (Ich hab einige Anlagen laufen, 2 x 317-2DP + CP343, 2 Standard-Switches dazwischen --> Laufzeit ca. 50ms)
Werden pro Verbindung mehr als 240 Byte übertragen, muss bei S7-400 der Baustein AG_LSEND verwendet werden, die Performance sinkt dann rapide --> ca. 4 sek für 4000 Byte
Eine Lösung wäre hier die Projektierung von merhreren parallelen Verbindungen, über die jeweils 240 Byte geschickt werden.

S7-Verbindung
Diese sind auch mit den PN/DP-Steuerungen möglich. Ich habe derzeit bei mir auf dem Schreibtisch einen Versuchsaufbau mit 2 x 317-2PN/DP. Zwischen diesen Steuerungen laufen mittlerweile 5 Kommunikationsverbindungen:
- S7-Verbindung: PUT/GET
- S7-Verbindung: USEND/URECV
- S7-Verbindung: BSEND/BRECV
- CBA-Verbindung
- Profinet-IO Master-Slave (in Station 2 ist ein CP343-1Lean als Slave verbaut)

Ich schicke jeweils 212 Byte (PNIO 240 Byte) Daten hin-und her, lasse ein Lebensbit im Kreis laufen dessen Laufzeit und die Anzahl verlorener Pakete ich messe. (CPU-Zykluszeit á 1 ms) Als Switch kommt ein Scalance X208 zum Einsatz.
- PUT/GET: 150ms
- BSEND/BRECV: 200ms
- USEND/URECV: 80ms
- CBA: 900ms
- PNIO: 30ms

Mit einem Standard-Switch sind die Resultate etwas schwächer, vor allem gehen bei USEND/URECV vereinzelt und bei BSEND/BRECV häufig Pakete verloren.

Fazit:
1. Wahl: Iso-on-TCP
2. Wahl: PUT/GET

Bei der Einfachheit der Programmierung sticht natürlich PUT/GET heraus - bei alle anderen Varianten ist gezielt ein Handshake zu programmieren.


mfg
Maxl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielen Dank für deine Antwort.

Komisch, mit hat man an der Hotline die S7-Kommunikation förmlich aufgedrängt Kommt aber vielleicht auch durch meine Problematik, dass ich eine Möglichkeit suche Verbindungen zur Laufzeit, d.h. ohne Stopp der SPS nachzuprojektieren, und das geht (mit meiner Hardware) nur mit S7-Kommunikation.

PUT/GET ist soviel ich weiß von der Sicherheit recht einfach, oder? Bei ISO-on-TCP wird ja mittels RFC 1006 kontrolliert, ob auch alles richtig angekommen ist und laut Hotline macht bei S7-Komm. das ja nur BSEND/BRECV. Oder bin ich da falsch informiert?

Wie hast du denn die Zeiten und den Datenverlust gemessen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Komisch, mit hat man an der Hotline die S7-Kommunikation förmlich aufgedrängt Kommt aber vielleicht auch durch meine Problematik, dass ich eine Möglichkeit suche Verbindungen zur Laufzeit, d.h. ohne Stopp der SPS nachzuprojektieren, und das geht (mit meiner Hardware) nur mit S7-Kommunikation.
CPU-Stop war bei nie ein Problem - daher kann ich dazu nichts sagen.

PUT/GET ist soviel ich weiß von der Sicherheit recht einfach, oder? Bei ISO-on-TCP wird ja mittels RFC 1006 kontrolliert, ob auch alles richtig angekommen ist und laut Hotline macht bei S7-Komm. das ja nur BSEND/BRECV. Oder bin ich da falsch informiert?
Wie das intern alles funktioniert, kann ich Dir auch nicht sicher beantworten.

Wie hast du denn die Zeiten und den Datenverlust gemessen?
Über einen Umweg (am Beispiel BSEND/BRECV)


1. Schritt: 1 Station als "Master" definieren, 1 als "Slave"

2. Schritt: Am Slave die Kommunikation programmieren:
- BRECV: Aufruf zyklisch
- mit Ausgangssignal "NDR" von BRECV wird BSEND am Slave gestartet (nur 1 mal)
--> Folge: Slave schickt nur dann Daten zum Master, wenn zuvor vom Master ein Paket empfangen wurde

3. Schritt: Kommunikation am Master programmieren
- BRECV: Aufruf Zyklisch
- mit Ausgangssignal "NDR" von BRECV wird BSEND gestartet (nur 1 mal)

4. Schritt: Anstoss der Kommunikation vom Master
- wird das Ausgangssignal NDR von BRECV am Master länger als z.B. 5 sek nicht 1, wird BSEND angestoßen.

--> Jeder Teilnehmer schickt nun nur Daten zum anderen, wenn zuvor ein Paket von diesem empfangen wurde. Das System muss (theoretisch) nur 1 mal angestoßen werden.

Wird das Timeout von Pkt. 4 lang genug gewählt, kann gemessen werden, wie lange es vom BSEND-Anstoß bis zum Empfang eines Pakets dauert (z.B. 150 ms). Kommt länger als 500 ms kein Paket vom Slave zurück, kann davon ausgegangen werden, dass das Paket verloren ging, der Bsend-Auftrag wird vom Master erneut angestoßen.

Um das ganze auf Längere Zeit nachvollziehbarer zu machen, habe ich Zähler eingebaut, wie oft BSEND abgesetzt wurde, und wie oft ein Paket zurückgekommen ist. Die Differenz interpretiere ich als verlorene Pakete.


Ich hoffe das ist jetzt nicht zu kompliziert sondern nachvollziehbar.

mfg
Maxl
 
Ne, klingt echt logisch und durchdacht. Haste dann als "Pakete" Daten mit unterschiedlichen Längern verwendet? (z.B. 10Byte, 100Byte, 240Byte, 500Byte, etc) Oder wie?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ne, klingt echt logisch und durchdacht. Haste dann als "Pakete" Daten mit unterschiedlichen Längern verwendet? (z.B. 10Byte, 100Byte, 240Byte, 500Byte, etc) Oder wie?
Hab am Anfang bei PUT/GET und bei USEND/URECV mit Paketgröße 16 Byte gearbeitet, dann auf die größeren Blöcke umgestellt. Bei der Laufzeit konnte keinen Unterschied messen.
 
Mit einem Standard-Switch sind die Resultate etwas schwächer, vor allem gehen bei USEND/URECV vereinzelt und bei BSEND/BRECV häufig Pakete verloren.

Ist diese Erfahrung allgemein gültig oder von der Qualität des Switches abhängig (hast du auch unterschiedliche Standard-Switche getestet)? Der Scalance X208 ist ja nicht so wirklich günstig!
 
Ist diese Erfahrung allgemein gültig oder von der Qualität des Switches abhängig (hast du auch unterschiedliche Standard-Switche getestet)? Der Scalance X208 ist ja nicht so wirklich günstig!
Ich habe bisher 3 Konfigurationen ausprobiert.
- 1. CPU - Scalance X208 - CPU
- 2. CPU - Surecom 30€-Switch - Scalance X208 - CPU
- 3. CPU - Surecom 30€-Switch - Firmennetz (3 manged switches) - CPU

Weitere Versuche laufen! Mein Ziel ist derzeit, bis Mitte Jänner ein Konzept zu haben, welches ich auf Anlagen einsetzen kann. Hier spielt derzeit Zuverlässigkeit die wichtigste Rolle, da investieren wir auch gern mal einige Hunderter mehr in die Switches.

mfg
Maxl
 
Ich hab jetzt auch mal mit BSEND / BRCV unter Verwendung unten stehender SPS (2 Stück) einige Tests gemacht. Dabei hab ich jeweils 240Byte aus einem DB verschickt, also 1x hin und 1x zurück. Ansonsten läuft nix auf der SPS, so dass ich eine Zykluszeit von 1ms habe.

SPS1:
Manueller Start (auf '1' steuern) des REQ vom BSEND, wodurch auch ein Timer gestartet wurde. Der Timer wurde wieder gestoppt wenn am NDR des BRCV der Datemempfang signalisiert wurde.

SPS2:
Die Emfangsbestätigung NDR des BRCV ist direkt mit dem REQ des BSEND verbunden, so dass die angekommenen Daten sofort zurückgeschickt werden.

Dauer der Kommunikation mit BSEND/BRCV: 30ms

Das ganze hat natürlich jetzt nix mit Profinet zu tun, denn meine CPs unterstüzen das nicht. War also reine S7-Kommunikation.
Zwischen den Steuerungen, die direkt nebeneinander stehen, ist ein Hirschmann Switch.
Ob jetzt Pakete verloren gehen kann ich nicht 100%ig sagen, aber sieht irgendwie nicht danach aus, denn dann mussten die Zeiten ja auch mal wesentlich länger werden. (oder?)

@Maxl:
Hab ich da jetzt nen "Fehler" drin? Ich hab ja doch wesentlich schnellere Werte als du.


Ergänzung:
8000Byte hin und zurück: 860ms
1000Byte hin und zurück: 120ms
 
Zuletzt bearbeitet:
Ja, natürlich. Mein Versuchsaufbau liegt nach wie vor bei mir am Schreibtisch.

Also die von Dir gemessene Zeit kann ich nicht 1:1 nachvollziehen, jedoch ist ist das durchaus plausibel. Ich muss dazusagen, dass ich die Status-Bits der SEND/RECV-Bausteine nicht direkt für die Laufzeitmessung verwende, sondern dass ich ein Bit in den Nutzdaten hin und herschicke.
Master --> Slave; Slave schickt 1:1 zurück; Master invertiert empfangenes Bit und schickt wieder zu Slave usw.
Ich messe nun am Master die Zeit vom letzten Zustandswechsel des Bits, bis dieser Zustand vom Slave zurückkommt. Dadurch dann ich die Reaktionszeit in einer realen Applikation recht genau bestimmen.


Mein Versuchsaufbau läuft mittlerweile seit Donnerstag (7.12.) wieder durch. Werde Ende dieser Woche wieder mal ein Resumée ziehen, und dann den Versuchsaufbau wieder umbauen.


mfg
Maxl
 
Zuletzt bearbeitet:
@ Maxl:
Hast du dir denn mal meine "Messbeschreibung" durchgelesen? Ich komme ja auf ganz andere Werte, aber hab irgendwie keine passende Erklärung dafür. Hast du eine?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute

also wenn ihr jetzt RFC Verbindungen nutzt ist die Datensicherheit durch das Protokoll an sich sichergestellt, dh das Protkoll sorgt dafür das ein(mehrere) Datenframes von Sender zum Empfänger übertragen werden und dort auch exakt mit dem selben Inhalt ankommen. Ist nun die Hardware die dazwischen geschaltet wurde stabil(keine Ausfälle der Switches oder der Ethernet CPs) kommt auch alles an was abgeschickt wird.

die Ethernetlandschaft sollte von einem Spezialisten geprüft werden wenn es sehr wichtig ist das eine 100% Verfügbarkeit vorhanden ist.

am Ethernet CP der S7 gibt es eine Statistikfunktion welche Online angesehen werden kann.

Hier gibts noch zwei versteckte Befehle welche diese Statistik erweitern und eventuelle Netzwerkfehler aufzeigen.

1. smcie
2. history

diese Befehle einfach blind bei aktivem NCM S7 Diagnosefenster eingeben und schon wird die entsprechende Statistik eingeblendet.

ansonsten kann ich nur sagen das ich sehr zufrieden bin mit der RCF Kommunikation über ISO on TCP.


allerdings handhaben wir es bei uns in der Firma auch so das wir synchrone Telegrammquittierungen eingebaut haben damit auch eine zusätzliche Sicherheit auf Softwareebene vorhanden ist.
 
So, schließe meinen Versuch nun mal vorläufig ab.

Also nochmal mein Versuchsaufbau:
2 x CPU317-2PN/DP, CP343-1 Lean bei 1. CPU, Scalance X208 Switch, PN/PN-Koppler, Surecom 30€-Switch


Versuchsaufbau 1:
Code:
CPU1 / CP343-1-Lean     CPU2       
  |         |             |
  |  +------+             |
  |  |  +-----------------+
  |  |  |  +-----------------------------------------+  +----> Firmennetz
  |  |  |  |        +----------+    +-------------+  |  |  +--> Laptop
  |  |  |  |        |          |    |             |  |  |  |
  |  |  |  |      X1P1 X1P2  X2P1 X2P2          Surecom-Switch
Scalance-X208        PN/PN-Koppler

Versuchsaufbau 2:
Code:
CPU1 / CP343-1-Lean                                       CPU2
  |         |                                               |
  |  +------+                                               +----------------+
  |  |                                                                       |
  |  |     +-----------------------------------------+  +-----> Firmennetz <-+
  |  |     |        +----------+    +-------------+  |  |  +--> Laptop
  |  |     |        |          |    |             |  |  |  |
  |  |     |      X1P1 X1P2  X2P1 X2P2          Surecom-Switch
Scalance-X208        PN/PN-Koppler

Ich hoffe mal, meine Zeichnungen sind halbwegs verständlich.

Beim ersten Versuchsaufbau sind die beiden CPUs direkt über den Scalance X208 verbunden, lediglich der PN/PN-Koppler kann nur über den Standard-Switch angesprochen werden. Dieser Aufbau ist ist vom 3. bis 18. Jänner (mit 2 Nächte Ausnahme) durchgelaufen.

Beim zweiten Versuchsaufbau hängen zwischen den CPUs neben dem X208 und dem Surecom-Switch noch 3 Switches von unserem Firmennetz (100MBit-Anbinung, GBit Backbone). Dieser Versuchsaufbau lief 2 mal über Nacht.


Die Kopplung erfolgte insgesamt über 6 Protokolle:
- S7-Verbindung: PUT/GET, USEND/URECV, BSEND/BRECV
- Profinet IO: Master-Slave-Kopplung (CPU2 = Master, CP343-1 = Slave), PN/PN-Koppler
- Profinet-CBA

CBA hab ich nach den ersten Versuchen sofort wieder verworfen, da iMAP meiner Meinung nach für die Kommunikationsprojektierung bei NICHT-Technologiemodulen absolut unbrauchbar ist. Es bleiben also 5!

1. S7-Verbindung, PUT/GET
Bei beiden Aufbauten keine messbaren Laufzeitunterschiede. Blockgröße 212 Byte, Signallaufzeit von CPU1 zu CPU2 und retour ca. 150ms

2. S7-Verbindung, USEND/URECV
Bei beiden Aufbauten keine messbaren Laufzeitunterschiede. Blockgröße 212 Byte, Signallaufzeit von CPU1 zu CPU2 und retour ca. 75ms

3. S7-Verbindung, BSEND/BRECV
Bei beiden Aufbauten keine messbaren Laufzeitunterschiede. Blockgröße 240 Byte, Signallaufzeit von CPU1 zu CPU2 und retour ca. 200ms

4. Profinet-IO, CPU als Master, CP343-1 Lean als Slave, Profinet-Aktualisierungszeit 2ms
Konnte hier ebenfalls kaum Laufzeitunterschiede messen, allerdings gab es beim 2. Aufbau einen Busausfall. Nach Erhöhen der Aktualisierungszeit auf 4ms keine Ausfälle mehr. Datenmenge 512 Byte, Signallaufzeit von CPU1 zu CPU2 und retour max. 45ms

5. Profinet-IO, PN/PN-Koppler
Datenmenge 256 Byte, Signallaufzeit von CPU1 zu CPU2 und retour max. 8ms (PN-Aktualisierungszeit 8ms) bzw. 16ms (PN-Aktualisierungszeit 4ms). Bei Versuchsaufbau 2 und 2ms-Aktualisierungszeit einmal Busausfall.


Kommunikationsablauf bei den S7-Verbindungen:
PUT/GET: Put und Get werden immer nacheinader abgearbeitet, eine gleichzeitige Bearbeitung macht die Verbindung eher langsamer
SEND/RECV: eine CPU ist "Master", eine ist "Slave". Die Master-CPU sendet Daten, die Slave-CPU sendet nur Daten zurück, wenn zuvor Daten vom Master empfangen wurde. Empfängt der Master nicht binnen einer definierten Zeit die Daten vom Slave, wird erneut gesendet. Es sind 2 Sendwiederholungen möglich, bevor die Überwachung anspricht. Die Differenz zwischen gesendeten und empfangenen Datenblöcken ist die Anzahl der verlorenen Datenblöcke.

Zur Messung der Signallaufzeit läuft ein Bit in den Nutzdaten im Kreis (kein Takt, sondern Handshake-Signal). Es wird immer die Laufzeit Hin und Zurpck gemessen - als in einer Applikation nutzbare Reaktionszeit kann also die Hälfte der gemessenen Zeit angenommen werden.


So, Resümee:
Alle 3 Arten der S7-Kommunikation sind gut einsetzbar bei Datenmengen bis 212 Byte. USEND/URECV ist etwas schneller, PUT/GET etwas leichter zu programmieren. BSEND/BRECV würde ich nur verwenden, wenn ich Datenblöcke > 212 Byte schicken muss. Für Signale, bei denen schnell reagiert weren muss, sind S7-Verbindungen wohl nicht geeignet.

Müssen wirklich Signale in Echtzeit hin- und hergeschaufelt werden, bleibt wohl nur der Umweg über CP343-1 Lean als Slave oder (besser) ein PN/PN-Koppler.


Switches
Ein genaues Urteil zum Thema Switches kann ich wohl erst abgeben, wenn ich mal größere IO-Systeme am laufen hab. Für S7-Verbindungen und Visu-Anbindung sollten Standard-Unmanaged-Switches absolut ausreichend sein.
Für die IO-Anbindung wird es wohl darauf ankommen, welche Reaktionszeit gefordert wird. Kann man als PN-Aktualisierungszeit 8, 16 oder 32ms verkraften, sind sicher keine Scalance X2xx notwendig, ein Scalance X1xx oder vergleichbare Modelle von Phönix oder Hirschmann sollten absolut ausreichen.


wie gehts weiter
Ich arbeite derzeit an einer Anlage, wo 3 F-CPUs über die PN-Schnittstelle gekoppelt werden sollen. Hierbei sollen auch die sicherheitsgerichteten Signale übers Ethernet laufen. Hab morgen einen Herrn von Siemens im Haus, mit dem ich das Thema F-Kopplung über Ethernet durchgehen möchte.
Zusätzlich werden auch noch Bediengeräte und SEW-Servos an der PN-Schnittstelle betrieben. Erste Ergebnisse mit der Anlage wirds im April geben.


mfg
Maxl
 
...
Müssen wirklich Signale in Echtzeit hin- und hergeschaufelt werden, bleibt wohl nur der Umweg über CP343-1 Lean als Slave oder (besser) ein PN/PN-Koppler.
...
Da hab ich heute mal bei Siemens nachgehakt: ob, und warum es nicht möglich ist, so wie bei Profibus eine CPU als PN-Master und eine andere als PN-Slave zu konfigurieren (derzeit kann eine 317-2PN/DP an der PN-Schnittstelle nur Master).
Antwort: ist in Arbeit. kommt möglicherweise dieses Jahr noch. Soll als Firmwareerweiterung nachrüstbar sein.
 
Zurück
Oben