TIA 1500er CPU-stop nach Zeitumstellung

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Zusammen,

wir haben einen Kunden, bei dem sind (alle) drei Steuerungen (S7-1515F-2 PN | 6ES7 515-2FM01-0AB0 | Firmware: V2.5.2) wegen der Winter-/Sommerzeitumstellung in den Stop-Zustand gewechselt. Die Steuerungen wurden mit TIA V15 programmiert.

Dabei standen im Diagnosepuffer 586 - 88 (501 Einträge) innherhalb von 53 ms:


Darauf folgte der CPU-Stop:



Für die Zeitumstellung benutze ich "SET_TIMEZONE". Bisher habe ich das beschriebene Verhalten noch nicht beobachtet. Dies war das erste Mal. Allerdings verstehe ich auch nicht, was jetzt genau den CPU-Stop ausgelöst hat.
Und: wir konnten die CPUen einfach wieder auf RUN stellen und danach gab es keine Probleme mehr.
Warum hat der CPU-Stop nicht sofort nach dem ersten Uhrzeitalarm-Fehler ausgelöst?


Hat Jemand dieses Verhalten schon einmal beobachtet oder sogar eine Lösung, durch irgend welche OBs, Einstellungen, etc.?

VG

MFreiberger

 

[ducati]

Nutzt Du denn die Uhrzeitalarme OB11? Wenn ja wofür?
Warum nutzt Du Set-Timezone? Wie ist in der HW-Konfig die Uhr konfiguriert? Sommer/Winterzeitumstellung macht die SPS doch selbst, wenn die Zeitzone Berlin eingestellt ist???
Welche CPU Firmware?
Hat das was mit F zutun?

Vermutlich nutzt Du irgendeine Sonderlocke, die noch niemand bei Siemens je ausprobiert hat.

Mit dem Firmware-Ausnahmefehler würd ich natürlich ne Supportanfrage stellen.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du solltest ein FW-Update machen ( von deiner V2.5.2 auf V2.9.2 ):


Aus dem V2.9.2 Update:

Die Ursache des Fehlers „Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#04440000 16#10020000 16#00000000) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“ wurde behoben. Das Verhalten bei hoher Systemauslastung wurde verbessert.

Quelle

 

[PN/DP]

Für die Zeitumstellung benutze ich "SET_TIMEZONE".

Wie machst Du das?? Warum machst Du das?
Mit SET_TIMEZONE soll nicht die Uhr umgestellt werden, sondern eigentlich nur einmalig die Uhr der CPU auf die Zeitzonen-Parameter eingestellt werden, dann kennt die Uhr die Umrechnungsparameter von Systemzeit (UTC) zu Lokalzeit (CET/CEST) und passt sich automatisch an. Für den Fall daß die CPU gewechselt wurde sollte man SET_TIMEZONE bei jedem Anlauf der CPU aufrufen.

Werden die Uhrzeit-Alarme der S7-1500 generell (oder nur in Deinem Programm) mit der Lokalzeit programmiert? Sollte das nicht mit der Systemzeit programmiert sein? Oder hast Du auf irgendeinem Weg tatsächlich die Uhr (Systemzeit) verstellt?
Für die Zukunft lade einen OB80 in die CPU, damit sie beim nächsten Mal nicht wieder in STOP geht.

Harald

 

[MFreiberger]

Moin Ducati,

Nutzt Du denn die Uhrzeitalarme OB11? Wenn ja wofür?

Ja, ich nutze die Uhrzeitalarme OB11. In diesem Fall als Stundentrigger, um statistische Daten zu sammeln bzw. Zähler zu initiieren.

Warum nutzt Du Set-Timezone?

Für die Einstellung der Lokalzeit.

Wie ist in der HW-Konfig die Uhr konfiguriert? Sommer/Winterzeitumstellung macht die SPS doch selbst, wenn die Zeitzone Berlin eingestellt ist???

War mir nicht bewusst. Gilt das ab einer bestimmten Firmware? SET_TIMEZONE funktioniert seit V1.7. Vielleicht wurde die Einstellung über die HW erst später implementiert?

Welche CPU Firmware?

V 2.5.2

Hat das was mit F zutun?

Nichts. Wieso?

Vermutlich nutzt Du irgendeine Sonderlocke, die noch niemand bei Siemens je ausprobiert hat.

Nicht, dass ich wüsste.

Mit dem Firmware-Ausnahmefehler würd ich natürlich ne Supportanfrage stellen.

ja

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du solltest ein FW-Update machen ( von deiner V2.5.2 auf V2.9.2 ):
Anhang anzeigen 60049

Aus dem V2.9.2 Update:

Quelle

Moin DMA,

super, danke Dir!

 

[ducati]

Für die Einstellung der Lokalzeit.

zum Stellen der Uhr würd ich WR_LOC_T bzw. WR_SYS_T verwenden. Aber wie gesagt, normalerweise macht die SPS die Sommer-/Winterzeitumstellung selber...

War mir nicht bewusst. Gilt das ab einer bestimmten Firmware? SET_TIMEZONE funktioniert seit V1.7. Vielleicht wurde die Einstellung über die HW erst später implementiert?

 

[MFreiberger]

Wie machst Du das??

In einem Anlauf-OB setze ich ein Initialisierungsbit. Mit diesem Bit wird der REQ von SET_TIMEZONE gesetzt. Wenn SET_TIMEZONE fehlerfrei durchgelaufen ist (DONE), wird das Initialisierungsbit zurückgesetzt.

Warum machst Du das?

Es erschien mir die sinnvollste Lösung zu sein, um die Sommer-/Winterzeitunstellung einzustellen. Ich bin mir gerade nicht sicher, ob es zu dem Zeitpunkt, zu dem ich es programmiert hatte, eine andere Möglichkeit (HW) gegeben war. Möglicherweise habe ich es auch nur als eine Möglichkeit ausgewählt.

Mit SET_TIMEZONE soll nicht die Uhr umgestellt werden, sondern eigentlich nur einmalig die Uhr der CPU auf die Zeitzonen-Parameter eingestellt werden, dann kennt die Uhr die Umrechnungsparameter von Systemzeit (UTC) zu Lokalzeit (CET/CEST) und passt sich automatisch an. Für den Fall daß die CPU gewechselt wurde sollte man SET_TIMEZONE bei jedem Anlauf der CPU aufrufen.

Ja, ist bekannt.

Werden die Uhrzeit-Alarme der S7-1500 generell (oder nur in Deinem Programm) mit der Lokalzeit programmiert? Sollte das nicht mit der Systemzeit programmiert sein? Oder hast Du auf irgendeinem Weg tatsächlich die Uhr (Systemzeit) verstellt?

Naja, das ist ja nun frei einstellbar (Kontext OB >> Allgemein >> Uhrzeitalarm). Ich stelle "nur" die Lokalzeit. Aber das hat ja Auswirkungen auf die Systemzeit?!
Aus der Hilfe zum Uhrzeitalarm-OB:


Ich habe einen neuen UhrzeitAlarm-OB eingefügt. Standardmäßig ist die Systemzeit eingestellt. Allerdings versuche ich alles im Programm auf die Lokalzeit zu beziehen. Dann tut man sich leichter mit der Kommunikation zu den Service-Technikern und muss nicht jedesmal neu überlegen, welche Zeit in diesem Fall verwendet wird.

Für die Zukunft lade einen OB80 in die CPU, damit sie beim nächsten Mal nicht wieder in STOP geht.

Guter Hinweis, danke.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

zum Stellen der Uhr würd ich WR_LOC_T bzw. WR_SYS_T verwenden. Aber wie gesagt, normalerweise macht die SPS die Sommer-/Winterzeitumstellung selber...

Anhang anzeigen 60052

Moin ducati,

danke, da hatte ich bisher nicht reingeguckt. Nur, warum sollte es Probleme geben, wenn ich SET_TIMEZONE verwende? Dabei geht es am Ende doch "nur" um die Einstellungen der CPU, die an dieser Stelle in der HW vorgenommen werden?

 

[Onkel Dagobert]

Wenn Uhrzeitalarme durch Uhrzeit- oder Datumsverstellung übersprungen werden, gingen auch schon frühere Simatic-Steuerung auf Stopp. Das scheint so gewollt zu sein. Warum das jetzt als "schwerer Ausnahmefehler" gemeldet wird, kann ich nicht nachvollziehen. Solche Trigger-Signale sollte man sich besser selbst bilden.

 

[MFreiberger]

Wenn Uhrzeitalarme durch Uhrzeit- oder Datumsverstellung übersprungen werden, gingen auch schon frühere Simatic-Steuerung auf Stopp. Das scheint so gewollt zu sein. Warum das jetzt als "schwerer Ausnahmefehler" gemeldet wird, kann ich nicht nachvollziehen. Solche Trigger-Signale sollte man sich besser selbst bilden.

Ok, das wusste ich nicht.
Das werde ich beherzigen.

Danke

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum das jetzt als "schwerer Ausnahmefehler" gemeldet wird, kann ich nicht nachvollziehen.

Anscheinend steigt die Last der CPU in der Situation so stark an, das die CPU in diesen Ausnahmefehler geht

Die Ursache des Fehlers „Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#04440000 16#10020000 16#00000000) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“ wurde behoben. Das Verhalten bei hoher Systemauslastung wurde verbessert.

 

[ducati]

Moin ducati,

danke, da hatte ich bisher nicht reingeguckt. Nur, warum sollte es Probleme geben, wenn ich SET_TIMEZONE verwende? Dabei geht es am Ende doch "nur" um die Einstellungen der CPU, die an dieser Stelle in der HW vorgenommen werden?

ja, aber warum machst Du das???

Die Einstellung in der HW-Konfig gibts doch schon mindestens seit V12...

Da stellst Du einmal ein und gut...

Das ist anders als bei den Comfortpanels. Bei den Panels musst Du aktiv den Haken setzen ob die Sommerzeit jetzt grad aktiv ist oder nicht. Bei der SPS bedeutet der Haken, dass die SPS die Lokalzeit SELBSTSTÄNDIG umstellt.

 

[MFreiberger]

ja, aber warum machst Du das???

Kann ich Dir nicht beantworten. Habe ich nie hinterfragt. Wird rausgekickt.

Aber die Ursache meines Problems scheint ja wirklich bei den UhrzeitAlarm-OBs zu liegen.
Auf die werde ich in Zukunft verzichten.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dein SET_TIMEZONE verstellt nicht die Uhr, und ist nicht die Ursache des CPU-STOP. Wie ducati schon schrieb, kannst Du das auch komplett weglassen, wenn die Zeitzonenparameter in der Gerätekonfig der CPU eingestellt werden (ab Firmware ...). SET_TIMEZONE war/ist ein Notbehelf/Provisorium für CPU mit älterer Firmware, wo die Zeitzonenparameter noch nicht in der Gerätekonfig eingestellt werden konnten.

Ursache Deines Problems ist daß bei Dir die Uhrzeitalarme auf Verwendung von Lokalzeit eingestellt sind und da ist das Verhalten (Aufruf OB80) in TIA beschrieben. Parametriere die Uhrzeitalarm-OBs auf Verwendung der Systemzeit anstatt Lokalzeit. Da ändert sich die verwendete Uhrzeit nicht und es werden bei Sommerzeit-Umstellungen keine Uhrzeitalarme übersprungen. Den OB80 würde ich aber trotzdem bei Verwendung von Uhrzeitalarmen immer in die CPU laden, für den Fall daß irgendwie die Uhrzeit verstellt wird, z.B. manuelles Verstellen der Uhr, falls die Uhr nicht Uhrzeit-synchronisiert wird (z.B. nicht aktiviert oder NTP-Server nicht erreichbar).

Harald

 

[MFreiberger]

Dein SET_TIMEZONE verstellt nicht die Uhr, und ist nicht die Ursache des CPU-STOP. Wie ducati schon schrieb, kannst Du das auch komplett weglassen, wenn die Zeitzonenparameter in der Gerätekonfig der CPU eingestellt werden (ab Firmware ...). SET_TIMEZONE war/ist ein Notbehelf/Provisorium für CPU mit älterer Firmware, wo die Zeitzonenparameter noch nicht in der Gerätekonfig eingestellt werden konnten.

Alles klar, danke für Klarstellung.

Ursache Deines Problems ist daß bei Dir die Uhrzeitalarme auf Verwendung von Lokalzeit eingestellt sind und da ist das Verhalten (Aufruf OB80) in TIA beschrieben. Parametriere die Uhrzeitalarm-OBs auf Verwendung der Systemzeit anstatt Lokalzeit. Da ändert sich die verwendete Uhrzeit nicht und es werden bei Sommerzeit-Umstellungen keine Uhrzeitalarme übersprungen. Den OB80 würde ich aber trotzdem bei Verwendung von Uhrzeitalarmen immer in die CPU laden, für den Fall daß irgendwie die Uhrzeit verstellt wird, z.B. manuelles Verstellen der Uhr, falls die Uhr nicht Uhrzeit-synchronisiert wird (z.B. nicht aktiviert oder NTP-Server nicht erreichbar).

Danke, das werde ich tun.

 

[ducati]

Ursache Deines Problems ist daß bei Dir die Uhrzeitalarme auf Verwendung von Lokalzeit eingestellt sind und da ist das Verhalten (Aufruf OB80) in TIA beschrieben. Parametriere die Uhrzeitalarm-OBs auf Verwendung der Systemzeit anstatt Lokalzeit. Da ändert sich die verwendete Uhrzeit nicht und es werden bei Sommerzeit-Umstellungen keine Uhrzeitalarme übersprungen. Den OB80 würde ich aber trotzdem bei Verwendung von Uhrzeitalarmen immer in die CPU laden,

Stimmt das mit dem OB80???

Der OB80 ist doch dafür da, eine eimalige Zykluszeitüberschreitung abzufangen?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

OB80 steht im Diagnosepuffer beim Stop, und auch bei der TIA Beschreibung der Uhrzeitalarme.
In S7-300/400 war das auch schon immer der OB80, da heißt der OB80 ganz allgemein "Zeitfehler-OB"

Harald

 

[ducati]

OB80 steht im Diagnosepuffer beim Stop, und auch bei der TIA Beschreibung der Uhrzeitalarme.
In S7-300/400 war das auch schon immer der OB80, da heißt der OB80 ganz allgemein "Zeitfehler-OB"

Harald

OK, habs jetzt auch gelesen... nur versteh ich das aber so, dass bei S7-1500 und fehlendem OB80 bei "Zeitfehler" die CPU in RUN bleiben sollte:



die Handbücher sind echt alles andere als eindeutig

 

[MFreiberger]

Moin,

vor dem CPU-Stop wurde der UhrzeitAlarm-OB ja 501 mal aufgerufen. Der hat sicher den OB1 unterbrochen und für die Zykluszeitüberschreitung gesorgt.