TIA OB83/OB86 stoppen die PLC

[Fabster]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Miteinander,

Erstmal das Setting ganz fix:

• PLC: CPU 1514SP-2 PN
• I/O-Module an einem IM: IM 155-6 PN ST
• verbunden über Profinet

Mein gesamtes Programm soll (kann schon):

• MQTT Nachrichten über die I/Os onChange verschicken ()
• MQTT Nachrichten empfangen und darauf reagieren ()

Die MQTT Nachrichten werden wie folgt erstellt:

• JSON Tree wird erstellt
• mit LStream_JsonSerializer wird aus dem JSON_tree ein Byte Array erstellt
• dieses Byte Array wird mit dem LMQTT_Client an den Broker verschickt

Mein Problem:

• Den Ausfall eines I-O-Moduls/des ganzen IM-Moduls festzustellen
• sobald dieser Auftritt eine MQTT Nachricht mit Infos dazu verschicken
• aktuell werden mit OB86 und OB83 die zwei Fälle abgefangen und es wird in den JSON_Tree geschrieben (über einen DB)
• PROBLEM: Die CPU geht in Stopp sobald ein Modul/IM abgezogen wird
  • am IM Modul: RN-LED (gelb) blinkt und ER-LED (rot) blinkt
  • an der CPU: R/S-LED (gelb) leuchtet und ER-LED (rot) blinkt
• Sobald der Fehler behoben wird (wieder angesteckt) ist alles wieder zurück zu normal
• Die MQTT Nachricht über den Fehler wird versendet
  • Diese Nachricht soll aber sofort bei Ausfall versendet werden

Ich hoffe jemand kann mir helfen!

Vielen Dank im Voraus
Fabi

P.S.: Diagnose im Anhang

 

[PN/DP]

• PROBLEM: Die CPU geht in Stopp sobald ein Modul/IM abgezogen wird
  • am IM Modul: RN-LED (gelb) blinkt und ER-LED (rot) blinkt
  • an der CPU: R/S-LED (gelb) leuchtet und ER-LED (rot) blinkt

Ist in dem gezeigten Diagnosepuffer geht die CPU nirgends in STOP wegen Teilnehmer-Ausfall. Da spielt nur jemand mit dem STOP-Schalter der CPU oder sendet STOP-Befehle mit PG?
Mit "R/S-LED" meinst du die RUN/STOP-LED?
Wann ist das Problem das letzte mal aufgetreten? Wieviele Tage ist das her? Müssen wir den Diagnosepuffer bis zurück zur Erstinbetriebnahme zurückverfolgen? Kannst du jetzt mal das Problem auslösen und den Diagnosepuffer zeigen?
Auf welchem Weg soll die SPS die Nachricht verschicken? Über die unterbrochenen Netzwerkkabel?

• Sobald der Fehler behoben wird (wieder angesteckt) ist alles wieder zurück zu normal
• Die MQTT Nachricht über den Fehler wird versendet
  • Diese Nachricht soll aber sofort bei Ausfall versendet werden

Wie geht die CPU aus dem STOP wieder nach RUN? Doch bestimmt nicht nur durch anstecken des Netzwerkkabels?

 

[Fabster]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist in dem gezeigten Diagnosepuffer geht die CPU nirgends in STOP wegen Teilnehmer-Ausfall. Da spielt nur jemand mit dem STOP-Schalter der CPU oder sendet STOP-Befehle mit PG?
Mit "R/S-LED" meinst du die RUN/STOP-LED?
Wann ist das Problem das letzte mal aufgetreten? Wieviele Tage ist das her? Müssen wir den Diagnosepuffer bis zurück zur Erstinbetriebnahme zurückverfolgen? Kannst du jetzt mal das Problem auslösen und den Diagnosepuffer zeigen?
Auf welchem Weg soll die SPS die Nachricht verschicken? Über die unterbrochenen Netzwerkkabel?


Wie geht die CPU aus dem STOP wieder nach RUN? Doch bestimmt nicht nur durch anstecken des Netzwerkkabels?

Sorry für die fehlenden Infos:
Es spielt niemand mit dem Stop-Schalter, das war falsch ausgedrückt, sorry, sie geht nicht in den Stop Modus.
Das Problem ist sobald ich entweder das Ethernet Kabel abziehe (zw. CPU und IM) oder ein I/O Modul abziehe (am IM) soll der Fehler (über ein weiteres Ethernet Kabel) per MQTT versendet werden. Allerdings wird diese Nachricht nicht direkt versendet, sondern nur wenn ich das jeweilige Modul wieder anstecke.
Ja die Run/Stop-LED.
Ich kann das Problem auslösen wann ich will indem ich das Kabel oder das IO Modul abziehe. Ich muss für die Entwicklung des Systems diesen Fall abfangen und eine Nachricht per MQTT absetzen. Im Diagnosepuffer ist das Problem mehrfach drin.

6 von 532; Ereignis-ID: 16# 02:3951
Fehler: Hardware-Komponente wurde entfernt oder fehlt

IO-Device_1 / DI 8x24VDC BA_1


Gehendes Ereignis
Ereignistyp: OK
10.06.2024 09:54:01.671
(Kodierung: 16# 20 00 00 03 17 D7 95 64 7B D1 EA 30 39 51 00 00 38 51 00 00 00 00 01 0E 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)


7 von 532; Ereignis-ID: 16# 02:3951
Fehler: Hardware-Komponente wurde entfernt oder fehlt

IO-Device_1 / DI 8x24VDC BA_1


Kommendes Ereignis
Ereignistyp: Fehler
10.06.2024 09:53:46.149
(Kodierung: 16# 20 01 00 03 17 D7 95 60 DE 9C 54 40 39 51 00 00 00 00 00 00 00 00 01 0E 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)

 

[PN/DP]

Rufen die Ereignisse nicht OB86 oder OB83 auf? Du müsstest in den OB das Senden der Nachricht anstoßen, insbesondere beim "Kommen"-Ereignis.

 

[Fabster]

Ja das tun die Ereignisse auch, in diesen schreibe ich die Infos des Errors in einen DB, das versenden habe ich jetzt auch mit in die OBs genommen (bin da warum auch immer nicht selbst drauf gekommen, Danke für den Tipp!) Funktioniert für das abziehen einer IO Karte blendend (also OB83) leider jedoch nicht für das abziehen des Kabels (also Trennung CPU zu IM Modul, OB 86), hier wird zwar auch in einen DB geschrieben, aber es wird nur beim wieder anstecken des Kabels die Nachricht versendet.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die OB8x werden nur einmalig bei einem Ereignis aufgerufen. Da kann man nichts länger dauerndes programmieren. Da kann man nur die Begleitinfos vom OB sichern (in DB umkopieren) und das Senden anstoßen (z.B. ein "Merker"-Bit setzen oder irgendeine Info in eine Variable schreiben). Das Senden musst du im OB1 programmieren, wenn das Bit gesetzt ist.

 

[Fabster]

Genau dieses mache ich in den OB8x, ich schreibe die Infos in einen DB und stoße das senden an welches in OB1 ist, das habe ich in beiden OB8x jedoch funtioeniert es bei OB83 jetzt aber bei OB86 nicht.