Step 7 Siemens PN-PN-coupler Probleme (CPU Stop) beim Verbinden einer S7-317 und S7-1516

schneijo

Level-1
Beiträge
51
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Siemens Community,

wir haben aktuell ein Projekt mit einer Partner-Firma beim gemeinsamen Kunden.
Hier soll ein älters Automatisierungssystem einer Anlagensteuerung mit einem neuen Anlagenteil zwecks Signalaustausch gekoppelt werden.
(Wir sprechen hier von einer Standard-Anwendung)

Bei dem älteren System handelt es sich um folgende Konfiguration:
- CPU: S7-300 6ES7 317-2EK14-0AB0 / V3.2
- Peripherie-Baugruppen hängen nur am Profibus
- der PN/PN-Koppler ist der einzige Teilnehmer am Profinet Netzwerk
- Entwicklungsumgebung: Simatic Manager V5.6

PN-PN-Koppler:
- Siemens 6ES7 158-3AD10-0XA0 / V4.2
- Schnittstelle X1: angebunden an S7-1500 Seite
- Schnittstelle X2: angebunden an S7-300 Seite
- Gerätename: pn-pn-ch1-k003-x2 (X1 und X2 verwenden unabhängig von einander den gleichen Gerätenamen)

Bei dem neuen System handelt es sich um folgende Konfiguration:
- CPU: S7-1500 6ES7 516-3FN02-0AB0 / V2.9
- Peripherie-Baugruppen: Profinet
- Entwicklungsumgebung: TIA-Portal V17

Wir verantworten die Integration auf dem alten Anlagenteil in der S7-300 Steuerung.
Nun haben wir die Situation, dass die HW-Configuration beidseitig offensichtlich in Ordnung ist.
Stellenweise kommt es allerdings zu einem CPU-Stop auf der S7-300 Steuerung, wenn die HW-Config auf der 1500er Seite geladen wird.
Dieses Verhalten ist für uns nicht nachvollziehbar.

Es ist mitunter schwierig die Kommunikation überhaupt ans laufen zu bringen.
Die S7-300 Seite geht bei jeder simultanen Änderung der Konfigurationen in Stop.
Mit geziehlten Eingriffen und stellenweise abgezogenen PN-Verbindungen und Power-Restarts am Koppler
können wir die Kommunikation beidseitig ohne Fehler zum laufen bringen.
Allerdings ist das aus unserer Sicht keine sichere Betriebsweise wenn beim Laden der HW-Configs einseitig die CPU auf Stop geht.

Aus der CPU-Diagnose der S7-300 Steuerung haben wir folgenden Fehler ausgelesen:
- Stop durch Ziehen/Stecken (OB nicht geladen oder nicht möglich, bzw. kein FRB vorhanden)

Wir haben folgende Fehlerbehandlungs OBs im Code implementiert:
- OB86
- OB122

Was uns etwas sprachlos macht ist die Tatsache, dass wir zwischendurch die Kommunikation ans laufen bringen und stellenweise durch das Laden der HW-Config auf der S7-1500 Seite die S7-300 Seite derart beeinflusst wird, dass die CPU auf Stop geht.
Soll nicht eigentlich der Einsatz eines PN-PN-Kopplers genau dies verhindern?
Alle Komponenten von der Hardware bis zu den Entwicklungsumgebungen sind aus dem Hause Siemens.

Wir wären dankbar für jede Form von Idee dieses Problem nachhalting und dauerhaft zu lösen.
Vielen Dank für eure Mithilfe.

Beste Grüße
 

Anhänge

  • S7-317_diagnose.jpg
    S7-317_diagnose.jpg
    115 KB · Aufrufe: 41
Zuviel Werbung?
-> Hier kostenlos registrieren
Was uns etwas sprachlos macht ist die Tatsache, dass wir zwischendurch die Kommunikation ans laufen bringen und stellenweise durch das Laden der HW-Config auf der S7-1500 Seite die S7-300 Seite derart beeinflusst wird, dass die CPU auf Stop geht.
Das sollte euch nicht sprachlos machen sondern das Verhalten ist erst einmal richtig so.

Der PN/PN Koppler ist gestört, wenn die Partnerseite ( S7-1500 ) in STOP geht und auf der S7-300 Seite müsst ihr halt entsprechend reagieren ( Fehler-OB + Auswertung + ggf. Fehlermeldung generieren ).

Was erwartet ihr denn?
Soll nicht eigentlich der Einsatz eines PN-PN-Kopplers genau dies verhindern?
Nein, der Koppler soll die Netze/IP-Kreise trennen. Ein Koppler kann aber ebenso Fehler/Warnungen abwerfen und wenn ihr programmseitig darauf keine Reaktion projektiert habt, dann geht die CPU halt auf STOP.
 
Zuletzt bearbeitet:
Der OB83 hats gebracht, die CPU geht nicht mehr auf Stopp.
Aber nicht nur einen leeren OB83 einspielen, nur damit "Ruhe" ist. Die Eingangssignale vom Koppler sind dann ja ungültig (vermutlich alle auf 0 gesetzt), da sollte eine Reaktion programmiert werden, oder sind die Signale alle drahtbruchsicher verarbeitet?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum ein Ausfall eines PNPN Koppler allerdings wie ziehen einer Baugruppe behandelt wird und nicht wie ein Ausfall anderer PN-Devices behandelt wird, ist aus meiner Sicht auch nicht nachvollziehbar.
 
Das PN-Device ist ja nicht ausgefallen, sondern auf der anderen Seite wurde ein Modul deaktiviert/"gezogen". Zieht mal auf eurer Seite das Netzwerkkabel vom PN/PN-Koppler ab - was passiert dann?
 
Aber nicht nur einen leeren OB83 einspielen, nur damit "Ruhe" ist. Die Eingangssignale vom Koppler sind dann ja ungültig (vermutlich alle auf 0 gesetzt), da sollte eine Reaktion programmiert werden, oder sind die Signale alle drahtbruchsicher verarbeitet?
ich baue bei Kommunikationen immer nen Watchdog mit in die auszutauschenden Daten ein. Dann kann man direkt aus dem Watchdog die Fehlermeldung und Reaktion generieren. Unabhängig von diversen immer unterschiedlichen Fehler-OBs, Bausteinstatus oder sonstwas...
Deshalb sind bei mir die Fehler-OBs (meist) auch (fast) leer...
Zusätzlich noch nen Alarm bei ner roten CPU-LED, falls man mal irgendwo was vergessen hat...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum ein Ausfall eines PNPN Koppler allerdings wie ziehen einer Baugruppe behandelt wird und nicht wie ein Ausfall anderer PN-Devices behandelt wird, ist aus meiner Sicht auch nicht nachvollziehbar.
Das kannst Du bestimmt irgendwo konfigurieren...

hier könnte man ja mal experimentieren:
1693560551127.png
 
Zuletzt bearbeitet:
Das PN-Device ist ja nicht ausgefallen, sondern auf der anderen Seite wurde ein Modul deaktiviert/"gezogen". Zieht mal auf eurer Seite das Netzwerkkabel vom PN/PN-Koppler ab - was passiert dann?
Hallo,

das haben wir getestet, jedesmal wenn das Netzwerk-Kabel gezogen wird auf unserer Seite ging die CPU auf Stop.
Ich denke mit dem Wissen aus den oben geposteten Beiträgen ist das nachvollziehbar.
 
ich baue bei Kommunikationen immer nen Watchdog mit in die auszutauschenden Daten ein. Dann kann man direkt aus dem Watchdog die Fehlermeldung und Reaktion generieren. Unabhängig von diversen immer unterschiedlichen Fehler-OBs, Bausteinstatus oder sonstwas...
Ja, ein Watchdog Handling haben wir angedacht (y)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
jedesmal wenn das Netzwerk-Kabel gezogen wird auf unserer Seite ging die CPU auf Stop.
Ich hatte noch keinen PN/PN-Koppler, doch ich meine, da müsste aber ein anderer OB angefordert/aufgerufen werden, vermutlich OB86 oder OB85. Findet man alles im Diagnosepuffer der CPU.
 
Eigentlich immer das gleiche Spiel. Handbücher beantworten offene Fragen...

Wobei @ducati ja gemeint hat:
Ist doch nen alter Hut. Jemand baut nen Felbusgerät an ne SPS und wundert sich dann, warum die CPU ständig in Stop geht...

Im Maschinenbau ist das ja vielleicht noch so gewollt, in der Prozessautomatisierung hab ich aber normalerweise immer alle Fehler-OBs in der SPS...

1693565156964.png

Welche Fehlermeldungen man dann wie und warum generiert und welche Aktionen man daraus ableitet, steht dann wieder auf nem anderen (großen) Blatt.

Auf jeden Fall kann Handbuch und Diagnosepuffer lesen schon helfen, vor allem aber alles mögliche halt testen ;)
 
Zurück
Oben