TIA S7-1500 Bug in OB122

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zur Info an alle, auch wenn wir das aus Zeitgründen momentan nicht näher austesten können:

Es scheint einen kritischen Bug im OB122 Verhalten zumindest unter TIA V13SP1Upd9 mit S7-1515 FW 1.8.4 unter folgenden Bedingungen zu geben:

- in einen etwas größeren Projekt werden im OB1 mehrere Peripheriezugriffe L "EW128" ausgeführt, welche hier im Testsystem nicht erreichbar sind, da die ET200 nicht angeschlossen ist.

- dadurch wird bei uns der OB122 aufgerufen, in welchen die Fehlerbehandlung erfolgt, also z.B. generieren von Meldungen

- diese Auswertung erfolgt nur, wenn im OB122 der #OB122_SW_FLT gleich B#16#42 also Fehler beim PEW lesen

- wenn jetzt im OB35 zusätzlich schreibende Peripheriezugriffe T"AW128" erfolgen, welche nicht erreichbar sind, kommt es zu Problemen mit dem OB122!!!

- d.h. die Auswertung des OB122 mit dem "PEW lesen" Fehler erfolgt sporadisch (alle ca. 5 Sekunden) nicht.

- woran das konkret liegt, wissen wir nicht, wir vermuten, dass der OB122 Aufruf durch den OB35 unterbrochen wird, obwohl die Priorität vom OB122 natürlich höher ist als beim OB35. Oder der Wert #OB122_SW_FLT wird im OB122 nicht richtig gebildet, wenn Fehler vom OB1 und OB35 "auflaufen"


Vielleicht hat dazu schon mal jemand was gehört? Oder kann sich das erklären?

Einen Supportrequest stelle ich erstmal nicht, da ich momentan keine Zeit für die Diskussionen mit Siemens habe.

Gruß.

 

[Mediator]

Falls für Dich möglich könntest Du das ja mal mit V2.03 testen (natürlich ohne etwas im Projekt zu ändern), denn dort gab es eine Korrektur im Umfeld der OBs (siehe unten). Der beschriebene Fall ist zwar anders, die Ursache könnte aber ja vielleicht dieselbe sein. Naja, die Hoffnung stirbt zuletzt

The following behavior has been corrected with FW 2.0.3:

• The following sporadic message: "Serious firmware exception error (non user-relevant system code: 16#400001 16#10020074 16#4a6c24d0)“ does no longer occur if a ProcessEvent OB is triggered by various ProcessEvents having different priorities, such that it interrupts itself.

Link für Update 2.0.3: https://support.industry.siemens.com/cs/de/en/view/109478459

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK, danke schonmal,

hab grad leider nicht die Zeit großartig zu testen. Wir haben als workaround im OB35 alle PAW Zugriffe durch AW Zugriffe ersetzt, da wir sie eigentlich nicht benötigen.

Eine weitere Vermutung meinerseits, dass die Priorität des OB122 bei der 1500 nicht wie beschrieben fest ist, sondern wie bei 300/400 laut TIA-Hilfe die gleiche OB-Priorität wie der aufrufende OB hat... ausserdem könnte man auch noch mit optimiertem/nichtoptimiertem OB122 rumspielen...

Trotzdem das Firmewareupdate hört sich zumindest so an, dass dort noch Probleme schlummern DA wir aber eh mit TIA v13 programmieren, will ich eigentlich nicht auf FW 2 hochrüsten...

Gruß.

 

[Mediator]

O.K., dann hast Du ja Dein Problem schon gelöst

Deine Angst vor Inkompatibilität schein ja größer zu sein als Deine Angst vor den Fehlern in der alten Version Ist Deine Angst vor Inkompatibilität eigentlich konkret - gab es konkrete Vorkommnisse - oder ist sie noch abstrakt?

In einer laufenden Anlage würde ich ohne wirkliche Not allerdings auch keine neue Version einspielen.

 

[ducati]

O.K., dann hast Du ja Dein Problem schon gelöst

Naja, nen workaround halt... Es ist nur beängstigend, wenn man sich auf die korrekte Funktion der OBs nicht verlassen kann!

Deine Angst vor Inkompatibilität schein ja größer zu sein als Deine Angst vor den Fehlern in der alten Version Ist Deine Angst vor Inkompatibilität eigentlich konkret - gab es konkrete Vorkommnisse - oder ist sie noch abstrakt?

In einer laufenden Anlage würde ich ohne wirkliche Not allerdings auch keine neue Version einspielen.

Es ist noch keine laufende Anlage, geht aber bald zur Inbetriebnahme. V13 mit FW2.0 will ich eigentlich vorrangig nicht wegen der Warnmeldung beim Laden der SPS... Und auf v14 steigen wir definitiv noch nicht hoch, so viele Bugs wie da noch drin sind...

Gruß.F

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Scheint als ob jedweder P-Zugriff auf fehlende/defekte Hardware (nicht erreichbar) die 1500 an einigen Stellen in Bedrängnis bringt.

 

[ducati]

Scheint als ob jedweder P-Zugriff auf fehlende/defekte Hardware (nicht erreichbar) die 1500 an einigen Stellen in Bedrängnis bringt.

Tja, es scheint eigentlich alles, was über simple UND/ODER Verknüpfungen in FUP hinausgeht, das TIA in Bedrängnis zu bringen

Aber mal zum OB122, wie war denn die Priorität bei 300/400 mit Classic? war das wirklich so, dass der OB122 die selbe Priorität wie der aufrufende OB hat? und kann dann der OB122 welcher vom OB1 gerufen wurde wirklich durch nen OB35 unterbrochen werden? Und was passiert, wenn der OB35 dann wiederrum nen OB122 ruft? Mir wäre neu, dass es so in Classic funktioniert hätte?

In der 1500er soll es laut Handbuch aber so sein, dass der OB122 ne feste Priorität bekommt und somit eigentlich nicht vom OB35 unterbrochen werden kann, wenn die Priorität höher als beim OB35 eingestellt ist...

kennt sich da jemand aus?

Gruß.
F

 

[RONIN]

Aber mal zum OB122, wie war denn die Priorität bei 300/400 mit Classic? war das wirklich so, dass der OB122 die selbe Priorität wie der aufrufende OB hat?

Laut Handbuch "S7-300/400 System- und Standardfunktionen" war das so.

1.28 Peripheriezugriffsfehler-OB (OB 122)

Beschreibung
Das Betriebssystem der CPU ruft den OB 122 auf, wenn beim Zugreifen auf Daten
einer Baugruppe ein Fehler auftritt. Wenn die CPU beispielsweise einen Lesefehler
beim Zugriff auf Daten einer Signalbaugruppe erkennt, dann ruft das
Betriebssystem den OB 122 auf.

Funktionsweise des Peripheriezugriffsfehler-OB
Der OB 122 läuft in derselben Prioritätsklasse wie der unterbrochene Baustein. Ist
der OB 122 nicht programmiert, dann wechselt die CPU den Betriebszustand von
RUN nach STOP.

Auf Seite 14 folgend des Pdf sind die OB-Prioritäten anschaulich gelistet.

und kann dann der OB122 welcher vom OB1 gerufen wurde wirklich durch nen OB35 unterbrochen werden? Und was passiert, wenn der OB35 dann wiederrum nen OB122 ruft? Mir wäre neu, dass es so in Classic funktioniert hätte?

Mal kurz so durchgedacht...
OB1 Anfang
OB1 Peripheriezugriff mit Fehler

OB122 Unterbrechung (OB122 mit Priorität 1)​

OB35 Unterbrechung (Priorität 12)​

OB35 Peripheriezugriff mit Fehler​

OB122 Unterbrechung (OB122 mit Priorität 12)​

OB35 Rückkehr+Ende​

OB122 Rückkehr + Ende​

OB1 Rückkehr

Ist schon ein interessanter Ablauf.
Kehrt das BS nach dem OB35 dann wieder in den unterbrochenen OB122 zurück? Schon denke ich.
Womöglich schafft das Anwenderprogramm im OB122 dann die Auswertung nicht mehr zeitfolgerichtig.
Bin mir bei der Sache aber wenig sicher.

Wie sind denn die Default-Prioritäten von OB35 und OB122 bei der 1500 gesetzt?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

hmm, 2 parallele Instanzen vom OB122 in der 300er? geht das wirklich so? jedelfalls ist das uns in der 300er an dieser Stelle noch nie ein Problem aufgefallen. Bei mehreren 100 Anlagen. Bei der 2. 1500er funktionierts leider nicht mehr...
der OB122 hat in der 1500er Standardmaessig die Prioritaet 7. beim OB35 weiss ichs nicht.
in unserem von ne. 300er migrierten Projekt hat der OB122 die Prioritaet 26.

Gruss

 

[Mediator]

Mal kurz so durchgedacht...
OB1 Anfang
OB1 Peripheriezugriff mit Fehler

OB122 Unterbrechung (OB122 mit Priorität 1)​

OB35 Unterbrechung (Priorität 12)​

OB35 Peripheriezugriff mit Fehler​

OB122 Unterbrechung (OB122 mit Priorität 12)​

OB35 Rückkehr+Ende​

OB122 Rückkehr + Ende​

OB1 Rückkehr

Womöglich schafft das Anwenderprogramm im OB122 dann die Auswertung nicht mehr zeitfolgerichtig.

Genau so läuft es bei 300/400. Der OB122 wird quasi vom Peripheriezugriffsfehler aufgerufen, ähnlich wie ein FC.

Bei 1500 läuft es so ähnlich, wenn die Priorität des OB122 höher als die Priorität des Bausteins mit dem Peripheriezugriffsfehler ist.

OB1 Anfang
OB1 Peripheriezugriff mit Fehler

OB122 Unterbrechung (OB122 mit Priorität 26)​

OB122 Rückkehr + Ende // schon hier, wenn die Priorität vom OB122 höher als die vom OB35 ist​

OB35 Unterbrechung (Priorität 12)​

OB35 Peripheriezugriff mit Fehler​

OB122 Unterbrechung (OB122 mit Priorität 12)​

OB35 Rückkehr+Ende​

OB1 Rückkehr

Angenommen die Priorität vom OB122 ware niedriger als die vom OB35, dann liefe es vermutlich - d.h. ich habe das bisher nicht probiert - so:
OB1 Anfang
OB1 Peripheriezugriff mit Fehler

OB122 Unterbrechung (OB122 mit Priorität 7)​

OB35 Unterbrechung (Priorität 12)​

OB35 Peripheriezugriff mit Fehler // Ich nehme an, dass dieser Fehler nicht zu einem späteren OB122-Aufruf führt​

OB35 Rückkehr+Ende​

OB122 Rückkehr + Ende //​

OB1 Rückkehr

oder so, falls der OB35 nicht den OB122 unterbricht:

OB1 Anfang
OB1 Peripheriezugriff mit Fehler

OB122 Unterbrechung (OB122 mit Priorität 7)​

OB122 Rückkehr + Ende //​

OB1 Rückkehr

OB35 Unterbrechung (Priorität 12)​

OB35 Peripheriezugriff mit Fehler // Ich nehme an, dass dieser Fehler zu einem späteren OB122-Aufruf führt​

OB35 Rückkehr+Ende​

OB122 Unterbrechung (OB122 mit Priorität 7)OB122 Rückkehr + Ende //
​

OB1 Rückkehr

Fazit:
Wenn man für jeden Peripheriezugriffsfehler einen OB122 - Aufruf haben will - wie bei S7300/400 muss man dem OB122 höhere Priorität geben als den Bausteinen, die Peripheriezugriffsfehler auslösen können.
Wenn nicht, kann man dem OB122 eine entsprechend niedrigere Priorität geben. Vorteil: weniger OB122-Aufrufe - weniger Zykluszeitverlängerung; Nachteil: Ein OB122 - Aufruf sagt "nur" noch aus, dass es mindestens einen Peripheriezugriffsfehler gab.

 

[ducati]

Bei 1500 läuft es so ähnlich, wenn die Priorität des OB122 höher als die Priorität des Bausteins mit dem Peripheriezugriffsfehler ist.

OB1 Anfang
OB1 Peripheriezugriff mit Fehler

OB122 Unterbrechung (OB122 mit Priorität 26)​

OB122 Rückkehr + Ende // schon hier, wenn die Priorität vom OB122 höher als die vom OB35 ist​

OB35 Unterbrechung (Priorität 12)​

OB35 Peripheriezugriff mit Fehler​

OB122 Unterbrechung (OB122 mit Priorität 12)​

OB35 Rückkehr+Ende​

OB1 Rückkehr

Fazit:
Wenn man für jeden Peripheriezugriffsfehler einen OB122 - Aufruf haben will - wie bei S7300/400 muss man dem OB122 höhere Priorität geben als den Bausteinen, die Peripheriezugriffsfehler auslösen können.

und genau das scheint bei der 1500 nicht so zu funktionieren, ich vermute, hier steckt der Bug!!!

Mal kurz so durchgedacht...
OB1 Anfang
OB1 Peripheriezugriff mit FehlerOB122 Unterbrechung (OB122 mit Priorität 1)
OB35 Unterbrechung (Priorität 12)
OB35 Peripheriezugriff mit Fehler
OB122 Unterbrechung (OB122 mit Priorität 12)
OB35 Rückkehr+Ende
OB122 Rückkehr + Ende
OB1 Rückkehr

wie ist das bei der 300er? gibt es dann wirklich 2 parallel "offene" OB122?

bzw. generell bei 300/400, wenn ich im OB34 nen FC100 aufrufe und im OB35 auch nochmal den gleichen FC100 aufrufe, sollte doch eigentlich funktionieren, dass ich dann "2 Instanzen" vom FC100 habe? ist das bei den OBs (OB122) genauso?

nur zum Verständnis...

Gruß.

 

[hovonlo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, das ist so. Für Testzwecke habe ich mal ein Projekt für die 300er geschrieben, dass immer weiter in der Priorität hochging und letztlich

OB1 > OB121 > OB122
              OB10 > OB121 > OB122
                             OB20 > OB121 > OB122
                                            OB32 -> OB121 -> OB122
                                                             OB35 -> OB121 -> OB122
                                                                              OB40 -> OB121 -> OB122
                                                                                               OB82 -> OB121 -> OB122

diese ganze Kette durchlief und hintennach wieder sauber abräumte - wie halt Unterbrechungen funktionieren.

Bedeutsam ist dabei bereits die Klassifizierung der Alarme:

• OB121 und OB122 sind Synchronalarme, treten also synchron an einer vorhersehbaren Stelle des Codes (genau an/durch einen Befehl) auf. Somit ist eine Ausführung auch in der gleichen Prio-Ebene wie im Baustein., in dem das Ereignis aufgetreten ist, möglich. Letztlich kann man OB121/122 Aufrufe wie einen Call, der nur beim Eintreten eines Ereignisses (Peripheriezugriffsfehler, BCD-Wandlungsfehler, ..) ausgeführt wird, betrachten.
• Die ganzen anderen OBs (Zeit-, Weck-, Prozess-, Diagnose- und wie sie alle heißen Alarme) sind Asynchronalarme und können deshalb zu beliebigen Zeiten auftreten. Unter anderem auch außerhalb der Ausführung des OB1.

Generell hat jeder OB immer seinen eigenen Datenbereich, egal wie oft er aufgerufen wurde. Und wie sich das für einen vernünftigen Stack gehört, wird dieser auch genau so wieder abgebaut, wie aufgebaut wurde (LIFO).

Ich kann nicht sagen ob Siemens da bei der 1500er was geändert hat - kann ich mir aber nicht vorstellen, da das einfach das Grundprinzip einer Interrupt-Verarbeitung ist.

 

[Mediator]

Ich kann nicht sagen ob Siemens da bei der 1500er was geändert hat - kann ich mir aber nicht vorstellen, da das einfach das Grundprinzip einer Interrupt-Verarbeitung ist.

Ja das wurde geändert, d.h. OB121 und OB122 sind jetzt von der Verarbeitung her auch "Asynchronalarme". In der Online-Hilfe heißt es z.B.: Das Betriebssystem der S7-1500-CPU ruft den Programmierfehler-OB auf, wenn während der Bearbeitung einer Anweisung des Anwenderprogramms ein Programmierfehler auftritt. Der Programmierfehler-OB wird mit der für ihn eingestellten Priorität bearbeitet.

Bei 1500 ist hierbei noch zu erwähnen:
Wenn jemand einen neuen Baustein schreibt und lokale Fehlerbehandlung macht werden OB122 und 121 nicht aufgerufen, sondern die Fehler per lokale Fehlerbehandlung gemeldet.

 

[ducati]

Generell hat jeder OB immer seinen eigenen Datenbereich, egal wie oft er aufgerufen wurde. Und wie sich das für einen vernünftigen Stack gehört, wird dieser auch genau so wieder abgebaut, wie aufgebaut wurde (LIFO).

OK, also jeder einzelne der "mehrfach" geöffneten OB122 hat seinen eigenen/separaten Datenbereich? Also der zweite OB122 greift nicht auf die Daten vom ersten OB122 zu?

Ich kann nicht sagen ob Siemens da bei der 1500er was geändert hat - kann ich mir aber nicht vorstellen, da das einfach das Grundprinzip einer Interrupt-Verarbeitung ist.

ausserdem geht die 1500 ohne programmierten OB122 bei nem Peripheriefehler NICHT mehr in Stop... also ich denke, die haben dran rumgefummelt und es nicht hinbekommen...

Gruß.