Step 7 ASI-Fehler erkennen

Tigerente1974 · 4 April 2019

Hallo Forum.

Ich habe ein Problem mit einer älteren Anlage.
Dort ist eine S7-315-2 PN/DP mit einem ASI-Master 342-2 (6GK7 342-2AH01-0XA0) eingesetzt.

Seit einigen Wochen kommt sporadisch ein Fehler vom ASI-Master (Adresse 256...271).
Im Diagnosepuffer der SPS sieht man, dass der Fehler nur ganz kurz da ist:

Ereignis 1 von 10: Ereignis-ID 16# 3842
Baugruppe ok Baugruppentyp: Kommunikationsprozessor
Eingangsadresse: 256
Kanalinformation vorhanden Angeforderter OB: Diagnosealarm-OB (OB 82)
Prioritätsklasse: 26
externer Fehler, gehendes Ereignis
05:20:08.931 04.04.2019
(Kodierung: 16# 3842 1A52 C554 0100 001C 0000)

Ereignis 2 von 10: Ereignis-ID 16# 3942
Baugruppe gestört oder Wartung erforderlich
Baugruppentyp: Kommunikationsprozessor
Eingangsadresse: 256 Modul falsch/fehlt Kanalinformation vorhanden
Modul/Submodul gestört
Fehler baugruppenextern
Kanalfehler vorhanden Angeforderter OB: Diagnosealarm-OB (OB 82)
Prioritätsklasse: 26
externer Fehler, kommendes Ereignis
05:20:08.785 04.04.2019
(Kodierung: 16# 3942 1A52 C554 0100 0D1C 0100)

Im OB82 steht folgender Code:

Code:

      L     #OB82_MDL_ADDR
      T     DB59.DBW    0
      SET   
      =     M    212.0
loop: NOP   0
      CALL  SFC   59
       REQ    :=M212.0
       IOID   :=B#16#54
       LADDR  :=DB59.DBW0
       RECNUM :=B#16#1
       RET_VAL:=DB59.DBW2
       BUSY   :=M212.1
       RECORD :=P#DB59.DBX10.0 BYTE 11
      CLR   
      =     M    212.0
      U     M    212.1
      SPB   loop

      U     #OB82_MDL_DEFECT
      S     M    200.4

Zur Auswertung des betroffenen Moduls werden die Bytes aus dem DB59 in Meldewörter rangiert.
Ich weiß, dass der Zugriff auf die ungeraden Wortadressen nicht schön ist. Der Code wurde damals von den Kollegen in zig Anlagen kopiert und scheint zu funktionieren.
Deswegen hab ich da nichts dran geändert.

Code:

      L     DB59.DBW   17
      L     W#16#0
      <>I   
      SPBN  m001
      T     DB240.DBW    2

m001: L     DB59.DBW   19
      L     W#16#0
      <>I   
      SPBN  m002
      T     DB240.DBW    4

m002: NOP   0

      U     DB612.DBX    1.7  // Quittiertaste
      SPBN  m003
      L     W#16#0
      T     DB59.DBW   17
      T     DB59.DBW   19
      T     DB240.DBW    2
      T     DB240.DBW    4

m003: NOP   0

Wenn ein ASI-Slave abgezogen wird, geht das entsprechende Bit im Bereich DB59.DBB17 ff. an und am HMI kommt die passende Fehlermeldung.

Bei der sporadischen Störung wird nur der M200.4 (#OB82_MDL_DEFECT) gesetzt. Es wird jedoch kein Slave mit angegeben.
Laut Siemens-Handbuch tritt ein Alarmereignis mit "externem Fehler" bei Änderungen der AS-i-Slavekonfiguration auf. Der Master ist im geschützten Betrieb.
Müsste da nicht auch ein Slave mit angegeben werden?
Eine 2. Möglichkeit wäre AS-i-Powerfail. Wenn man die ASi-Spannung kurz abklemmt, werden direkt alle Slaves als Fehler mit angegeben. Das passiert aber auch nicht bei dem sporadischen Fehler.

Anbei noch die Online-Ansicht des DB59.

Welche Möglichkeiten zur Diagnose habe ich noch?
Kann man aus der "Kodierung" im Diagnosepuffer nähere Informationen bekommen?
Was kommt noch als Ursache in Betracht?

Gruß

Chris

Tigerente1974 · 9 April 2019

Hat jemand noch eine Idee?
Kann ich im OB82 noch etwas an der Auswertung machen?

Clyde82 · 11 April 2019

Guck dir mal SFC 59 an. Ich hab mal was ähnliches aufgebaut nur ging es dabei um die Diagnose aller Teilnehmer an einem PA-Strang. Wenn du SFC 59 auf deinen AS-I Link anwendest erhälst du kurz gesagt 2 Sachen:

- Informationen über Teilnehmer die Diagnosedaten liefern
- Informationen über Teilnehmer die im Datenaustausch mit Master stehen (eine Art Hallo ich bin da Liste)-> hier könntest du z.B. gucken ob ein Teilnehmer sich mal abmeldet

Nachtrag:

Ich hab das damals so gemacht:

- mit dem SFC 59 geguckt ist ein Teilnehmer weg / fehlerhaft
- Wenn ja führe SFC 51 für diesen Teilnehmer aus

Was dein Kollege macht, wenn ein Teilnehmer einen Fehler meldet, iteriere durch alle Teilnehmer und guck welcher weg ist. Es könnte natürlich sein, dass das iterieren so lange dauert, dass der fehlerhafte Teilnehmer wieder da ist bis die Schleife bei ihm angekommen ist.

Tigerente1974 · 12 April 2019

Hallo Clyde,

danke für die Antwort.
Ich habe in der gleichen Richtung gedacht und den Code noch wie folgt geändert:

Code:

      L     #OB82_EV_CLASS
      L     B#16#39
      ==I   
      SPBN  M001

      L     B#16#0
      T     DB58.DBB    0
      T     "Auswertung OB82".OB82_MDL_TYPE
      T     DB58.DBB    2
      T     DB58.DBB    3
      T     "Auswertung OB82".DS1_BYTE_4
      T     "Auswertung OB82".DS1_BYTE_5
      T     "Auswertung OB82".DS1_BYTE_6
      T     "Auswertung OB82".DS1_Delatliste_0
      T     "Auswertung OB82".DS1_Delatliste_1
      T     "Auswertung OB82".DS1_Delatliste_2
      T     "Auswertung OB82".DS1_Delatliste_3

      L     #OB82_MDL_ADDR
      T     #t_laddr
      SET   
      =     #t_req

M002: NOP   0

      CALL  "RD_REC"
       REQ    :=#t_req
       IOID   :=B#16#54
       LADDR  :=#t_laddr
       RECNUM :=B#16#1
       RET_VAL:=#t_return
       BUSY   :=#t_busy
       RECORD :=P#DB58.DBX0.0 BYTE 11

      U     #t_busy
      R     #t_req
      SPB   M002

M001: NOP   0

Weil der Fehler nur ganz kurz da war, wurde das Bit offenbar direkt wieder abgelöscht, als der OB82 erneut aufgerufen wurde.
So war das Bit schon wieder aus, als der normale Programmablauf an die Stelle kam, wo die Auswertung erfolgte.
Durch die Abfrage auf einen kommenden Fehler (#OB82_EV_CLASS = B#16#39) habe ich das verhindert und siehe da, es wurde ein Bit in der Deltaliste eingetragen.

Clyde82 · 12 April 2019

Moin,

supi - dann kannste ja gucken warum er weggeht.

Step 7 ASI-Fehler erkennen

Tigerente1974

Level-3

Anhänge

Tigerente1974

Level-3

Clyde82

Level-1

Tigerente1974

Level-3

Clyde82

Level-1

Similar threads

Wir schützen deine Privatsphäre