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