Step 7 Sicherheitsprogramm: Interner CPU-Fehler

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab bei 2 CPU mit unterschiedlicher Firmware das selbe Problem (V2.6.4 und V2.6.6).

Ich meinte eine der zwei CPU in einem Gehäuse.
Denn in einer F-CPU laufen ja zwei Programme in zwei CPu.
Die erste verarbeitet das von dir geschriebene Programm, die zweite bekommt das Programm in inverser Logik, das automatisch generiert wird.

Was ist denn ab bzw an Adresse 308 angeschlossen?
Denn 20 Byte sind schon viel für eine et200 Baugruppe.


bike

 

[Fenix]

Das ist doch ein handfester Hinweis auf eine bestimmte Adresse bzw. Baugruppe. Ereignis 1 und 2 würde ich zunächst einmal als Ulk verbuchen. Die auslösende Fehlerursache ist wahrscheinlich Ereignis 3. Wenn du die Funktion "Systemfehler melden" nutzen würdest, bekämst du eventuell konkrete Hinweise auf die Fehlerursache. "Systemfehler melden" projektieren ist in der Onlinehilfe beschrieben.

Die Meldungen der fehlenden Profibusslaves hauen mir den ganzen Diagnosepuffer voll. Ursache für diese Meldung, ein projektierter Frequenzumrichter, den ich hier im Büro nicht habe wird reklamiert. Ist aus meiner sicht normal. E/A-Bereich 308 ist für diesen Frequenzumrichter vergeben.

 

[Fenix]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich meinte eine der zwei CPU in einem Gehäuse.
Denn in einer F-CPU laufen ja zwei Programme in zwei CPu.
Die erste verarbeitet das von dir geschriebene Programm, die zweite bekommt das Programm in inverser Logik, das automatisch generiert wird.

Was ist denn ab bzw an Adresse 308 angeschlossen?
Denn 20 Byte sind schon viel für eine et200 Baugruppe.


bike

Hallo Bike,
schon, bei Siemens wird es nach meiner Info durch ein inverses Programm aber mit einem Prozessor gelößt, aber
das tut ja nix zur Sache.
E/A-Bereich 308 ist für einen Frequenzumrichter reserviert, reine Standardanwendung.
Meine Vermutung, was mir noch nicht ganz klar ist wie es zu der Diagnosemeldung Interner CPU-Fehler kommt
ist, das die Safetyklemme an dem Profibusfeldbusknoten defekt ist.
Meine Erfahrung, gestern die gelbe Klemme getausch und seither ist die CPU durchgelaufen.
Ich hoffe dass es kein Zufall war.

 

[Onkel Dagobert]

Die Meldungen der fehlenden Profibusslaves hauen mir den ganzen Diagnosepuffer voll...

Ich meinte nicht den Diagnosepuffer, sondern die Option "Systemfehler melden". Die findest du in der HW-Konfig unter "Extras", wenn die CPU selektiert ist. Es ist ein geringer Projektierungsaufwand mit enormen Nutzen. Die Meldungen kannst du dir auch im Simatic-Manager anzeigen lassen (ohne Panel).

.. wie es zu der Diagnosemeldung Interner CPU-Fehler kommt.....

In dem Link von Matze aus Beitrag 2 heißt es "..Die F-CPU geht in STOP durch einen internen Fehler (16#75D1). Die in der Hilfe zum Fehler angeführten Punkte treffen nicht zu..". Ich weiß nicht so recht, wie man diese Aussage deuten soll. Ich schätze die Meldung kommt als Sammelfehler oder fälschlicherweise als Folgefehler.

.. Meine Erfahrung, gestern die gelbe Klemme getausch und seither ist die CPU durchgelaufen.
Ich hoffe dass es kein Zufall war.

Nur interessehalber, was für eine Klemme war das denn genau?


Gruß, Onkel

 

[Fenix]

Hallo Onkel D.

ich hab mir das schon angeschaut, und für mich kommt aus meinem aktuellen Wissen keiner der folgenden
Ursachen in Frage.

• Das Standard-Anwenderprogramm beschreibt unzulässig Daten des Sicherheitsprogramms.
• Über "Variable beobachten/steuern" wurden Daten des Sicherheitsprogramms unzulässig verändert.
• Automatisch generierte Programmteile wurden verändert oder gelöscht.
• Es wurden in HW Konfig im Dialog "Eigenschaften CPU", Register "F-Parameter" für die F-CPU reservierte Bausteine verändert oder gelöscht.
• Ein interner CPU-Fehler ist aufgetreten.

Das systemfehler melden habe ich mir gerede angeschaut. Hab bisher nicht damit gearbeitet.
Jetzt hab ich ein paar neue Bausteine, kann aber nicht wirklich was damit anfangen. Kommen da andere Informationen raus wie ausm Diagnosepuffer?

Achja die Safetyklemme von einem Hersteller mit W am Anfang unterstützt das ganze nicht oder andersrum, sie wird nicht unterstützt.
Die Klemme ist eine mit 4DI und 4 DO alles Failsafe.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Fenix,

..Jetzt hab ich ein paar neue Bausteine, kann aber nicht wirklich was damit anfangen. Kommen da andere Informationen raus wie ausm Diagnosepuffer?..

Ich denke schon. So weit ich weiß werden alle Diagnosedaten angezeigt, die die Baugruppe sendet. Die Baugruppe muß natürlich diagnosefähig sein. Standard DE/DA-Baugruppen sind meist nicht diagnosefähig, analoge Baugruppen hingegen schon. "Systemfehler melden" nutze ich auch erst seit ein paar Wochen und ich möchte es nicht mehr missen. In meinem aktuellen Projekt habe ich Wago-Anschaltungen (750-333) über Profibus. Die analogen, diagnosefähigen Klemmen melden Fehler, wenn sie z.Bsp. nicht beschaltet sind. Die Diagnose kann man bei Bedarf kanalweise deaktivieren. Welche Fehler gemeldet werden, hängt von der jeweiligen Baugruppe ab.

..Achja die Safetyklemme von einem Hersteller mit W am Anfang unterstützt das ganze nicht oder andersrum, sie wird nicht unterstützt...

Sie muß nicht explizit unterstützt werden. Es reicht ganz einfach, wenn sie Diagnosetaten sendet. Ich hätte nicht geglaubt daß man Safetyklemmen von Wago mit Siemens verwenden kann. Gut zu wissen.

..Die Klemme ist eine mit 4DI und 4 DO alles Failsafe.

Diese senden sicherlich auch Diagnosedaten. Wenn du die Bausteine generiert hast, bist du mit der Projektierung bereits fertig. Bei der Inbetriebnahme kannst du im Simatic-Manager unter "Zielsystem - CPU-Meldungen.." ein Fenster öffnen, in dem die entsprechenden Meldungen erscheinen. Die Meldungen kommen nur bei kommenden oder gehenden Ereignis. Also kein Zumüllen wie im Diagnosepuffer. Die Meldungen kannst du aber auch an einem Panel anzeigen. Unter WinCCflexible ist das z.Bsp. ohne viel Tippserei möglich. Die Meldungen werden ohne dein Zutun importiert.

Probier's einfach mal aus.


Gruß, Onkel


PS: Zum "Spielen" kann man übrigens auch in PCLSIM Diagnosealarme simulieren (Ausführen - Fehler-OB auslösen). Dabei erhält man auch einen Eindruck über den Umfang der möglichen Meldungen.

 

[Fenix]

Hallo Onkel Dagobert!



Zufälligerweise nutze ich auch den Koppler 333 und wie von Dir beschrieben sind die E/As nicht diagnosefähig. Leider auch nicht unsere Safetyklemme.

Wir nutzen zur Diagnose von W bereitgestellte Bausteine. Man erhält für jeden 333 Koppler einen DB der dann den Blinkcode und die Diagnose der einzelnen Klemmen enthält,
soweit diese diagnosefähig sind.

Zum Thema, nach den jetzigen Stand gehe ich schwer davo aus, dass das Problem mit dem CPU-Fehler durch die Sicherheitsklemme am PB verursacht wurde.

 

[DeltaMikeAir]

Hallo Onkel D.

ich hab mir das schon angeschaut, und für mich kommt aus meinem aktuellen Wissen keiner der folgenden
Ursachen in Frage.

• Das Standard-Anwenderprogramm beschreibt unzulässig Daten des Sicherheitsprogramms.
• Über "Variable beobachten/steuern" wurden Daten des Sicherheitsprogramms unzulässig verändert.
• Automatisch generierte Programmteile wurden verändert oder gelöscht.
• Es wurden in HW Konfig im Dialog "Eigenschaften CPU", Register "F-Parameter" für die F-CPU reservierte Bausteine verändert oder gelöscht.
• Ein interner CPU-Fehler ist aufgetreten.

Auch wenn der Beitrag schon alt ist, vielleicht ist ies trotzdem für jemand interessant. Das FAQ zum Fehler 16#75D1 wurde erweitert,
zusätzlich zu den oben genannten Punkten kam folgender hinzu:

Alter Teil:
Fehlerbehebung:

1. Überprüfen Sie das Standard-Anwenderprogramm auf Rückwirkungen auf das Sicherheitsprogramm.
2. Prüfen Sie, ob über "Variable beobachten/steuern" unzulässig Daten des Sicherheitsprogramms verändert werden.
3. Kopieren Sie aus der F-Bibliothek verwendete F-Bausteine erneut in das Sicherheitsprogramm.
4. Generieren Sie das Sicherheitsprogramm erneut.
   oder
5. Tauschen Sie die F-CPU aus.

Neu hinzugefügt (1.12.2020):
Die Ursache kann jedoch auch folgende sein:
In einem F-Baustein greifen Sie lesend auf eine Temp-Variable zu, ohne diese vorher initialisiert zu haben. Damit verarbeiten Sie im Sicherheitsprogramm ein Signal, welches einen unbestimmten Zustand hat. Der F-Kontrollbaustein erkennt dies und setzt die F-CPU in den sicheren STOP-Zustand.

Abhilfe

• Initialisieren Sie alle temporären Variablen durch einen schreibenden Zugriff, bevor Sie lesend auf sie zugreifen oder
• verwenden Sie sichere globale Operanden aus einem F-DB oder
• setzen Sie statische Variablen innerhalb eines F-FBs ein.

Quelle:
https://support.industry.siemens.co...n-fehler-16-75d1-in-stop-geht-?dti=0&lc=de-WW