TIA Hardware Diagnose TIA/500

[ssppss]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammmen,

ich beschäftige mich momentan mit der Hardware Diagnose. Von den Anforderungen her kann ich gar nicht so tief ins Detail gehen, da noch gar nicht so richtig klar ist, was man GENAU will am Ende. Aber mir sind bei meiner Recherche diverse Dinge aufgefallen, die ich einfach mal in die Runde fragen würde.

Grundlegend soll EIN PN IO System überwacht werden. Dabei sollen Fehler, das ziehen einer Baugruppe und das Deaktivieren einer Baugruppe erkannt werden, um in der PLC entsprechend zu reagieren.

(1) Die Überwachung auf Deaktivierung einer Baugruppe würde ich mit der Anweisung "DeviceStates"/"ModuleStates" im Mode 3 zyklisch im OB1 abfragen.

(2) Das Ziehen/Stecken einer Baugruppe könnte man ebenfalls mit der Anweisung "DeviceStates"/"ModuleStates" im Mode 4 zyklisch im OB1 abfragen, oder man könnte dies auch im Interrupt OB83 lösen.

(3) Fehler kann man ebenfalls mit der Anweisung "DeviceStates"/"ModuleStates" im Mode 5 zyklisch im OB1 abfragen, oder alternativ im Interrupt OB82.

Ich tendiere ja stark dazu, für (2) und (3) die entsprechenden OBs 83 und 82 zu nutzen, da dann keine zyklisch abfrage notwendig ist. Kann ich nun davon ausgehen, dass ich mit dem OB83 dasselbe erkenne, wie mit den Anweisungen "DeviceStates"/"ModuleStates" im Mode 4? Und das ich mit dem OB82 dieselben Fehler erkenne wie mit den Anweisungen "DeviceStates"/"ModuleStates" im Mode 5?

Zusätzlich stellt sich mir die Frage, was genau unter Störungen bei den Anweisungen "DeviceStates"/"ModuleStates" im Mode 2 erkannt wird? Sind das letztendlich auch Fehler, die ich im OB82 auch erkennen würde? Die Anweisung "Get_Diag" erkennt laut Doku keine "Störungen" sondern nur Fehler oder diverse andere Dinge.

Außerdem ist es doch so, dass die CPU beim Stecken/Ziehen bzw. Fehler in STOP geht, wenn der OB82/83 nicht programmiert ist. Inwiefern mach dann eine zyklische abfrage überhaupt Sinn? Oder liege ich da falsch?

In diesem Siemens Beispiel

https://support.industry.siemens.co...m-anwenderprogramm-mit-s7-1500?dti=0&lc=de-WW

erfolgt die Fehlerabfrage z.B. zyklisch. Allerdings mit Ausführungsbedingung der CPU Fehler LED. Wäre es aber nicht "besser" den OB82 dafür zu nutzen? Im OB82 wird ja lediglich der Fehlerzustand des IO-Systems gesetzt. Das könnte man doch direkt im OB82 tun und sich das Zyklische sparen???

In eigener Recherche bin nicht wirklich fündig auf die obigen Fragen geworden. Demnach wäre ich über Hilfe sehr dankbar.

Gruß

 

[DOD666]

Hallo,

kennst du dies schon: Diagnose im Anwenderprogramm

Was ich bei dem Beispiel schlecht finde ist die Visualisierung.
Dafür gibt es ja in WinCC schon die Systemdiagnose die all diese Informationen liefert,
ohne das man das noch mal extra durch die CPU schleifen muss oder PowerTags verbraucht.

Gruß

Jens

 

[ssppss]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ja kenne ich. Mir geht es auch gar nicht um die Visualisierung etc. sondern lediglich um die Erkennung der Zustände in der PLC für Reaktionen innerhalb der PLC.

 

[ducati]

Ich würds alles im OB1 aufrufen.
Ausserdem teste es doch einfach...

 

[PN/DP]

Ich würde auch zyklisch im OB1 alles diagnostizieren. Meine Erfahrung mit S7-300/400: Nur mit den Alarm-OBs 8x ist unsicher und läuft irgendwann weg von der Realität, besonders wenn die SPS auch mal ausgeschaltet wird. Z.B. Baugruppen die schon beim Hochlauf fehlen oder Probleme haben, lösen die OB nicht aus.

Harald

 

[ssppss]

Zuviel Werbung?
-> Hier kostenlos registrieren

Prinzipiell geht es mir darum, mit "DeviceState" erkenne ich folgende Zustände

1 konfiguriert.
2 gestört
3 deaktiviert
4 vorhanden
5 Problem

Ich würde meine Hardware gerne NICHT zyklisch abfragen, sondern ereignisgesteuert. Wenn ich mir nun die dafür in Frage kommenden OBs 82, 83 und 86 anschaue, stellen sich mir folgende Fragen:

OB82 (Diagnosealarm OB)
OB83 (Ziehen/Stecken OB)
OB86 (Baugruppenfehler OB)

Bei OB83 ist es eindeutig. Damit kann ich den Zustand 4 (vorhanden) von "DeviceState" erkennen. Aber bei OB82 und OB86 werde ich anhand der TIA-Hilfe nicht schlau, was da genau erkannt wird???? Und das Alles durchtesten ist aussichtslos.... Sowas muss doch eindeutig aus der Hilfe heraus entnehmbar sein???? Weiß da niemand bescheid, oder kann zumindest ein wenig Licht ins Dunkel bringen?

Was genau ist der Unterschied zwischen den erkennbaren Zuständen von "DeviceState" und den OBs 82, 83 und 86?

Bin für alle Hinweise dankbar.

 

[Ludewig]

Wie Harald PN/DP schon schrieb, ist die zyklische Abfrage zuverlässiger, da es Situationen gibt, wo der Interrupt nicht erkannt wird. Wovor hast Du Angst?

 

[ssppss]

Wir haben die OBs 82, 83 und 86 standardmäßig eh immer drin. Von dem her würde ich es halt sinnvoll finden, die dann auch dafür zu nutzen. Außerdem würde dadurch der Standardzyklus nicht unnötig belastet. Wenn das Zyklische zuverlässiger ist, spricht ansonsten nix dagegen. Dennoch bin ich jetzt angefixt und würde trotzdem gerne die Unterschiede der erkennbaren Zustände zwischen "DeviceState" (2 gestört, 5 Problem) und den OBs 82 und 86 in Erfahrung bringen. Weiß da niemand genaueres?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben die OBs 82, 83 und 86 standardmäßig eh immer drin.

Vermutlich weitgehend leere OB (höchstens Aufrufzähler oder eine Meldung generieren)? Vermutlich "weil wir das schon immer so machen", damit die CPU nicht in STOP geht, auch wenn die S7-1500 vielleicht gar nicht in STOP gehen würde.

Dennoch bin ich jetzt angefixt und würde trotzdem gerne die Unterschiede der erkennbaren Zustände zwischen "DeviceState" (2 gestört, 5 Problem) und den OBs 82 und 86 in Erfahrung bringen. Weiß da niemand genaueres?

Kurz und salopp: Total-Ausfall/Wiederkehr von dezentralen Stationen --> OB86, Diagnose-Meldungen (Hilfspannung fehlt, Drahtbruch) --> OB82

Die OB8x melden nur Ereignisse, wenn Ereignisse auftreten und die CPU die Ereignisse im RUN mitbekommt.
Beispiel: die CPU ist in RUN und alle dezentralen Devices sind vorhanden. Alles OK. Jetzt fällt Device A aus --> OB86 meldet das. Jetzt wird der Schrank mit der CPU ausgeschaltet und das Device A wird repariert. Allerdings vergisst der Techniker das Buskabel zu Device B wieder anzustecken. Beim nächsten Einschalten und Hochlauf der CPU ist das Device A von Anfang an wieder vorhanden, es kommt kein Ereignis was den OB86 antriggert. Dafür ist Device B von Anfang an nicht vorhanden, es kommt ebenfalls kein OB86 der einen Ausfall melden würde. Nur auf der OB86-Auswertung basierende Programme würden Device A als ausgefallen anzeigen, obwohl es OK ist, und Device B als OK anzeigen, obwohl es gar nicht vorhanden ist. Den tatsächlichen Status kann man aber jederzeit leicht mit DeviceState abfragen.

Man müsste also mindestens im Hochlauf + x Sekunden den DeviceState aller Geräte zusätzlich abfragen. Da kann man auch gleich zyklisch DeviceState abfragen und sich den ganzen Aufwand mit der OB-Auswertung sparen.

OB82-Auswertung ist noch komplizierter (und häufig sind die möglichen Ereignisse nicht vollständig dokumentiert), weil Kommen/Gehen "unsymetrisch" auftreten kann. Also mehrere kommende Störungs-Ereignisse, aber nur ein gehendes Ereignis "Alles wieder gut".

Durch ungünstiges Timing und Firmwarefehler und vielleicht auch eigene Programmfehler kommt es erfahrungsgemäß vor (selten, "hochsporadisch" ), daß mal kein OB-Aufruf kommt oder nicht richtig registriert wird. Dann zeigt die supertolle OB-Auswertung Zustände an, die nicht den tatsächlichen Zuständen entsprechen. Wie bekommt man das wieder bereinigt (am besten automatisch)?? Noch zig zusätzlichen Code programmieren, der versucht solche Fehler zu erkennen und zu umgehen? Nochmal: Da kann man auch gleich zyklisch DeviceState abfragen und sich den ganzen Aufwand mit der OB-Auswertung sparen. Das ist einfacher und sicherer.

Harald

 

[ducati]

Auch wenn ereignisgesteuert mal wieder grad hipp ist, weil es aus der viel besseren IT-Welt kommt, mit der zyklischen Bearbeitung einer SPS fährt man in der Industrieautomatisierung immer besser.

Um welche SPS gehts eigentlich? OB83 verhält sich bei 1515 anders als bei 1512SP und dezentral nochmal anders als mit zentralen Baugruppen...

OT: ich vermeide soweit es geht in meinen Programmen sogar Flanken, Setze/Rücksetze sowie Sprünge... manchmal gehts natürlich nicht ohne...

 

[ssppss]

Also erstmal vielen Dank an die letzten beiden Antworten.

Vermutlich weitgehend leere OB (höchstens Aufrufzähler oder eine Meldung generieren)? Vermutlich "weil wir das schon immer so machen", damit die CPU nicht in STOP geht, auch wenn die S7-1500 vielleicht gar nicht in STOP gehen würde.

So ungefähr. Ist ne Mischung aus vielem. Das jetzige Fehlerhandling ist etwas undurchsichtig.

Kurz und salopp: Total-Ausfall/Wiederkehr von dezentralen Stationen --> OB86, Diagnose-Meldungen (Hilfspannung fehlt, Drahtbruch) --> OB82

Die OB8x melden nur Ereignisse, wenn Ereignisse auftreten und die CPU die Ereignisse im RUN mitbekommt.
Beispiel: die CPU ist in RUN und alle dezentralen Devices sind vorhanden. Alles OK. Jetzt fällt Device A aus --> OB86 meldet das. Jetzt wird der Schrank mit der CPU ausgeschaltet und das Device A wird repariert. Allerdings vergisst der Techniker das Buskabel zu Device B wieder anzustecken. Beim nächsten Einschalten und Hochlauf der CPU ist das Device A von Anfang an wieder vorhanden, es kommt kein Ereignis was den OB86 antriggert. Dafür ist Device B von Anfang an nicht vorhanden, es kommt ebenfalls kein OB86 der einen Ausfall melden würde. Nur auf der OB86-Auswertung basierende Programme würden Device A als ausgefallen anzeigen, obwohl es OK ist, und Device B als OK anzeigen, obwohl es gar nicht vorhanden ist. Den tatsächlichen Status kann man aber jederzeit leicht mit DeviceState abfragen.

Man müsste also mindestens im Hochlauf + x Sekunden den DeviceState aller Geräte zusätzlich abfragen. Da kann man auch gleich zyklisch DeviceState abfragen und sich den ganzen Aufwand mit der OB-Auswertung sparen.

So ein Ähnliches Beispiel hatte ich auch im Kopf. Im Hochlauf würde ich so oder so ein Scan mit DeviceState durchführen.

OB82-Auswertung ist noch komplizierter (und häufig sind die möglichen Ereignisse nicht vollständig dokumentiert), weil Kommen/Gehen "unsymetrisch" auftreten kann. Also mehrere kommende Störungs-Ereignisse, aber nur ein gehendes Ereignis "Alles wieder gut".

Durch ungünstiges Timing und Firmwarefehler und vielleicht auch eigene Programmfehler kommt es erfahrungsgemäß vor (selten, "hochsporadisch" ), daß mal kein OB-Aufruf kommt oder nicht richtig registriert wird. Dann zeigt die supertolle OB-Auswertung Zustände an, die nicht den tatsächlichen Zuständen entsprechen. Wie bekommt man das wieder bereinigt (am besten automatisch)?? Noch zig zusätzlichen Code programmieren, der versucht solche Fehler zu erkennen und zu umgehen? Nochmal: Da kann man auch gleich zyklisch DeviceState abfragen und sich den ganzen Aufwand mit der OB-Auswertung sparen. Das ist einfacher und sicherer.

Harald

Das hört sich nach ziemlich viel Gefriemel an.

Um welche SPS gehts eigentlich? OB83 verhält sich bei 1515 anders als bei 1512SP und dezentral nochmal anders als mit zentralen Baugruppen...

CPU 1518F-4 PN/DP.

OT: ich vermeide soweit es geht in meinen Programmen sogar Flanken, Setze/Rücksetze sowie Sprünge... manchmal gehts natürlich nicht ohne...

Da bin ich 100% deiner Meinung. Solche Dinge gehen zwar auf die Schnelle einfacher, machen einen aber langfristig nicht glücklich.


=>
Ich mach es im Hochlauf und zyklisch. Spricht ja nun einiges dafür. Meine Ursprungsmeinung war halt, warum nicht die Dinge dafür nutzen, die speziell dafür gedacht sind. Aber zumindest bin ich anhand der Doku's stutzig geworden und bin nun doch auf dem "richtigen" Weg.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

CPU 1518F-4 PN/DP.

wenn Du zentrale Baugruppen ziehtst/steckst, geht die SPS sowieso in Stop, egal ob OB83 vorhanden ist oder nicht.

dezentral würde es nur damit gehen:

SIOS

support.industry.siemens.com

Trotzdem bin ich der Meinung, dass Du das, was Du diagnostizieren willst/musst auch mal auf dem Bürotisch ausprobierst. Sonst fällst Du auf der Baustelle auf die Nase.

 

[ssppss]

Testen werde ich das Ganze selbstverständlich, bevor es fix eingebaut wird. Meine Bedenken bei der Zyklischen Abfrage sind halt, dass das Ganze die Zykluszeit zu stark belastet. Ich will ein Profinetz abfragen. Das Netz hat ca 15 bis 20 Devices mit ca. max. 20 Modulen oder weniger (je nach Ausprägung der Maschine). D.h. da wird zyklisch ziemlich viel abgefragt. Aber das kann man ja ziemlich schnell testen. Einfach DeviceStates und ModuleStates paar mal zyklisch aufrufen und kucken, was mit der Zykluszeit passiert. Das sind eigentlich meine Hauptbedenken in meinen Vorüberlegungen.

 

[ducati]

Testen werde ich das Ganze selbstverständlich, bevor es fix eingebaut wird. Meine Bedenken bei der Zyklischen Abfrage sind halt, dass das Ganze die Zykluszeit zu stark belastet. Ich will ein Profinetz abfragen. Das Netz hat ca 15 bis 20 Devices mit ca. max. 20 Modulen oder weniger (je nach Ausprägung der Maschine). D.h. da wird zyklisch ziemlich viel abgefragt. Aber das kann man ja ziemlich schnell testen. Einfach DeviceStates und ModuleStates paar mal zyklisch aufrufen und kucken, was mit der Zykluszeit passiert. Das sind eigentlich meine Hauptbedenken in meinen Vorüberlegungen.

ich denke, die SPS hat intern die Diagnosedaten eh schon irgendwo im Speicher. Der DeviceState fragt da nicht jeden PNIO-Teilnehmer direkt nochmal an, sondern "kopiert das innerhalb der SPS nur in nen anderes Array um"

20-PNIO-Teilnehmer sind selbst für ne S7-1515 kein Problem. Es sei denn, Du brauchst undbedingt (warum auch immer) extrem kurze Zykluszeiten...

 

[ssppss]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wir haben ohne Hardware Diagnose eine Zykluszeit von ca 1,5ms. Wenn ich nun DeviceState und ModuleState für alle 5 Zustände 20 mal aufrufe, erhalte ich eine durchschn. Ausführungszeit von über 1ms für diese Anweisungen. Das halte ich für nicht sinnvoll. 50% der Zykluszeit für etwas zu "verschwenden", was nur im Fehlerfall benötigt wird.

Eigentlich wäre doch der bessere Weg, die Zustände "Störung", "vorhanden" und "Problem" nur auszuwerten, wenn die PLC CPU LED einen Fehler anzeigt (rot blinkt). Das wäre mit der Anweisung "LED" erkennbar. "konfiguriert" würde ich nur im Hochlauf abfragen. "deaktiviert" könnte man dann in jedem Zyklus abfragen oder vlt auch nur in jedem 5. oder 10. Zyklus. Aber dann wäre die Zykluszeitauslastung sicher vertretbar.

 

[PN/DP]

Also wir haben ohne Hardware Diagnose eine Zykluszeit von ca 1,5ms. Wenn ich nun DeviceState und ModuleState für alle 5 Zustände 20 mal aufrufe, erhalte ich eine durchschn. Ausführungszeit von über 1ms für diese Anweisungen. Das halte ich für nicht sinnvoll. 50% der Zykluszeit für etwas zu "verschwenden", was nur im Fehlerfall benötigt wird.

Brauchst Du denn wirklich eine so schnelle Zykluszeit für Deinen Prozess? Sind nicht 10..20 ms auch noch völlig ausreichend schnell?
Weißt Du eigentlich, wie sehr die Zykluszeit hochgeht, wenn Du einfach nur mit TIA online gehst?

Eigentlich wäre doch der bessere Weg, die Zustände "Störung", "vorhanden" und "Problem" nur auszuwerten, wenn die PLC CPU LED einen Fehler anzeigt (rot blinkt).

Die LEDs sind aber Sammel-Fehler-LEDs. Sobald die leuchten, müsstest Du zyklisch für ALLE Geräte DeviceState aufrufen, weil man ja nicht sehen kann wieviele Geräte Probleme haben, ob welche dazukommen oder gehen. Dann würde bei einem Problem von nur einem Gerät schlagartig die Zykluszeit auf das Doppelte hochgehen. Da wäre mir eine gleichmäßig hohe Zykluszeit von 5ms viel lieber als eine Zykluszeit von 1,5ms im Idealfall mit unvorhersehbaren "Überraschungen". Falls die 5ms schon problematisch hoch sind, dann fällt das gleich auf und nicht erst, wenn zufällig bestimmte Sachen gleichzeitig auftreten, die einzeln mit dem Problem eigentlich gar nichts zu tun haben.

Harald

 

[ducati]

Also wir haben ohne Hardware Diagnose eine Zykluszeit von ca 1,5ms. Wenn ich nun DeviceState und ModuleState für alle 5 Zustände 20 mal aufrufe, erhalte ich eine durchschn. Ausführungszeit von über 1ms für diese Anweisungen. Das halte ich für nicht sinnvoll. 50% der Zykluszeit für etwas zu "verschwenden", was nur im Fehlerfall benötigt wird.

Also ich hab bei verschiedenen Anlagen ne Zykluszeit von 100ms. Da verschwende ich nur 1%

 

[DOD666]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir stellen normal auf 10ms mindestzykluszeit. Ich deaktivieren das nur um zu sehen ob ich ggf. dicht dran bin. Mit der Zeit haben wir einen sehr stabilen Zyklus.

 

[Oberchefe]

Wenn ich nun DeviceState und ModuleState für alle 5 Zustände 20 mal aufrufe, erhalte ich eine durchschn. Ausführungszeit von über 1ms für diese Anweisungen.

Evtl. ist es auch eine Lösung, im OB1(bzw. im davon entsprechend aufgerufenen Baustein) eine Variable hochzuzählen und jedes Gerät nur bei einem bestimmten Variablenwert abzufragen(Variable beim letzten Gerät natürlich wieder auf Anfang setzen). Das reduziert die Ausführungszeit pro Zyklus und verlangsamt die gesamte Überprüfung nur etwas. Ein Ausfall und Wiederkehr dauert Erfahrungsgemäß länger als die 20 ms.

 

[ducati]

Evtl. ist es auch eine Lösung, im OB1(bzw. im davon entsprechend aufgerufenen Baustein) eine Variable hochzuzählen und jedes Gerät nur bei einem bestimmten Variablenwert abzufragen(Variable beim letzten Gerät natürlich wieder auf Anfang setzen). Das reduziert die Ausführungszeit pro Zyklus und verlangsamt die gesamte Überprüfung nur etwas. Ein Ausfall und Wiederkehr dauert Erfahrungsgemäß länger als die 20 ms.

Kommt halt immer drauf an, was man machen will... Ich hatte mal nen Kunden, der wollte z.B. mit der Diagnose einer fehlerhaften DI-Karte alle drahtbruchsicheren Meldungen unterdrücken. Da brauchst dann die Diagnose im selben Zyklus oder musst alle Störungen verzögern...