CPU-CPU Kommuikation

Mikele

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

ich stehe gerade vor dem Problem das einer meiner Kunden behauptet das CPU- CPU Kommunikation über eine S7- Verbindung mit den Bausteinen F_SENDS7/F_RCVS7 andere Profinet- Protokolle (NRT/RT/IRT) benutzt als bei einer CPU- CPU Kommunikation über PN/PN Koppler mit den Bausteinen F_SENDDP/F_RCVDP. Daraus sollen sich dann erhebliche Laufzeitunterschiede ergeben.
In meinem Fall geht es zwar um Sicherheitsgerichtete Kommunikation, das gleiche gilt aber für die Standartkommunikation. Falls jemand Erfahrungen damit hat wäre ich echt dankbar.
 
Dein Kunde hat schon recht. Der Grund dafür liegt in der Art und weise, wie die beiden Arten der Kommunikation funkionieren.

Die Bausteine F_SENDDP/F_RCVDP arbeiten auf E/A-Ebene (SFC14/15) und am Ethernet läuft das ganze über das Protokoll Profinet-IO (RT). Dieses Protokoll garantiert eine schnelle echtzeittaugliche Kommunikation im Bereich von einigen Millisekunden (so wie Profinet-IO z.B. bei einer ET200S).
Die Kommunikation zwischen 2 Steuerungen funktioniert hierbei über einen PN/PN-Koppler. Wie bei einem DP/DP-Koppler werden hier die E/A-Daten quasi 'gekreuzt' --> die A-Daten von CPU 1 werden als E-Daten an CPU 2 gesendet und umgekehrt.

Die Bausteine F_SENDS7/F_RCVS7 kommunizieren über eine S7-Verbindung über herkömliches TCP/IP miteinander. Hierbei kommt kein echtzeittaugliches Protokoll zum Einsatz, die Kommunikation erfolgt intern über die Bausteine USEND/URECV (Testbericht mit diesen hier: http://www.sps-forum.de/showthread.php?t=9946).

Solange Du keine garantierten Reaktionszeit bei den Safety-Daten brauchst, bzw.eine Reaktionszeit im Bereich von mehreren 100ms zulässig ist, kannst Du F_SENDS7/F_RCVS7 verwenden. Muss es schnell gehen, kommst Du über einen DP/DP-Koppler oder einen PN/PN-Koppler nicht herum.

mfg
Maxl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus Maxl,

danke schon mal für Deine ausführliche Erklärung, ich hatte sowas schon vermutet. Ohne Deine Aussage in Zweifel stellen zu wollen, kannst Du mir verraten wo Du diese Informationen her hast?
Ich durchsuche seit Tagen alle möglichen Handbücher und FAQs und finde nirgendwo Erklärungen dazu welche Protokolle zum Beispiel die S7 Verbindung benutzt.:confused: In der Profinet Systembeschreibung von Siemens steht sogar das zur CPU- Kommunikation eine S7- Verbindung oder Send/Receive Verbindung genutzt werden kann ohne auf die Details hinzuweisen. Im Distributed Safety Handbuch genauso. :twisted:
Also, falls Du mir noch ein paar Quellenangaben schicken könntest wäre das toll! Wie gesagt ich glaube Deine Aussage ungeprüft, würde mir aber gerne noch etwas mehr Wissen zum Thema aneignen! Danke nochmal und schönene Grüße

Mikele
Ob S7-Verbindungen auf TCP oder UDT oder irgendwas anderes aufsetzen, kann ich Dir auch nicht mit Sicherheit sagen, sondern diese Aussage entstammt meinem Bauchgefühl. TCP ist jedenfalls naheliegend, da es ebenfalls Verbindungsbasiert ist.

Die Angaben zum Thema Sicherheitstechnik, Reaktionszeiten usw. entstammen keiner Schriftlichen Quelle, sondern aus Versuchen und einem Gespräch mit einem Techniker von Siemens, der den Bereich Safety Integrated bei Siemens Österreich betreut. Zusätzlich habe ich einige Versuche gemacht.
Zitat "Wenn Sie S7-Verbindungen verwenden, und die Überwachungszeiten entsprechend kurz einstellen (beim konkreten Projekt waren 40ms notwendig), ist zwar die Sicherheit nicht gefährdet, allerdings können wir von Siemens Ihnen nicht garantieren, dass auf Dauer nicht immer wieder Timeouts auftreten können - das kann nur bei PN/PN-Kopplern garantiert werden"

Die Aussage, dass F_SENDS7/F_RCVS7 mit USEND/URECV lässt sich
per Referenzdaten - Programmstruktur nachvollziehen (gleiches gilt übrigens für die Kombination
F_SENDDP/F_RCVDP - SFC14/15). Bekannt ist, dass die Fehlersichere Kommunikation über nichtsichere Kanäle erfolgt - die Sicherheit wird alleine durch das darauf aufsetzende sichere Anwenderprogramm gewährleistet (Stichwort "Profisafe" - bin mir allerdings nicht sicher, ob der Begriff "Profisafe" auch bei S7-Verbindungen korrekt ist). Da das sichere Anwenderprogramm
F_SENDS7/F_RCVS7 auf die nicht sicheren Funktionen USEND/URECV zurückgreift, darf davon ausgegangen werden, dass die Signallaufzeiten bei sicherer und nichtsicherer Kommunikation gleich sind.

Deine Feststellung, dass in den Distributed Safety Unterlagen keinerlei Angaben zu den unterschiedlichen Laufzeiten bei PN/PN-Kopplern und S7-Verbindungen gemacht werden, kann ich bestätigen.


Ich hoffe, die Tatsache, dass ich meine Aussagen jetzt nicht schriftlich begründen kann, stößt Dich jetzt nicht vor den Kopf. Habe letztes Jahr viel Zeit mit dem Thema verbracht - viel gelesen, viel getestet, viel mit Siemens telefoniert.
Unterm Strich ist eine Anlage mit 6 F-Steuerungen rausgekommen, welche per DP/DP-Koppler kommunizieren - Profibus war ohnehin vorhanden, die Komponenten sind nach wie günstiger als die PN-Komponenten und es waren keine Echtzeittauglichen Ethernet-Switches notwendig.


mfg
Maxl
 
Keine Angst, ich fühle mich nicht vor den Kopf gestoßen! Tausend Dank für Deine ausführlichen Antworten!

Mein Problem ist halt das ich die Aussagen meines Kunden prüfen und entweder bestätigen oder wiederlegen muß. Das eine wie auch das andere muß ich entweder dem Kunden, oder meinem Chef plausibel erklären und im Zweifelsfall auch Beweisen können (Kostenfaktor). Deshalb hätte ich gerne was schriftliches. Ich hoffe noch darauf das ich das diese Woche vom Siemens support bekomme.

Nochmal, vielen Dank für Deinen Beitrag, das hat mir sehr geholfen.Falls ich noch Material und Hintergrundwissen durch Siemens bekomme, lasse ich es Dir gerne zukommen falls Interesse besteht!

Gruß Mikele
 
...

Nochmal, vielen Dank für Deinen Beitrag, das hat mir sehr geholfen.Falls ich noch Material und Hintergrundwissen durch Siemens bekomme, lasse ich es Dir gerne zukommen falls Interesse besteht!

Gruß Mikele
Du darfst es auch gerne der Allgemeinheit zur Verfügung stellen, indem du es hier ins Forum setzt:rolleyes:
 
Zurück
Oben