Step 7 CPU-Stop aufgrund Profibusfehler

Hallo,
eventuell hatte jemand ein ähnliches Problem, wie folgendes und daher einen Ratschlag. Eine bestehende Anlage geht seit etwa 2 Wochen unregelmäßig in Stopp, aber kann immer sofort wieder manuell in Run umgeschaltet werden.
Der CPU-STOP, wahrscheinlich aufgrund Dezentrale Peripherie, Profibusfehler, ist mir bisher nicht erklärlich, da OB121 PROG_ERR und OB122 MOD_ERR und OB86 RACK_FLT online sind.
Als Fehler im Diagnosepuffer wird Dezentrale Peripherie, die Adresse 5 angegeben, siehe Anhang. Profibusteilnehmer mit der Adresse 5 ist ein Encoder und dieser wurde bereits getauscht inklusive Profibuskabel, Profibusstecker und Versorgungsleitung. Jedoch der Fehler tritt immer noch unregelmäßig auf. Einen weiterer Profibusteilnehmer gibt es nicht.
Was könnte die Ursache des CPU-Stopps sein oder mit welchen Werkzeugen ist es möglich, einen CPU-Stopp zu verhindern?
Danke für Eure Unterstützung.
Anhang anzeigen Profibusfehler.pdf

Endwiderstand drin? An beiden Enden?

Gesendet von meinem SM-G925F mit Tapatalk

trabajador73 schrieb:

Was könnte die Ursache des CPU-Stopps sein oder mit welchen Werkzeugen ist es möglich, einen CPU-Stopp zu verhindern?

Zum Vergrößern anklicken....

Schau in den Diagnosepuffer der CPU, aber nicht bei irgendwelchen Profibus-Meldungen sondern bei dem Eintrag wo die CPU in STOP geht. Da (oder kurz davor) steht dann auch welcher OB angefordert wurde. Das könnte z.B. auch noch OB85 oder OB82 oder OB80 oder ... sein.

Harald

Danke für die bisherigen Antworten,
die Endwiderstände sind on, die Anlage läuft auch und lief zuvor einige Jahre ohne dauerhaften Busfehler bzw. ohne dieses aktuell unregelmäßig auftretende CPU-Stopp Phänomen.

Hallo Harald,

Deine Ausführung ist mir schon in etwa verständlich, jedoch wenn der entsprechende OB, hier OB86 und OB82 online sind, dann ist mir der CPU-Stopp nicht zu erklären. Im folgenden sind die Diagnosepuffermeldungen aufgeführt.



Ereignis 1 von 10: Ereignis-ID 16# 4302
Betriebszustandsübergang von ANLAUF nach RUN
Anlaufinformation:
- Uhr für Zeitstempel bei letztem NETZ-EIN gepuffert
- Einprozessorbetrieb
Aktuelle/letzte durchgeführte Anlaufart:
- Neustart (Warmstart) über Betriebsartenschalter; letzter NETZ-EIN gepuffert
Zulässigkeit bestimmter Anlaufarten:
- manueller Neustart (Warmstart) zulässig
- automatischer Neustart (Warmstart) zulässig
Letzte gültige Bedienung oder Einstellung der automatischen Anlaufart bei NETZ-EIN:
- Neustart (Warmstart) über Betriebsartenschalter; letzter NETZ-EIN gepuffert
Bisheriger Betriebszustand: ANLAUF (Neustart/Warmstart)
Angeforderter Betriebszustand: RUN
kommendes Ereignis
03:18:19.193 09.01.1994
(Kodierung: 16# 4302 FF68 C700 0000 0813 7713)


Ereignis 2 von 10: Ereignis-ID 16# 1381
Manuelle Neustart (Warmstart)-Anforderung
STOP-Ursache: STOP durch Peripherieverwaltung
Anlaufinformation:
- Anlauf ohne geänderten Systemausbau
- keine Soll-/Istdifferenz vorhanden
- Uhr für Zeitstempel bei letztem NETZ-EIN gepuffert
- Einprozessorbetrieb
Aktuelle/letzte durchgeführte Anlaufart:
- Neustart (Warmstart) über Betriebsartenschalter; letzter NETZ-EIN gepuffert
Zulässigkeit bestimmter Anlaufarten:
- manueller Neustart (Warmstart) zulässig
- automatischer Neustart (Warmstart) zulässig
Letzte gültige Bedienung oder Einstellung der automatischen Anlaufart bei NETZ-EIN:
- Neustart (Warmstart) über Betriebsartenschalter; letzter NETZ-EIN gepuffert
Angeforderter OB: Anlauf-OB (OB 100)
Prioritätsklasse: 27
kommendes Ereignis
03:18:19.192 09.01.1994
(Kodierung: 16# 1381 1B64 C772 4548 0813 7713)


Ereignis 3 von 10: Ereignis-ID 16# 4301
Betriebszustandsübergang von STOP nach ANLAUF
STOP-Ursache: STOP durch Peripherieverwaltung
Anlaufinformation:
- Uhr für Zeitstempel bei letztem NETZ-EIN gepuffert
- Einprozessorbetrieb
Aktuelle/letzte durchgeführte Anlaufart:
- Neustart (Warmstart) über Betriebsartenschalter; letzter NETZ-EIN gepuffert
Zulässigkeit bestimmter Anlaufarten:
- manueller Neustart (Warmstart) zulässig
- automatischer Neustart (Warmstart) zulässig
Letzte gültige Bedienung oder Einstellung der automatischen Anlaufart bei NETZ-EIN:
- Neustart (Warmstart) über Betriebsartenschalter; letzter NETZ-EIN gepuffert
Bisheriger Betriebszustand: STOP (intern)
Angeforderter Betriebszustand: ANLAUF (Neustart/Warmstart)
kommendes Ereignis
03:18:19.100 09.01.1994
(Kodierung: 16# 4301 FF46 C772 4548 0813 7713)


Ereignis 4 von 10: Ereignis-ID 16# 38C4
Dezentrale Peripherie: Station Wiederkehr
Adresse des betroffenen DP-Slaves: Stationsnummer: 5
DP-Mastersystem-ID: 1
Log. Basisadresse des DP-Slaves: Eingangsadresse: 1022
Log. Basisadresse des DP-Masters: Eingangsadresse: 2047
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
externer Fehler, gehendes Ereignis
03:18:14.616 09.01.1994
(Kodierung: 16# 38C4 FE56 C054 07FF 03FE 0105)


Ereignis 5 von 10: Ereignis-ID 16# 3842
Baugruppe ok
Baugruppentyp: Dezentrale Peripherie
Eingangsadresse: 1022
Anwenderinformation vorhanden
Diagnosealarm von Stellvertreter
Angeforderter OB: Diagnosealarm-OB (OB 82)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
externer Fehler, gehendes Ereignis
03:18:14.564 09.01.1994
(Kodierung: 16# 3842 FE52 C554 03FE 0063 0000)


Ereignis 6 von 10: Ereignis-ID 16# 3842
Baugruppe ok
Baugruppentyp: Dezentrale Peripherie
Eingangsadresse: 1022
Anwenderinformation vorhanden
Diagnosealarm von Stellvertreter
Angeforderter OB: Diagnosealarm-OB (OB 82)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
externer Fehler, gehendes Ereignis
03:18:14.562 09.01.1994
(Kodierung: 16# 3842 FE52 C554 03FE 0063 0000)


Ereignis 10 von 10: Ereignis-ID 16# 38C4
Dezentrale Peripherie: Station Wiederkehr
Adresse des betroffenen DP-Slaves: Stationsnummer: 5
DP-Mastersystem-ID: 1
Log. Basisadresse des DP-Slaves: Eingangsadresse: 1022
Log. Basisadresse des DP-Masters: Eingangsadresse: 2047
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
externer Fehler, gehendes Ereignis
03:18:13.935 09.01.1994
(Kodierung: 16# 38C4 FE56 C054 07FF 03FE 0105)

Lies dir mal folgendes durch:

Hinweis
Ein Peripherieverwaltungsfehler kann nicht durch einen Fehler-OB abgefangen werden.

Zum Vergrößern anklicken....

https://support.industry.siemens.co...peripherieverwaltung-auf-stop-?dti=0&lc=de-WW

Fehler "Stop durch Peripherieverwaltung"

Der Fehlercode von meinem Link zu Siemens passt nicht zu deinem Fehlercode, wichtig ist letztendlich die Information:

Hinweis
Ein Peripherieverwaltungsfehler kann nicht durch einen Fehler-OB abgefangen werden.

Zum Vergrößern anklicken....

In dem o.g. Diag-Auszug sieht man aber nicht die definitive Stop-Ursache bzw. die zugehörige Meldung dazu ...

Stop durch Peripherieverwaltung hatte ich bisher nur ein einziges Mal, in Verbindung mit Spannungsschwankungen an den IM360/361 Modulen, ein eigenes Netzteil für CPU + CP + IMs hat hier jetzt seit mehreren Jahren zuverlässige Abhilfe geschaffen. Im Prinzip würde ich das Problem hier eher lokal auf dem CPU Rack bzw. dessen lokalen Erweiterungen suchen.

trabajador73 schrieb:

Ereignis 3 von 10: Ereignis-ID 16# 4301
Betriebszustandsübergang von STOP nach ANLAUF
STOP-Ursache: STOP durch Peripherieverwaltung

Zum Vergrößern anklicken....

Suche/Zeige uns den/die Diagnosepuffereintrag(e), wo die CPU in STOP geht. Sehr wahrscheinlich musst Du dazu unter [Einstellungen] die Anzeige von allen bzw. mehr als 10 Einträgen erst freischalten.

Die Diagnosepuffer-Einträge 1 bis 3 betreffen das Starten der CPU von STOP über ANLAUF zu RUN. Alle gezeigten Diagnosepuffer-Einträge haben mit dem STOP-gehen nichts zu tun.

Es wird auch OB82 angefordert - hast Du einen OB82 in der CPU?

PS: Stell doch mal die Uhr der CPU (Zielsystem > Uhrzeit stellen)

Harald

OB80, OB82, OB85, OB86, OB100, OB121 und OB122 sind online.
Heute wurde zudem die CPU und das Netzteil getauscht, jedoch der Fehler tritt weiterhin unsporalisch auf.
Ein weiterer Anhang mit Fehlermeldungen des Diagnosepuffers wurde hochgeladen.Anhang anzeigen 2018-06-19_1257_Diagnose.txt

Interessant,

die gleichen Fehlercodes wie hier schon mal geschrieben:

https://www.sps-forum.de/simatic/80878-s7-317-2dp-stuerzt-ab.html?highlight=4358

Siemens-Support hat einen hilfreichen Hinweis mitgeteilt.

"Da CPU und Stromversorgung schon getauscht wurden, kommt nun noch eine Überlastung des Rückwandbus in Frage.
Hierzu empfehle ich die Belastung auf den einzelnen Kanälen zu beobachten, evtl wird ein Ausgang überlastet
und zieht deshalb die Spannung am Rückwandbus runter.
Dies kann sowohl die Analogausgänge wie auch die digitalen Ausgänge betreffen.
Evtl. ist auch eine Baugruppe defekt."

Die Ursache des CPU-Stopps lag an einer Türverriegelung. In dessen Innenraum wird ein Induktionselement ständig auch mit Wasser gekühlt.
Vielen Dank für jeden Beitrag.
Frohes Schaffen.

trabajador73 schrieb:

Siemens-Support hat einen hilfreichen Hinweis mitgeteilt.

"Da CPU und Stromversorgung schon getauscht wurden, kommt nun noch eine Überlastung des Rückwandbus in Frage.
Hierzu empfehle ich die Belastung auf den einzelnen Kanälen zu beobachten, evtl wird ein Ausgang überlastet
und zieht deshalb die Spannung am Rückwandbus runter.
Dies kann sowohl die Analogausgänge wie auch die digitalen Ausgänge betreffen.
Evtl. ist auch eine Baugruppe defekt."

Zum Vergrößern anklicken....

"Überlastung des Rückwandbus durch Belastung auf den einzelnen Kanälen" - Das klingt mir völlig unglaubwürdig. Kam der Tip vom Level-1-Support oder vom "richtigen" Siemens-Fachleute-Support?

Ich glaube eher, daß da eine Baugruppe im zentralen Rack eine Macke/Defekt hat oder EMV-Probleme bestehen.
Der Diagnosepuffer läßt tatsächlich darauf schließen, daß eventuell der Rückwandbus gestört wird. Es gibt unmotivierte Einträge über "Baugruppenüberwachungszeit gestartet" (z.B. 47, 53, 198 ) und "Ende der Synchronisation mit einem DP-Master/IO-Controller" (z.B. 37, 135) ohne vorherigen Eintrag über einen Grund. (Vielleicht sind die Diagnose-Einträge aber auch reduziert, weil die CPU die ganze Zeit in STOP war).

Liest und analysierst Du eigentlich auch mal selber die Einträge im Diagnosepuffer?
Was nützen uns die von Dir präsentierten 500 Diagnosepuffer-Einträge, wenn die CPU die ganze Zeit über in STOP war? Wie soll man erforschen warum die CPU in STOP ging, wenn da kein einziger Eintrag bzgl. in STOP-gehen drin ist???

(Keine Angst, ich werde Dich jetzt nicht noch ein drittes Mal auffordern, endlich mal Diagnosepuffer-Einträge bezüglich in STOP gehen zu suchen/zeigen... )

trabajador73 schrieb:

Die Ursache des CPU-Stopps lag an einer Türverriegelung. In dessen Innenraum wird ein Induktionselement ständig auch mit Wasser gekühlt.

Zum Vergrößern anklicken....

Wie besteht da eine Wirkkette zum CPU-STOP und/oder zum Rückwandbus? Kannst Du uns das evtl. genauer und schlüssig erklären?


Deine CPU 315-2DP: 315-2AH14 V3.3.10
ich würde mal auf die neueste Firmware V3.3.12 updaten

Harald

Je nach Leistung und Frequenz, enstehen in einer Härteanlage schon "brutalle" EMV-Ausstrahlungen !


Wurde EMV-Mässig was verändert ?

Es wurden 2 Spulenkontakte von Türverriegelungen von digitalen Ausgängen abgeklemmt und daraufhin ist der CPU-Stopp nicht mehr aufgetreten. Im Innenraum findet eine Wasserkühlung statt. Wasserspritzer bzw. die Wasserdampfentstehung aufgrund einer Induktionshärtung (Erhitzung) von Metallstangen könnte schon einen Spannungsabfall im Rückwandbus verursachen, wenn das Gehäuse der Verriegelung oder Kabelzugang nicht dicht sind. Die Anlage hat schon einige Jahre hinter sich. Die hohe Luftfeuchtigkeit ermöglicht eine bessere Leitfähigkeit was einen erhöhten Spannungsabfall an der Verriegelungsspule oder irgendwo an der Zuleitung hervorrufen kann und damit einen Spannungsabfall am Rückwandbus verursachen könnte.
Die Spannung ist zuvor von mir gemessen worden, an diesen Ausgängen, jedoch dabei wurde mit 24,..V nicht auffälliges gemessen.
EMV-mässig wurde nicht geändert? Bei einen FU ist am Gehäuse noch eine zusätzliche Erdung montiert und ein geschirmtes Kabel von FU zu den Klemmen im Schaltschrank neu gelegt worden, jedoch danach ist die CPU auch wieder in den Stoppzustand gegangen. Die CPU ließ sich manuell auch immer wieder sofort in den Runzustand bringen. Erst seit Abklemmung der beiden Ausgänge ist kein weiterer CPU-Stopp aufgetreten.
Aus den Diagnosemitteilungen wurden schon versucht, hilfreiche Informationen zu erhalten. Es wurde ja alles vom Encoder gewechselt, jedoch wenn ein 2. Teilnehmer am Profibus integriert wäre, dann wäre dieser auch aufgeführt worden, aber dieser hätte mit der eigentlichen Fehlerquelle auch nichts zu tun.

trabajador73 schrieb:

Es wurden 2 Spulenkontakte von Türverriegelungen von digitalen Ausgängen abgeklemmt und daraufhin ist der CPU-Stopp nicht mehr aufgetreten. Im Innenraum findet eine Wasserkühlung statt. Wasserspritzer bzw. die Wasserdampfentstehung aufgrund einer Induktionshärtung (Erhitzung) von Metallstangen könnte schon einen Spannungsabfall im Rückwandbus verursachen, wenn das Gehäuse der Verriegelung oder Kabelzugang nicht dicht sind. Die Anlage hat schon einige Jahre hinter sich. Die hohe Luftfeuchtigkeit ermöglicht eine bessere Leitfähigkeit was einen erhöhten Spannungsabfall an der Verriegelungsspule oder irgendwo an der Zuleitung hervorrufen kann und damit einen Spannungsabfall am Rückwandbus verursachen könnte.

Zum Vergrößern anklicken....

Danke für Deine Erläuterungen, doch die klingen für mich Elektroniker ziemlich abenteuerlich...
Was meinst Du mit "nicht dicht" und "hohe Luftfeuchtigkeit"? Ist die SPS Wasserspritzern, Wasserdampf oder sehr hoher Luftfeuchtigkeit/Betauung ausgesetzt?

Bei den S7-300-Ausgangsbaugruppen wo ich die Schaltung kenne, sind die Ausgangsschaltungen von der Rückwandbusanschaltung galvanisch getrennt (Optokoppler) - wie soll da ein Ausgang Spannungen am Rückwandbus beeinflussen? Das geht eigentlich nur mit Spannungsüberschlägen oder Impulseinkopplungen. Mir scheint daß da die Last in unzulässiger Weise angeschaltet wurde. Verbessert sich das Verhalten durch den Einsatz von Koppelrelais?

Welche Ausgangsbaugruppe ist das?
Kannst Du vielleicht doch noch Diagnosepuffereinträge zum in-STOP-gehen der CPU präsentieren?

Harald

Alos die Erklärung verwundert mich auch etwas. Die Belastung eines Ausganges sollte am Rückwandbus keine Rolle spielen, da diese über Optokoppler komplett
vom Rückwandbus entkoppelt sind. Wie Harald schon schrieb, eine galvanische Trennung. Meine Vermutung wäre auch, dass diese Last unzulässig geschaltet.

Verwendet wird als digitale Ausgangsbaugruppe: 6ES7 322-1BL00-0AA0
Meine Vermutung zum CPU-Stopp ist, daher die Mitteilung von Wasserdampf und -spritzer:
Im Gehäuse der Härtemaschine wird mittels Induktion Metallstangen erhitzt. Herum um die Induktionsspule wird mit Wasser gekühlt, wobei Wasserspritzer entstehen und auch eine Wasserverdunstung stattfindet, was Wasserdampf verursacht. Dies erhöht die Luftleitfähigkeit und kann damit auch einen Kurzschluss zwischen L+ und L- verursachen, wenn das Gehäuse zur Elektronik der Verriegelungshartware nicht 100% dicht ist.
So hatte ich auch den Siemenshinweis verstanden, dass aufgrund einer Art Kurzschlusssituation die Spannung des Rückwandbuses auch vermindert werden kann.
Wenn die digitale Ausgangsbaugruppe mit galvanischer Trennung aufgebaut ist, dann ist mir auch nicht erklärlich, warum der CPU-Stopp jetzt nicht mehr auftritt. Aber seit der Abklemmung der Verriegelungszuleitung am Mittwoch oder Donnerstag letzter Woche ist die CPU nicht mehr in den Stoppzustand gegangen.

Für mich klingt das auch alles sehr zweifelhaft. Ein Zusammenhang mit der Türverriegelung ist offensichtlich, aber mit dem Rückwandbus dürfte diese nicht direkt verknispelt sein.

• Kannst du mal die elektrische Schaltung der Türverriegelung beschreiben?
• Wird diese tatsächlich direkt mit 24VDC aus dem 0,5A-SPS-Ausgang versorgt?
• Gibt es weitere Schaltglieder zwischen SPS-Ausgang und Türverriegelung?
• Gibt es an dieser Stelle ein (event. defektes) Entstörglied?
• Lässt sich ein zeitlicher Zusamenhang mit den Schaltvorgängen der Türverriegelung erkennen?

• Kannst du mal die elektrische Schaltung der Türverriegelung beschreiben? Diese Frage wird später beantwortet, im Schaltplan ist nur eine Versorgung von +24V und L- aufgeführt.

• Wird diese tatsächlich direkt mit 24VDC aus dem 0,5A-SPS-Ausgang versorgt? ja
• Gibt es weitere Schaltglieder zwischen SPS-Ausgang und Türverriegelung? nein
• Gibt es an dieser Stelle ein (event. defektes) Entstörglied? kann ich nicht beantworten, die Hardware wird von beiden Türverriegelungen ausgetauscht. Im angezogenen Zustand ist die Tür verriegelt, also zeigt normales Funktionsverhalten.
• Lässt sich ein zeitlicher Zusamenhang mit den Schaltvorgängen der Türverriegelung erkennen? nein, die CPU geht nicht in den Stoppzustand wenn ein Ein- bzw. Ausschalten des Ausganges praktiziert wird.

Die Mitteilungen des Diagnosepuffers, wie gewünscht, wurden von mir noch nicht veröffentlicht, was ich jetzt nachhole als Anhang.Anhang anzeigen 2018-06-19_1257_Diagnose.txt

trabajador73 schrieb:

Die Mitteilungen des Diagnosepuffers, wie gewünscht, wurden von mir noch nicht veröffentlicht, was ich jetzt nachhole als Anhang.Anhang anzeigen 41790

Zum Vergrößern anklicken....

Der Diagnosebuffer sagt aber OB82 und 86 wären nicht vorhanden. Sehe ich das Falsch?