TIA Remanenzdatenverlust im normalen Betrieb. "Aus nach Stop" im Log

vollmi

Level-3
Beiträge
5.651
Reaktionspunkte
1.570
Ich habe eine S7-1512 die regelmässig (zwischen einem Tag und zwei Wochen) in Stop geht, und teilweise auch die LAN Verbindung verliert.
Nach dem Neustart ist die CPU wieder erreichbar aber das LOG ist nahezu leer. Ich habe die CPU auch schon ausgetauscht und im Büro betrieben ohne das Verhalten reproduzieren zu können, die neue CPU zeigt dasselbe Fehlverhalten. Die Memorycard wurde nicht mitgetauscht, es ist also die alte Karte vor Ort.
Die CPU wird mit 90 anderen gleicher Ausrüstung betrieben. die anderen laufen einwandfrei, die Software drauf ist zu 99% identisch bis auf die IO Copy.

Ich bin mir jetzt nicht sicher wo ich weitermachen könnte. Mir drängt sich der Verdacht auf, dass die Memorycard einen Schuss weg hat (ich hatte aber bei tausenden von CPUs der 1500er Reihe noch nie eine defekte Memorycard), aber auch die Spannungsversorgung möglicherweise instabil ist. Allerdings hatte ich da erwartet das die CPU einfach neu startet.

Hier das Log. zu beachten, vor dem Stop hatte die CPU das Korrekte Datum. der Letzte Log Eintrag fand offenbar nach der NTP Synchronisation statt.

Diagnosepuffer der Baugruppe QSK_4500 [CPU 1512SP-1 PN]


Artikel-Nr. / Bezeichn. Komponente Version
6ES7 512-1DK01-0AB0 Hardware 7
- - - Firmware V 2.9.7
Firmware-Erweiterung Firmware-Erweiterung ---


Baugruppenträger: 0
Steckplatz: 1


Seriennummer: S C-MDE754412020




1 von 7; Ereignis-ID: 16# 02:4428
Security-Information: Sitzungslegitimierung erfolgreich
SessionID 1536-16643

QSK_4500


Client IP-Adr: 10.145.32.10


Kommendes Ereignis
Ereignistyp:
17.05.2024 06:26:27.732
(Kodierung: 16# 34 01 00 5F 17 D0 2F 69 64 83 E0 C4 44 28 0C 00 06 00 41 03 00 00 00 32 00 02 00 00 00 00 00 00 F0 09 00 B6 00 00 00 00 0A 91 20 0A 00 00 00 00 00 00 00 00)


2 von 7; Ereignis-ID: 16# 02:400C
CPU-Info: Folge-Betriebszustandsübergang
Netz-ein-Hochlauf-Modus: WARMSTART --> RUN

Anlaufsperre(n) anstehend:
- keine Anlaufsperre gesetzt

CPU wechselt von Zustand STOP (Initialisierung) nach STOP

QSK_4500 / QSK_4500


Kommendes Ereignis
Ereignistyp: OK
01.01.2012 01:00:07.446
(Kodierung: 16# 20 01 00 0F 12 64 AE 74 E5 A9 56 3D 40 0C 0C 01 02 22 40 00 10 00 00 34 00 02 00 00 03 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)


3 von 7; Ereignis-ID: 16# 02:4009
CPU-Fehler: Warnung zu Remanenzdaten: Remanenzdaten verloren

Aktueller CPU-Betriebszustand: STOP (Initialisierung)

QSK_4500 / QSK_4500


Kommendes Ereignis
Ereignistyp: Fehler
01.01.2012 01:00:07.444
(Kodierung: 16# 20 01 00 10 12 64 AE 74 E5 87 CC 4D 40 09 0C 03 02 00 00 00 10 23 00 32 00 02 00 00 03 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)


4 von 7; Ereignis-ID: 16# 02:4468
Security-Information: ES/HMI-Kommunikation: Wechsel von Betriebszustand Bereitstellung nach sicher
QSK_4500


Kommendes Ereignis
Ereignistyp:
01.01.2012 01:00:06.912
(Kodierung: 16# 20 01 00 5F 12 64 AE 74 C5 D8 3E EC 44 68 0C 00 44 DA 44 DC 00 00 00 32 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)


5 von 7; Ereignis-ID: 16# 02:4441
Security-Information: Security-Konfiguration geändert

QSK_4500


Kommendes Ereignis
Ereignistyp:
01.01.2012 01:00:06.911
(Kodierung: 16# 34 01 00 5F 12 64 AE 74 C5 CA 68 79 44 41 0C 21 44 E3 44 E3 00 00 00 32 00 02 00 00 00 00 00 32 00 00 00 B5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)


6 von 7; Ereignis-ID: 16# 02:4403
Security-Information: Sitzungslegitimierungspasswort für Lese-/Schreibzugriff geändert

QSK_4500


Kommendes Ereignis
Ereignistyp:
01.01.2012 01:00:06.911
(Kodierung: 16# 34 01 00 5F 12 64 AE 74 C5 C2 91 D7 44 03 0C 00 00 00 44 E1 00 00 00 32 00 02 00 00 00 00 00 00 00 00 00 B5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)


7 von 7; Ereignis-ID: 16# 02:4001
CPU-Info: Hochfahren

Memory Card-Typ: Programmkarte (externer Ladespeicher)
CPU wechselt von Zustand AUS nach STOP (Initialisierung)

QSK_4500 / QSK_4500


Kommendes Ereignis
Ereignistyp: OK
01.01.2012 01:00:01.158
(Kodierung: 16# 20 01 00 0F 12 64 AE 73 6E E7 D0 B7 40 01 0C 01 03 01 00 00 10 00 00 34 00 02 00 00 0F 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)

Interessant finde ich 7 von 7. Aus nach Stop. Das hätte ich nach einem Spannungsabfall erwartet. Aber warum dann nach Stop und nicht nach Run?
Und dann 3 von 7. Woher kommt dieser Remamenzdatenverlust?
 
Wir hatten in den letzten Monaten gleich 2x den Fall, dass die 24V Versorgung Fehlerhaft war. 1x war es das Netzteil, 1x das Redundanzmodul. In beiden Fällen war es aber so, dass die 24V eine Zeitlang OK waren, und dann plötzlich für ein paar Sekunden ausgefallen sind.
Der Eintrag 7 aus den Log heißt ja nicht, dass die CPU nun den Zustand "AUS" hat, nachdem sie im "STOP" war, sondern sie war "AUS" und wechselt nun in "STOP". Das ist ja soweit erstmal normal nach dem Einschalten, da sie ja erstmal initialisieren und hochlaufen muss.

Also mein Verdacht liegt da am ehesten auf der 24V Versorgung
 
Ich habe die CPU auch schon ausgetauscht und im Büro betrieben ohne das Verhalten reproduzieren zu können, die neue CPU zeigt dasselbe Fehlverhalten.
Das schliesst die CPU ja eigentlich aus.

Wenn ein Analogeingang vorhanden ist, könnte man über einen Spannungsteiler die 24V messen und in der CPU einen Trace mit Pretrigger installieren. Fallen die 24V aus oder unter die minimal spezifizierte Betriebsspannung, läuft die CPU noch lange genug nach, um den Ausfall zu speichern. Der Trace sollte nach Neustart in der CPU vorhanden sein. Wenn nicht -> MMC ?

Oder man hängt eine 1200er parallel mit installiertem Trace auf die 24V, die braucht keine MMC und eine "nackte" 1200er-CPU läuft ca. 1-2s nach.
 
Evtl. Probleme mit den kleinen Pins der IO-Karten bzw. Sockeln oder dem Servermodul... Das macht auch undefinierte Fehler...
Wenn das nicht zu viele IOs sind, würd ich mal komplett alles tauschen!
 
Ich hatte ein ähnliches Fehlerbild einmal an einer 300’er. -> hier
Allerdings stand da etwas von "internem Systemfehler" im Diagnosepuffer.

Letztlich war es eine Kombination aus „ungünstigem“ EMV-Umfeld und dussliger Verdrahtung. Der Schaltschrankbauer ist mit der Masse streng nach Zielverdrahtung von der Montageplatte in die Tür und wieder zurückgesprungen. Mit vernünftiger Verdrahtung konnte über 100m Litze eingespart werden.
 
Okay dass ein EMV Problem zu so einem Verhalten führen kann, da wäre ich jetzt nicht drauf gekommen. Ich werde das Potential auch noch prüfen. Etwas unglücklich ist, dass hier ein Kupfernetzwerkkabel von fast 100 Metern von Schrank zu Schrank gezogen wird. Und die Zielsps erklettert werden muss, was den Zugang etwas erschwert.
Aber ich werde, sobald das Wetter besser wird, mal Karte tauschen lassen und auf Potentialprobleme prüfen.

ein Stopp, hätte ich jetzt erwartet, aber nicht dass dann das ganze Logfile gelöscht wird. Hätte man besser machen können.
 
dass hier ein Kupfernetzwerkkabel von fast 100 Metern von Schrank zu Schrank gezogen wird
Das ist schon grenzwertig. Die maximale Segmentlänge sind zwar 100m aber dann kommt es noch auf die Verlegung an ( einzeln verlegt oder parallel zu anderen Kabeln / Motorleitungen... )

PS:
Wenn ihr schon mal vor Ort seit, würde ich die MMC auch gleich tauschen.
 
Zurück
Oben