TIA Fehler quittieren funktioniert nicht

S

Saufautomat

Level-1
Beiträge
38
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo allerseits,

ich habe hier eine Anlage mit S7-300 und TP1200 Basic Panel. Durch einen Druckluftausfall wurde ein Fehler ausgelöst und lässt sich nicht mehr quittieren obwohl wieder Druckluft da ist.

1668683103584.png
Ich bin kein blutiger Anfänger mehr aber weiter komme ich gerade nicht. Wenn ich auf quittieren drücke erwarte ich, dass Tag_25 den Fehler zurücksetzt. Tag_25 wird aber nicht gesetzt.
(E_AIR_P sollte besser E_AIR_P_ok heißen)
1668683048832.png

Im HMI scheint es korrekt verknüpft zu sein:
1668683298948.png

Wenn ich den Merker in der Variablentabelle beobachte und die Quittieren-Taste gedrückt halte bleibt der Wert 0. Ich finde auch keine Querverweise, die daraufhin deuten, dass der Wert an anderer Stelle überschrieben wird.

Wo liegt der Fehler? Ich fürchte es ist etwas Einfaches oder ich verstehe das Meldesystem falsch^^ Vielen Dank schonmal
 
Und wie wird TAG_25 gesetzt ? Hast Du einen Button dafür gemacht?
Weil über den Quittierbutton an deiner Fehleranzeige passiert dies nicht.

Grüße

Marcel
 
1668684851637.png
Damit beim Setzen des zugeordneten Quittierbits einer quittierpflichtigen Bitmeldung immer ein Signalwechsel erzeugt wird, setzt das Bediengerät, sobald eine quittierpflichtige Meldung erkannt wurde, das der Meldung zugeordnete Quittierbit zurück und schreibt die Quittiervariable in die Steuerung.

Wenn eine quittierpflichtige Bitmeldung am Bediengerät quittiert wird, wird das entsprechende Bit in der zugeordneten Quittiervariablen gesetzt. Die gesamte Quittiervariable wird dann vom Bediengerät in die Steuerung geschrieben. Damit kann die Steuerung erkennen, dass eine bestimmte Störmeldung am Bediengerät quittiert wurde.
Zum Vergrößern anklicken....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Komischerweise ist die Anlage schon einige Jahre alt und es gab keine Probleme, die mir bekannt wären.

Es gibt keinen extra Quittier-Button auf dem HMI. Vielleicht am Schaltkasten. Ich kann nur aus der Ferne darauf schauen aber kläre das mal.

Danke für den Hinweis mit der Quittierung HMI/PLC:
1668684958404.png
Verstehe nur nicht, warum dann in der Steuerung mit Qvar2 gearbeitet wurde.
 
Du kannst ja mal probieren den Merker M127.3 am Anfang des OB1 zu setzen. Dann weißt du ob dieser vom Programm zurückgesetzt wird, wenn das RS-Glied nicht zurückgesetzt wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Watchcat schrieb:
Du kannst ja mal probieren den Merker M127.3 am Anfang des OB1 zu setzen. Dann weißt du ob dieser vom Programm zurückgesetzt wird, wenn das RS-Glied nicht zurückgesetzt wird.
Zum Vergrößern anklicken....
Habe ich ausprobiert und es wurde nicht überschrieben, zumindest in dem Programmteil.

Den Fehler bin ich schon näher. Tatsächlich sitzt manchmal der Fehler vor dem PC. Qvar2 wurde doch potentiell überschrieben in Netzwerk 49, also nach den oben gezeigten:
1668686424518.png
Nachstellen kann ich den Fehler aber gerade nicht. Wenn ich jetzt quittiere verschwindet die Meldung wie sie es auch sollte:unsure:
 
Ich kann den Fehler nicht nachvollziehen und nicht nachstellen.
Wenn ich den Druckluftabfall simuliere und quittiere wenn die Druckluft weg ist oder schon wieder da ist lässt sich der Fehler quittieren. So wie es sein sollte.
Dass der Programmierer das Quittierwort zurücksetzt wenn das Triggerwort gleich 0 ist, ist ja auch nicht verkehrt?
 
Wenn der Merker M127.3 erst zurückgesetzt wird, nachdem er gelesen wurde, kann er ja trotzdem TRUE sein in NW15.
HMI-Variablen werden immer am Zyklusanfang gelesen bzw. geschrieben.
 
Watchcat schrieb:
Wenn der Merker M127.3 erst zurückgesetzt wird, nachdem er gelesen wurde, kann er ja trotzdem TRUE sein in NW15.
HMI-Variablen werden immer am Zyklusanfang gelesen bzw. geschrieben.
Zum Vergrößern anklicken....

Stimmt bei 1200/1500er nicht und kann man auch gut ausprobieren die gleiche Variable mehrfach im Zyklus verwendet.

Für reproduzierbare Ereignisse ist es meiner Meinung nach daher wichtig, die Variable nur einmal zu verwenden und bei Bedarf auf eine SPS-Variable zu kopieren und dann mit dieser mehrfach zu arbeiten, wenn man dies benötigt. Ansonsten können komische Effekte auftreten, die sich keiner erklären kann.
 
Störmeldungen die 'unerklärlich' nicht quittierbar sind könnte sein, weil das Störmeldebit sofort wieder gesezt wird wenn das Quittierbit gesetzt wird.
Also, die HMI sieht nicht dass das Störmeldebit auf OFF geht bevor es wieder auf ON geht da die HMI Variabeln viel langsahmer aktualisiert werden als der SPS das Program durchläuft. .
Dann 'denkt' die HMI dass die Fehler gesetzt und quittiert ist, nicht wie in die Realität dass eine neue Störmeldung angestossen wurde, und das Quittierbit zurückgesetz werden muss damit dass man die Störmeldung erneut quittieren kann.
Dies ist eine bekannte Problematik bei die bit-Meldungen. War schon so bei Protool und WinCC Flexible.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
JesperMP schrieb:
Störmeldungen die 'unerklärlich' nicht quittierbar sind könnte sein, weil das Störmeldebit sofort wieder gesezt wird wenn das Quittierbit gesetzt wird.
Also, die HMI sieht nicht dass das Störmeldebit auf OFF geht bevor es wieder auf ON geht da die HMI Variabeln viel langsahmer aktualisiert werden als der SPS das Program durchläuft. .
Dann 'denkt' die HMI dass die Fehler gesetzt und quittiert ist, nicht wie in die Realität dass eine neue Störmeldung angestossen wurde, und das Quittierbit zurückgesetz werden muss damit dass man die Störmeldung erneut quittieren kann.
Dies ist eine bekannte Problematik bei die bit-Meldungen. War schon so bei Protool und WinCC Flexible.
Zum Vergrößern anklicken....
Ich habe ebenfalls die Erfahrung gemacht, daß sich die Quittierbit-Kommunikation vom HMI-Panel manchmal verschluckt. ;)
Deshalb lösche ich das HMI-Quittierbit in der SPS wenn eine Meldung neu kommt. (Ich mache das gleich Wordweise, siehe z.B. hier, da habe ich nicht wieder davon gehört, daß das Problem noch auftritt)


Saufautomat schrieb:
Qvar2 wurde doch potentiell überschrieben in Netzwerk 49, also nach den oben gezeigten:
Anhang anzeigen 65020
Nachstellen kann ich den Fehler aber gerade nicht. Wenn ich jetzt quittiere verschwindet die Meldung wie sie es auch sollte:unsure:
Zum Vergrößern anklicken....
Hier scheint der Programmierer auch von dieser Problematik gewusst zu haben, allerdings ist diese "faule" Variante des Rücksetzens der HMI-Quittierbits in der SPS falsch programmiert und funktioniert nicht immer. Wenn in der Triggervariable MW122 noch eine weitere Meldung ansteht, dann werden die HMI-Quittierbits in MW126 nicht gelöscht, und wenn eine Meldung das nächste mal kommt, dann wird in jedem Programmdurchlauf das Meldebit/Triggerbit rückgesetzt und gleich wieder gesetzt (wenn die Meldungsursache noch ansteht), solange bis das HMI-Panel das HMI-Quittierbit löscht. Die HMI-Kommunikation dauert natürlich länger als die Zykluszeit der SPS. Und so lange besteht die Chance, daß sich das HMI-Panel sporadisch verschluckt.

Tipp: Ich würde noch eine Funktion "Alle Meldungen löschen" einbauen, z.B. über eine Schaltfläche am HMI-Panel, besser auf eine
Hardware-Taste oder Tastenkombination legen. Für den Fall, daß durch (Tipp-)Fehler im Programm ;) oder Defekt des HMI-Panels
oder HMI-Kommunikationsprobleme ein Meldebit ewig gesetzt bleibt (so wie bei Dir). Dazu alle Meldebits rücksetzen (auf 0 schreiben).

Harald
 
PN/DP schrieb:
Ich habe ebenfalls die Erfahrung gemacht, daß sich die Quittierbit-Kommunikation vom HMI-Panel manchmal verschluckt. ;)
Deshalb lösche ich das HMI-Quittierbit in der SPS wenn eine Meldung neu kommt. (Ich mache das gleich Wordweise, siehe z.B. hier, da habe ich nicht wieder davon gehört, daß das Problem noch auftritt)
Zum Vergrößern anklicken....
Meiner Verständniss ist: Es gibt pro Meldung ein HMI-interne Variabel welche den Zustand "quitiert" speichert. Man sieht es nur in die Meldeanzeige damit dass die quitterte Meldungen grau angezeigt werden, und mit das "IX" markiert sind für "angekommen und quittiert".
Nur wenn die HMI sieht dass das Störmeldebit auf OFF geht wird diese interne "quitiert" Zustandsbit zurückgesezt.
Das HMI quittier-bit wird von die HMI meines Wissens nicht lesend verwendet.

Wenn die Abhilfe die du beschrebst helfen wurde, dann wurde es mein Verständniss zerstören.

PN/DP schrieb:
Tipp: Ich würde noch eine Funktion "Alle Meldungen löschen" einbauen, z.B. über eine Schaltfläche am HMI-Panel, besser auf eine
Hardware-Taste oder Tastenkombination legen. Für den Fall, daß durch (Tipp-)Fehler im Programm ;) oder Defekt des HMI-Panels
oder HMI-Kommunikationsprobleme ein Meldebit ewig gesetzt bleibt (so wie bei Dir).
Zum Vergrößern anklicken....
+1
PN/DP schrieb:
Dazu alle Meldebits rücksetzen (auf 0 schreiben).
Zum Vergrößern anklicken....
Ich setze auch die SPS-quittierbits auf 1 und nach wenige Sekunden wieder auf 0.
Damit werden die Meldungen in die HMI auch quittiert und gelöscht.
 
Vielen Dank für die vielen Antworten. Aktuell habe ich leider keinen Zugriff auf die Anlage. Den Vorschlag von Harald mit "Alle Meldungen löschen" werde ich als Erstes umsetzen, damit die Anlage bedienbar gemacht werden kann.

Die Ursache des Problems habe ich ehrlich gesagt noch nicht verstanden. Dafür muss ich mal mit der Anlage spielen. Vielleicht muss wie oben erwähnt auch ein zweiter Fehler anlegen, um dieses Problem zu verursachen. Angeblich hat mehrmaliges Neustarten der Anlage mit anliegendem Druck den Fehler nicht verschwinden lassen. D.h. für mich, dass dieser Merkerbereich remanent ist (kann ich offline nicht kontrollieren) oder das HMI diesen Fehler triggern muss.

Ich werde hier ein Update nachreichen wenn ich getestet habe.
 

Similar threads

W
simatic baustein sfc 84. fehler wegen testfunktion
Antworten
10
Aufrufe
8K
OHGN
OHGN
Zurück
Oben