# Diagnosealarm im OB82 auswerten?



## anne (22 Juni 2010)

Hi Ihr, 

ich verstehe nicht so ganz, was bei dem SIWAREX-Modul ausgewertet werden soll - könnt ihr mir da etwas helfen? Das Beispiel ist von Siemens!

OB82/NW1:


```
// *** Diagnosealarm von Baugruppe mit Adresse 298 ? ***
      L     #OB82_MDL_ADDR              // Baugruppenadresse der Baugruppe, die Alarm auslöst
      L     298                         // SIWAREX U mit Anfangsadresse 298
      ==I                               // ja,
      SPB   N200                        // dann Alarm auswerten
      BEB
```
 

OB82/NW2:


```
N200: NOP   0
      L     #OB82_EV_CLASS              // prüfen, ob Fehler "kommend"
      L     B#16#39                     // "39" heißt Fehler "kommend"
      ==I   
      SPB   A001                        // Fehler "kommend" gemeldet
      SPA   A002                        // Fehler "gehend" gemeldet
```
 

OB82/NW3:


```
A001: L     'JA '
      T     MD    90
      BEB
```
 

OB82/NW4:


```
A002: L     'NEIN'
      T     MD    90
```
 

1) NW1 ist klaro!

2) In NW2 wird offensichtlich geprüft, ob der Fehler kommend oder gehend ist - wofür das?

3) In NW3/4 wird 'JA' bzw. 'NEIN' in ein Merkerdoppelwort geladen - so etwas hab' ich noch nie gesehen... ist das siemensspezifisch und was steht denn dann in dem MD - dort kann doch nicht JA oder NEIN stehen? 

Lieben Dank, bin hier grad völlig überfordert...


----------



## Verpolt (22 Juni 2010)

Hallo,


   L     B#16#39                     // Kommendes Ereignis

   L     B#16#38                     // Gehendes Ereignis

Mit einem kommenden Ereigniss darauf reagieren.
Mit einem gehenden Ereigniss zu Überprüfung oder ähnliches auswerten

zB.: Kommendes Ereignis --Setze Fehler
nach Quittierung der Störung und....
Prüfen auf gehendes Ereignis-->Reset Fehler

`ja` soll ein CHAR sein  (Text)

MD 90  --Deklaration (4 byte = 4 char

also 

MB90 = J oder N
MB91 = A oder E
MB92 =    oder I
MB93 =    oder N


Grüße


----------



## anne (22 Juni 2010)

Vielen Dank schon mal Verpolt!

Hm, also wird dann im Grunde das MD90 ausgewertet - wenn also z.B. 'JA' im MD steht, liegt ein kommendes Ereignis vor. 

Ein kommendes Ereignis könnte ja z.B. ein _Fehler_ vom SIWAREX-Modul sein; heißt das dann, dass sich bei einem Fehle *automatisch* dieses 'JA' in das MD90 einträgt?


----------



## Verpolt (22 Juni 2010)

> heißt das dann, dass sich bei einem Fehle automatisch dieses 'JA' in das MD90 einträgt?



Mit diesem Beispiel oben  *ACK*  ja


----------



## anne (22 Juni 2010)

Gut, vielen Dank... dann bin ich schon ein Stück weiter... 

Also angenommen, es tritt ein Fehler am SIWAREX-Modul auf und es wird daraufhin automatisch dieses 'JA' in das MD eingetragen:

- reagiert dann der OB82 und unterbricht den Zyklus oder

- muss ich selbst das MD90 auswerten?

Sorry für die doofen Fragen...


----------



## Verpolt (22 Juni 2010)

Der OB82 Aufruf ist schon eine Unterbrechung des Zyklus.

Wenn der nicht da ist , geht CPU in Stop.

Was dort verarbeitet wird, mußt Du entscheiden.

Anbei ein Beispiel mit OB86 :

Diese Störmerker verwende ich im Programm für Störmeldungen--Ausfunktionen...


----------



## anne (22 Juni 2010)

Ja ok, aber in dem Siemens-Beispiel müsste im OB82 im Grunde *nichts *mehr hinzugefügt werden, damit der Zyklus bei einem *Fehler* unterbrochen wird - d.h. die Unterbrechung würde auch mit dem momentanen Code (NW1-4) stattfinden?

Habe mal dieses 'JA' in ein MD geladen:

Dann steht im MD (Anzeigeformat = Zeichen) unter Statuswert *DW#16#00004A41*. Stimmt das echt?


----------



## Verpolt (22 Juni 2010)

> Ja ok, aber in dem Siemens-Beispiel müsste im OB82 im Grunde nichts mehr hinzugefügt werden, damit der Zyklus bei einem Fehler unterbrochen wird - d.h. die Unterbrechung würde auch mit dem momentanen Code (NW1-4) stattfinden?



Ja, richtig



> Dann steht im MD (Anzeigeformat = Zeichen) unter Statuswert DW#16#00004A41. Stimmt das echt?



in deiner Vat nicht MD eintragen, sondern auflösen

MB90
MB91
MB92
MB93

Anzeigeformat = "Zeichen"/"char" definieren


Grüße


----------



## anne (22 Juni 2010)

Verpolt schrieb:


> Der OB82 Aufruf ist schon eine Unterbrechung des Zyklus.
> 
> Wenn der nicht da ist , geht CPU in Stop.
> 
> Grüße


 
Aber der ist doch nur da, wenn ich ihn auch explizit in den Bausteinordner lade...
Wenn ich den OB82 nicht benötige, dann muss er doch auch nicht in die SPS geladen werden und dann geht die doch auch nicht in Stop.

Oder verstehe ich da jetzt was falsch?

Lieben Dank!


----------



## Verpolt (22 Juni 2010)

> Aber der ist doch nur da, wenn ich ihn auch explizit in den Bausteinordner lade...
> Wenn ich den OB82 nicht benötige, dann muss er doch auch nicht in die SPS geladen werden und dann geht die doch auch nicht in Stop.




Wenn er NICHT da ist, geht die CPU in Stop.

Wenn er da ist, Programm rein, auswerten, reagieren-->CPU (Anlage) läuft weiter



> Beschreibung
> 
> Wenn eine diagnosefähige Baugruppe, bei der Sie den Diagnosealarm freigegeben haben, eine Änderung ihres Diagnosezustands erkennt, stellt sie eine Diagnosealarmanforderung an die CPU:
> 
> ...




Grüße und F1 auf OB82


----------



## anne (22 Juni 2010)

Ja ok,

dann muss aber explizit der Diagnosealarm in der Baugruppe *freigegeben* werden... sonst muss der entsprechende OB *nicht *in die SPS geladen werden, oder?

Und es müsste ja auch schon reichen, dass der entsprechende OB vorhanden ist, auch wenn er keinen Programmcode besitzt?


----------



## Verpolt (22 Juni 2010)

> dann muss aber explizit der Diagnosealarm in der Baugruppe freigegeben werden... sonst muss der entsprechende OB nicht in die SPS geladen werden, oder?



Normal geht CPU in Stop, wenn der entsprechende OB nicht geladen ist.



> nd es müsste ja auch schon reichen, dass der entsprechende OB vorhanden ist, auch wenn er keinen Programmcode besitzt?



ja *ACK*


----------



## anne (22 Juni 2010)

Verpolt schrieb:


> Normal geht CPU in Stop, wenn der entsprechende OB nicht geladen ist.


 
Auch wenn der Diagnosealarm der entspr. Baugruppe *deaktiviert* ist?

Vielen dank Verpolt!


----------



## Verpolt (22 Juni 2010)

> Beschreibung
> 
> Wenn eine diagnosefähige Baugruppe, _*bei der Sie den Diagnosealarm freigegeben haben*_, eine Änderung ihres Diagnosezustands erkennt, stellt sie eine Diagnosealarmanforderung an die CPU:
> 
> ...



Hab ich noch nie gesperrt. Möchte immer eine Diagnose haben.


----------



## petzi (22 Juni 2010)

Hallo,

wie wäre es denn eigentlich, wenn ich *zwei getrennte* SIWAREX-Module einsetze?

Den OB82 brauche ich doch trotzdem nur* einmal*. Kann dann das NW1-4 im gleichen OB82 einfach noch einmal programmiert werden; nur halt beim zweiten Mal mit einem anderen Merkerdoppelwort, oder wie macht man das dann?

Vielen Dank.


----------



## Verpolt (22 Juni 2010)

Das ganze auf eine andere Anfangsadresse abfragen


```
// *** Diagnosealarm von Baugruppe mit Adresse 298 ? ***
      L     #OB82_MDL_ADDR              // Baugruppenadresse der Baugruppe, die Alarm auslöst
      L     298                         // SIWAREX U mit Anfangsadresse 298
      ==I                               // ja,
      SPB  N200                  // dann Alarm auswerten
      BEB
```

und jetzt als Bspl.: 256 (Anfangsadresse)


```
// *** Diagnosealarm von Baugruppe mit Adresse[B][I][U] 256 [/U][/I][/B]? ***
      L     #OB82_MDL_ADDR              // Baugruppenadresse der Baugruppe, die Alarm auslöst
      L    [B][I][U] 256[/U][/I][/B]                        // SIWAREX U mit [U][I][B]Anfangsadresse 256[/B][/I][/U]
      ==I                               // ja,
      SPB   [U][I][B]N202[/B][/I][/U]                        // dann Alarm auswerten
      BEB
```

jetzt Sprungmarke N202 definieren


```
N202: L ´ok´
T MD94
```

das gleiche mit den "Nein" Sprungmarken.

Grüße


----------



## petzi (22 Juni 2010)

Ok Verpolt, danke für deine Ausführungen.


Nun hätte ich noch zwei Fragen dazu:

1) Kommt nun von einer der beiden SIWAREX-Baugruppen ein Fehler, so würde bei der angegebenen Programmierung der OB82 *nur *den Zyklus unterbrechen - aber weiter würde nichts passieren; sehe ich das richtig?

2) Wenn ich nun bei einem Fehler der Wiegebaugruppe einen Alarm in der Visualisierung haben möchte, muss ich dann das *Merkerdoppelwort *in der Visualisierung heranziehen?


----------



## petzi (23 Juni 2010)

Hi, könnte mir evtl. noch jemand meine zwei Fragen beantworten? 



petzi schrieb:


> Nun hätte ich noch zwei Fragen dazu:
> 
> 1) Kommt nun von einer der beiden SIWAREX-Baugruppen ein Fehler, so würde bei der angegebenen Programmierung der OB82 *nur *den Zyklus unterbrechen - aber weiter würde nichts passieren; sehe ich das richtig?
> 
> 2) Wenn ich nun bei einem Fehler der Wiegebaugruppe einen Alarm in der Visualisierung haben möchte, muss ich dann das *Merkerdoppelwort *in der Visualisierung heranziehen?


 
Danke für die Hilfe!


----------



## Verpolt (23 Juni 2010)

Hallo again,



> Zitat von petzi
> 
> Nun hätte ich noch zwei Fragen dazu:
> 
> ...



1. Ja, passiert nix. Wenn Du nix programmierts. Leerer OB82 verhindert CPU-Stop. (im Beispiel passiert auch nix-nur Auswertung der Teilnehmer und Ja/nein Antwort)

2. Ich würde an der Sprungmarke -Fehler- ein Bit (Merker/Datenbausteinbit..) setzen. Dieses an die Visu schicken. (Ja/Nein Doppelwort ist unnötig)

Rücksetzen wenn quittiert und "gehendes Ereigniss" 


LG


----------



## rostiger Nagel (23 Juni 2010)

es ist so das bei einen Fehlerereignis das den OB82 aufruft, dieser dann
einmal durchlaufen wird und dann geht es mit den zyklischen Programm
weiter ("OB1").
Am besten machst du es so das du deinen Fehler im entprechenden OB
auswertest, in diesen fall OB82. Dort ist es dann von vorteil das du einfach
nur einen Merker oder Datenbit setzt für den endsprechenden fehler und dieses
dann im zyklischen Programm weiterverarbeitest.
Das könnte z.b. sein eine Störmeldung ausgeben und entsprechend 
reagieren wenn eine baugruppe ausgefallen ist. D.h. wenn die Wage
nicht mehr arbeitet, den Produktionspozess an dieser stelle anhalten.


----------



## petzi (23 Juni 2010)

Vielen Dank für eure Antworten und Erklärungen...



Verpolt schrieb:


> Ich würde an der Sprungmarke -Fehler- ein Bit (Merker/Datenbausteinbit..) setzen. Dieses an die Visu schicken. (Ja/Nein Doppelwort ist unnötig)
> 
> Rücksetzen wenn quittiert und "gehendes Ereigniss"
> LG


 
In etwa so?


```
N200: NOP   0
      L     #OB82_EV_CLASS              // prüfen, ob Fehler "kommend"
      L     B#16#39                     // "39" heißt Fehler "kommend"
      ==I   
      SPB   [COLOR=red]A001[/COLOR]                        // Fehler "kommend" gemeldet
      SPA   A002                        // Fehler "gehend" gemeldet
```
 

Fehler kommend:


```
[COLOR=red]A001[/COLOR]: L     'JA  '
      T     MD    90
      [COLOR=blue]S M "Visu"[/COLOR]
      BEB
```
 
Und beim Rücksetzen einfach M "Visu" rücksetzen, oder?


----------



## Verpolt (23 Juni 2010)

> A001: L     'JA  '<---brauchst Du doch nicht
> T     MD    90         <---Das auch nicht
> S M #Visu              <---nimm eine globale Variable (M 100.0 / DB1.DBX0.0 )
> BEB



Hier wird jetzt nur auf Fehler ausgewertet, nicht aber welcher Teilnehmer.


M #Visu  ?
M "Visu"  ?    Schreibfehler?
Grüße


----------



## petzi (23 Juni 2010)

Hm, ich meinte eigentlich ob mein Merker an dieser Stelle richtig wäre... aber offensichtlich nicht.



> Ich würde an der Sprungmarke -Fehler- ein Bit (Merker/Datenbausteinbit..) setzen.


 Wo ist denn diese Sprungmarke?

So besser?


Code:

N200: NOP 0
S M100.0
L #OB82_EV_CLASS 
L B#16#39 
==I 
SPB A001 
SPA A002 


Falls ja, an *welcher *Stelle müsste der Merker M100.0 rückgesetzt (gehendes Ereignis) werden?


PS: 

Ja, #Visu war Schreibfehler 
Sollte eigentlich "Visu" heißen!


----------



## Verpolt (23 Juni 2010)

OK

Ein Beispiel anbei mit OB86 aber im Prinzip das gleiche.

Bild 1: Bei Fehler (kommend) wird M220.0 gesetzt (DP-Fault)
         Danach wird der Fehler einem Teilnehmer zugeordnet (DP3_FAULT)

Bei einem gehendes Ereignis (B#16#38) wird DP_FAULT zurückgesetzt.

DP3_FAULT wird auch zurückgesetzt, meine Störung (Bild 2) bleibt anstehen


Bild 2: DP3_FAULT setzt meine Störmeldung (Datenbausteinbit -    Kommunikation VISU)  

Reset Taster resetet Störmeldung


Gilt alles auch für OB82


----------



## petzi (23 Juni 2010)

Herzlichen Dank Verpolt für deine Mühe... aber jetzt ist es mir klar!

Ähm, bis auf eine Kleinigkeit:

Im Grunde könnte man doch auch schreiben


```
L #OB86_EV_Class
L B#16#39
==I
S "DP_FAULT"
 
[COLOR=red]L #OB86_EV_Class[/COLOR]
L B#16#38
==I
R "DP_FAULT"
 
usw.
```
 

*Ohne* den zweiten Ladebefehl L #OB86_EV_Class und *ohne* den Befehl TAK würde der Inhalt von Akku2 (B#16#39) und B#16#38 verglichen (==I) werden, richtig?

Durch den Befehl *TAK* (Tausche Akku1 mit Akku2) wird aber im Grunde wieder die rote Ladeanweisung verwendet, oder?


----------



## ssound1de (24 Juni 2010)

```
L #OB86_EV_Class   //#OB86_EV_Class in Akku1 laden
L B#16#39          //Inhalt von Akku1 nach Akku 2 kopieren und 39 in Akku1 laden
==I
S "DP_FAULT"
 
[COLOR=red]TAK                //Inhalt von Akku1 und 2 miteinander vertauschen = ...[/COLOR]
[COLOR=#ff0000]                    #OB86_EV_Class ist jetzt in Akku 1 und 39 in Akku 2[/COLOR]
[COLOR=#000000]L B#16#38          //Inhalt von Akku1 nach Akku 2 kopieren und 38 in Akku1 laden[/COLOR]
[COLOR=#000000]==I[/COLOR]
[COLOR=#000000]R "DP_FAULT"[/COLOR]
```
 
Klar?


----------



## petzi (24 Juni 2010)

Yep, jetzt ist es klar geworden; vielen Dank ssound1de!


----------



## PN/DP (24 Juni 2010)

Wenn ich eine Variable mehrfach auf verschiedene Werte vergleichen will, dann benutze ich nicht die Operation TAK 
sondern POP. Da wird der Sinn der Operation deutlicher sichtbar.

```
L #OB86_EV_Class   //#OB86_EV_Class in Akku1 laden
L B#16#39          //#OB86_EV_Class von Akku1 nach Akku2 und 39 in Akku1 laden
==I
S "DP_FAULT"
 
[COLOR=red]POP                //#OB86_EV_Class von Akku2 zurück in Akku1[/COLOR]
L B#16#38
==I
R "DP_FAULT"
```
Gruß
Harald


----------

