# S7-300 nicht in Stop bei Profibussttörung



## -Melanie- (9 Februar 2010)

Hallo Leute,

Kann mir jemand sagen wie und welche Bausteine ich einbinden muss um bei Profibusstörungen nicht in den zustand Stop zu gelangen.

Habe eine CPU 315 -2 DP


----------



## Hawkster (9 Februar 2010)

OB 82 -> Rack Fault (Wenn ein Modul in Störung geht)
OB 85 -> IO Fauliure

Mit freundlichen Grüßen,
Hawkster


----------



## Larry Laffer (9 Februar 2010)

Na - ja ...
meine Favouriten sind OB82 , OB86 und OB122 ...

Gruß
LL


----------



## Steve38 (9 Februar 2010)

Muss ich die Baustein tatsächlich nur aufrufen im OB1 ?

Möchte gerne das die CPU nach einen DP Fehler, von alleine wieder anläuft


----------



## offliner (9 Februar 2010)

Die Bausteine müssen gar nicht aufgerufen werden, die müssen nur auf der Steuerung vorhanden sein...


----------



## Steve38 (9 Februar 2010)

Ok.
Hab ich, und dann geht die CPU nicht mehr in Stop?


----------



## rostiger Nagel (9 Februar 2010)

nein die cpu läuft weiter, du kannst in den entsprechenden Bausteinen 
auswerten was los ist und entsprechend reagieren.


----------



## thomass5 (9 Februar 2010)

Ich würde sogar dazu raten, in den Bausteinen den Fehler auszuwerten und entsprechend zu reagieren. Wenn z.B.  dummerweise an den Baugruppen Endlagenschalter auch noch als Schließer drann sind ...
Thomas


----------



## R.Blum (9 Februar 2010)

Steve38 schrieb:


> Ok.
> Hab ich, und dann geht die CPU nicht mehr in Stop?


 

Wenn Du den Fehler ausgewertet hast und der Meinung bist, dass die CPU wegen des Fehlers trotzdem in Stop gehen sollte, rufst Du in dem jeweiligen Fehler OB den SFC46 auf.

Gruß Rolf


----------



## Steve38 (10 Februar 2010)

Ich möchte eigentlich nur im Panel sagen, welches Gerät gerade nicht mehr am Bus ist.


----------



## derwestermann (10 Februar 2010)

Dann empfehle ich PNIO-Diag.

Oder wenn's die CPU nicht hergibt, die alte Diagnose mit dem FC/FB125.


----------



## Steve38 (11 Februar 2010)

Morgen,

erbitte um hilfe. 
Hab das noch nie gemacht. 

Bis jetzt hab ich immer nur Panels über den DP mit eingebunden.

Was muss ich, wo genau machen?!


----------



## Perfektionist (11 Februar 2010)

Ich habs zwar auch noch nicht gemacht, habe halt immer die OB82/86 nur deswegen eingebunden, um den Stopp zu verhindern.

Ich denke mal, wenn man das Handbuch
"STEP 7 - System- und Standardfuntionen für S7-300 und S7-400"
( wird mit der Installation mitgeliefert) aufschlägt und Kapitel 1.18 und 1.22 betrachtet, dann kommt man schon ein ganzes Stück weiter ...


----------



## Larry Laffer (11 Februar 2010)

Hallo Steve,
du lädst dir zunächst bei Siemens die vom Westermann benannten Bausteine runter (sind Freeware).
Je nach Geschmack verwendest du dann den FB oder den FC - mir reicht normalerweise der FC. Den beschaltest du entsprechend (wie beschrieben). In den Fehler-OB's setzt du ein Trigger-Bit für den FC welches du dann wieder zurück nimmst. Der FC gibt dir dann in 2 Bereichen die entsprechenden Meldungen aus. Bei Siemens gibt es dazu aber auch gleich eine Beispiel-Applikation.
Schau dir das einfach mal an ...

Gruß
LL


----------



## Steve38 (11 Februar 2010)

Hi,

perfekt. Hab´s gefunden.

Das klappt ja wunderbar. 

http://support.automation.siemens.com/AT/llisapi.dll?func=cslib.csinfo&objId=26996747&objAction=csOpen&nodeid0=16599820〈=de&siteid=cseus&aktprim=4&extranet=standard&viewreg=AT


----------



## Steve38 (11 Februar 2010)

Simulieren mit PLCSIM kann ich das ganz hier am PC nicht oder?


----------



## Perfektionist (11 Februar 2010)

Steve38 schrieb:


> Hi,
> 
> perfekt. Hab´s gefunden.
> 
> ...


das hab ich mir soeben auch angeschaut - und ich würde es in eines meiner Programme nicht einbinden mögen ...

(und das liegt nicht an der orangenen Farbe, sondern fängt schon damit an, dass z.B. der DB126 schonmal gar keinen Namen hat.)


----------



## Jochen Kühner (11 Februar 2010)

*Also...*

Also ich hab im OB86 eigendlich immer folgenden Code:


```
U(    
      L     #OB86_FLT_ID
      L     B#16#C4
      ==I   
      )     
      U(    
      L     #OB86_EV_CLASS
      L     B#16#39
      ==I   
      )     
      SPB   pbEr

      U(    
      L     #OB86_FLT_ID
      L     B#16#C4
      ==I   
      )     
      U(    
      L     #OB86_EV_CLASS
      L     B#16#38
      ==I   
      )     
      SPB   pbOK

      BEA   

pbEr: L     LB    10
      +     -1
      L     16
      *I    
//DP Slave Teilnehmernummer
      L     LB    11
      +I    
      LAR1  
      AUF   "DB_STOERUNGEN_PROFIBUS"
      SET   
      S     DBX [AR1,P#0.0]
      BEA   

//LB10 -> Mastersystem ID
pbOK: L     LB    10
      +     -1
      L     16
      *I    
//DP Slave Teilnehmernummer
      L     LB    11
      +I    
      LAR1  
      AUF   "DB_STOERUNGEN_PROFIBUS"
      SET   
      R     DBX [AR1,P#0.0]
      BEA
```

Und dann den DB Störungen profibus so aufgebaut:


```
PROFIBUS_MASTER	ARRAY[1..5]		$PB-STOERUNG$	
	STRUCT			
TN_ERROR	ARRAY[0..126]			
	BOOL			
	END_STRUCT
```


----------



## Steve38 (12 Februar 2010)

Ok, 
das ist perfekt.

Aber so richtig will es noch nicht klappen. Die CPU geht immer noch in Stop. Liegt es an meiner Anweisung im OB1?

In meine OB1 schreib ich:
      L     B#16#1
      T     PAB  256

damit sag ich quasi dem Gerät DP1 welches Datenprofil er mir zurück senden soll. 
Und das kann ich natürlich nicht mehr machen wenn der Teilnehmer nicht mehr da ist. Wie kann ich das unterbinden?



Simulieren kann ich das ganze mit PLCSIM, oder?
ausführen->fehler-ob auslösen->ob86

Irgenwie will es aber sich damit nicht simulieren lassen. :-(


----------



## rastus (12 Februar 2010)

Du musst auf das grüne Kästchen im DP-Status klicken um einen Stationsausfall zu simulieren.


----------



## Jochen Kühner (12 Februar 2010)

*nee...*

nee, das waren 2 verschalchtelte arrays.

maximal 5 master, und in jedem master gibt es wieder 128 bool variablen!



Steve38 schrieb:


> Ok,
> das ist perfekt.
> 
> Aber so richtig will es noch nicht klappen. Die CPU geht immer noch in Stop. Liegt es an meiner Anweisung im OB1?
> ...


----------



## Steve38 (12 Februar 2010)

rastus schrieb:


> Du musst auf das grüne Kästchen im DP-Status klicken um einen Stationsausfall zu simulieren.



Ja schon klar, dass hab ich gemacht. Hab es jetzt nur nicht als Screenshot dargestellt. Aber dies funktioniert nicht!


----------



## Jochen Kühner (12 Februar 2010)

*Hmmm*

das solltest du doch an der Stopp Ursache sehen...


----------



## Steve38 (12 Februar 2010)

Jochen Kühner schrieb:


> nee, das waren 2 verschalchtelte arrays.
> 
> maximal 5 master, und in jedem master gibt es wieder 128 bool variablen!




Wie meinst du das?

Mach mal nen Screenshot, von deinem DP







du meinst so, oder?


----------



## Steve38 (12 Februar 2010)

Jochen Kühner schrieb:


> das solltest du doch an der Stopp Ursache sehen...




Jepp, die liegt ja im OB 1

Und mehr ist da nicht drin, außer ein paar FC aufrufe, aber die sind nicht betroffen.


----------



## rastus (12 Februar 2010)

Poste doch mal den Diagnosepuffer.

Nur so eine Vermutung. Du hast eine CPU als Mastersystem und eine Station als DP-Slave in deiner Simulation. Wenn diese ausfällt, was soll die CPU dann denn noch bearbeiten? Ich weiss nicht, ob man den Stop durch Baugruppenausfall bis zum Ende ausreizen kann. Vielleicht hat die CPU beim jetzigen Programm gar keine Chance, um den Stop zu verhindern.


----------



## Steve38 (12 Februar 2010)

rastus schrieb:


> Poste doch mal den Diagnosepuffer.
> 
> Nur so eine Vermutung. Du hast eine CPU als Mastersystem und eine Station als DP-Slave in deiner Simulation. Wenn diese ausfällt, was soll die CPU dann denn noch bearbeiten? Ich weiss nicht, ob man den Stop durch Baugruppenausfall bis zum Ende ausreizen kann. Vielleicht hat die CPU beim jetzigen Programm gar keine Chance, um den Stop zu verhindern.



Hier:


----------



## -Melanie- (12 Februar 2010)

Der 2. DB ist richtig der erste wäre Sinnfrei


----------



## Jochen Kühner (12 Februar 2010)

so:


----------



## Steve38 (12 Februar 2010)

Und mein OB1 sieht wie folgt aus:

NW 1
Call FC1

NW 2
Call FC2

NW 3
 Call FC3

NW 4
 Call FC4

NW 5
  Call FC5

NW6
L     B#16#1
T     PAB  256


----------



## Steve38 (12 Februar 2010)

Im NW6 sag ich dem Teilnehmer der Ausfallen kann, was ich für ein Profil haben möchte. 

Die Teilnehmer DP 2 (CPU) und DP3 (Panel) können nicht ausfallen, jedenfalls nicht im Normalfall. DP1 ist ein Messgerät das bei Spannungsausfall halt aussteigen kann.


Siehe hier:


----------



## rastus (12 Februar 2010)

Ich hab deinen OB1 mal nachgebaut. Dein Stopursache liegt aber im NW4 (Bausteinadresse 58) und kommt vom FC4.


----------



## Steve38 (12 Februar 2010)

Den hab ich aber schon rausgenommen und es ergab keine Änderung. :-(

Im FC4 skalier ich die Werte vom UMG96S, quasi von DP-Teilnehmer 1, mit dem richtigen Faktor.

z.B. im NW1
     L     "Strom L1"
     L     2
     *I    
     T     "Analogwerte skaliert".Strom_L1
     NOP   0


----------



## rastus (12 Februar 2010)

Es muss aber eine Änderung im Diagnosepuffer geben.


----------



## Steve38 (12 Februar 2010)

Der Puffer hat mir genau das angezeigt als ich den FC4 rausgenommen habe.

Aber es funktioniert ja auch mit der simulation nicht.
Geh jetzt immer wieder in die Werkstatt an die echte CPU


Jetzt hab ich NW4 und NW6 mal rausgenommen:


----------



## rastus (12 Februar 2010)

Dann ist das NW4 jetzt leer? Das ist aber seltsam.
Öffne doch mal den OB1 und navigiere mit "Gehe zu -> Bausteinadresse -> 58" zur Stopursache.


----------



## PN/DP (12 Februar 2010)

*Peripheriezugriffsfehler-OB122*

Hallo Steve38,

in Deinem Beitrag #27 warst Du schon sehr knapp dran, warum Deine CPU in Stop geht.
Du must nur den Diagnosepuffer-Eintrag *ganz durchlesen* (hochscrollen)!

Da steht ja eindeutig:


> STOP durch Peripheriezugriffsfehler (*OB nicht geladen* ...


Wenn Du da noch etwas weiterscrollst, dann müßte da etwa sowas stehen:


> Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)


Weil Du keinen OB122 in der CPU hast geht Deine CPU in Stop.
Wenn Du nun einen (leeren) OB122 in die CPU lädtst, dann geht die CPU nicht mehr in Stop,
aber der Diagnosepuffer läuft dann über mit Peripheriezugriffsfehler-Diagnoseeinträgen.
Nicht sehr elegant, hilft aber fürs erste weiter.

Mit den SFC36 und SFC37 kann man die Aufrufe des OB122 beeinflussen. 
Das ist aber wahrscheinlich (noch) viel zu kompliziert für Dich.

Besser ist es, die Diagnoseangaben aus dem OB86 auszuwerten und wenn ein DP-Slave ausgefallen ist, 
dann nicht mehr auf die Adressen des DP-Slave zugreifen.

Z.B. etwa so:
Nicht direkt die PEW... und PAW... im Programm benutzen, sondern Zwischenmerker MW... oder DBW...
Am OB1-Anfang die PEW... auf Eingangs-MW/DBW kopieren, aber nur, wenn der zugehörige Slave OK ist.
Am OB1-Ende die Ausgabe-MW/DBW in die PAW... kopieren, aber nur, wenn der zugehörige Slave OK ist.

Gruß
Harald


----------



## Steve38 (12 Februar 2010)

PN/DP schrieb:


> h.
> 
> Besser ist es, die Diagnoseangaben aus dem OB86 auszuwerten und wenn ein DP-Slave ausgefallen ist,
> dann nicht mehr auf die Adressen des DP-Slave zugreifen.
> ...



Hi Harald, 

aber wie stell ich fest ob der zugehörige Slave ok ist.

Würde gerne die Auswertung machen, auch in Bezug auf die Zukunft, hab bald ein Projekt anstehen mit 40 DP-Teilnehmer


----------



## Steve38 (12 Februar 2010)

PN/DP schrieb:


> Hallo Steve38,
> 
> in Deinem Beitrag #27 warst Du schon sehr knapp dran, warum Deine CPU in Stop geht.
> Du must nur den Diagnosepuffer-Eintrag *ganz durchlesen* (hochscrollen)!



Da stand nichts von OP122


----------



## Steve38 (12 Februar 2010)

Irgendwie geht das auch immer noch nicht mit PLCSIM, denke das da prinzipell noch irgendwas total schief ist. :-(


----------



## PN/DP (12 Februar 2010)

Steve38 schrieb:


> aber wie stell ich fest ob der zugehörige Slave ok ist.
> 
> Würde gerne die Auswertung machen, auch in Bezug auf die Zukunft, hab bald ein Projekt anstehen mit 40 DP-Teilnehmer


Indem Du zum Beispiel den OB86 von Jochen Kühner aus #18 nimmst und die Bits aus dem "DB_STOERUNGEN_PROFIBUS" verknüpfst. 
(DBX... = 1 : Slave ist ausgefallen)

Oder Du nimmst die Bits aus dem Diagnosepaket PNIODiag, welches Du doch schon erfolgreich getestet hast:


Steve38 schrieb:


> Hi,
> 
> perfekt. Hab´s gefunden.
> 
> ...



Gruß
Harald


----------



## Steve38 (13 Februar 2010)

PN/DP schrieb:


> Indem Du zum Beispiel den OB86 von Jochen Kühner aus #18 nimmst und die Bits aus dem "DB_STOERUNGEN_PROFIBUS" verknüpfst.
> (DBX... = 1 : Slave ist ausgefallen)



Ok, ich würde gerne die Version von Jochen nehmen. 
Aber soweit das der OB86 aufgerufen wird, bin ich ja noch garnicht. :-(

Wenn ich die Hauptspannung wegnehme und damit der Teilnehmer 1 nicht mehr im Bus ist, geht meine SPS immer noch auf Stop. :-(


----------



## Jochen Kühner (13 Februar 2010)

*Doch...*

doch, der ob 86 wird schon aufgerufen, aber du addresierst ja deine eingänge noch, und dann geht sie wahrscheinlich auf stop!


----------



## Steve38 (13 Februar 2010)

Ok, das probier ich am Montag in der Werkstatt aus.
Hab das jetzt alles soweit geändert.

Mit PLCSIM klappt es nicht, weil ich nur eine 314 2-DP verwende, dafür braucht man aber mindestens eine 315 2-DP.


Ach noch was, als ich beim letzten mal in die echte CPU übertragen habe, schrieb mir das System, irgendwas von der anordnung der Baustein bzw. das sie falsch angeordnet sind.

Hier mal ein Bild:


----------



## Steve38 (13 Februar 2010)

Wenn ich das ganze dann mal mit der 315 2-DP teste, dann kann ich der DP Station auch wegschalten, dann läuft alles perfekt.

Aber man muss drauf achten, das man auch beim zuschalten die Reihenfolge einhält, Station wiederkehr und dann erst Station o.k., sonst bleibt das Bit nämlich auf True.


----------

