# Profinet-Diagnose



## KNEFI (11 Mai 2010)

Hallo Leute 
ich beschäftige mich derzeit mit einem Projekt indem ich meine Profinet Teilnehmer diagnostizieren möchte. Dies soll auf eine einfache Art und weise passieren. Ich möchte "einfach" nur bei einem Ausfall ein Bit gesetzt bekommen. Ähnlich wie bei dem FC125 dp Diagnose. 
Es gibt da den Baustein von Siemens fb126 dieser Baustein ist ein komplett system mit Visualisierung das ich so aber nicht anwenden möchte. Der zugehörige DB in dem die Daten stehen ist nicht weiter beschrieben. (von Siemens gewollt).

Nun meine Frage bevor ich anfange das Wincc bild zu entschlüsseln und den einzelnen Bits im Bild dem DB zuzuordnen. Hat jemand diese entschlüsselung vllt schon gemacht???
 Oder hat jemand vllt eine andere Muster lösung um mein Pronlem zu lösen?

Danke schonmal im voraus..........


----------



## Inflames (11 Mai 2010)

Soweit wie ich weiss, wenn ich dein Problem jetzt richig verstehe, gibt es so etwas schon. Ich hatte erst das vergnügen auf Messebau das ich auch die Profinetdiagnose fahren sollte über das WinCC. Ich hatte allerdings nur den IO Link und unten dran ein Asi-Netz. Also diese Diagnose war völlig für AS-i ausgelegt.:|


----------



## KNEFI (11 Mai 2010)

*oder..*

Hat jemand erfahreungen profinet mit dem ob 82 auszuwerten?? Also dieser Baustein von siemens FB126 ist mist.


----------



## Approx (11 Mai 2010)

KNEFI schrieb:


> Hat jemand diese entschlüsselung vllt schon gemacht???
> Oder hat jemand vllt eine andere Muster lösung um mein Pronlem zu lösen?


 
Für FC125 guck doch mal HIER
 Approx


----------



## MSB (11 Mai 2010)

Approx schrieb:


> Für FC125 guck doch mal HIER
> Approx



... Bringt dir nur leider bei Profinet nichts ...


----------



## Approx (11 Mai 2010)

MSB schrieb:


> ... Bringt *dir* nur leider bei Profinet nichts ...


Mir ist's eigentlich schnuppe! Dann eben nur für DP...


----------



## Schnicker (11 Mai 2010)

Hallo,
ich habe aus dem Inst-DB (normalerweise DB126) den Status auf 0 verglichen. Wenn 0 dann Profinet OK.

```
L     "Detail_PNIO_Diag".Systems_Status
      L     0
      ==I   
      =     "PNIO_OK"
```
In dem Bereich des DB´s stehen auch noch andere Sachen die man für eine einfache Diagnose verwenden kann.

Gruß Schnicker


----------



## rostiger Nagel (11 Mai 2010)

könntest du nicht einfach über den OB86 Baugruppenträgersausfall auswerten
ob eine Baugruppe ausgefallen ist.

Bei der Kopfinformaiton "OB86_EV_CLASS" kannst du dann prüfen was
das für ein erreignis war, der Wert "B#16#39" ist ein kommendes Ereignis
und bei "B#16#38" ist es ein gehendes Ereignis.

Über die Kopfinformation "OB86_FLT_ID" bekommst du dann über den Wert
was da so passiert ist, hier die relaveten Fehler:


```
B#16#CA
PROFINET IO-Systemausfall·    OB86_MDL_ADDR: logische Basisadresse des
IO-Controllers·    OB86_Z23:-    Bit 0 bis 10: 0 (Stationsnummer)-
Bit 11 bis 14: IO-System-ID-    Bit 15: 1-    Bit 16 bis 31: 0

B#16#CB
PROFINET IO-Stationsausfall/Stationswiederkehr·    OB86_RESERVED_1:
B#16#C4·    OB86_MDL_ADDR: logische Basisadresse des IO-Controllers· 
OB86_Z23:-    Bit 0 bis 10: Stationsnummer-    Bit 11 bis 14:
IO-System-ID-    Bit 15: 1-    Bit 16 bis 30: logische Basisadresse der
Station-    Bit 31: I/O-Kennung

B#16#CC
PROFINET IO-Stationswiederkehr mit Störung·    OB86_RESERVED_1:
B#16#C4·    OB86_MDL_ADDR: logische Basisadresse des IO-Controllers· 
OB86_Z23:-    Bit 0 bis 10: Stationsnummer-    Bit 11 bis 14:
IO-System-ID-    Bit 15: 1-    Bit 16 bis 30: logische Basisadresse der
Station-    Bit 31: I/O-Kennung

B#16#CD
PROFINET IO-Stationswiederkehr, Sollausbau weicht von Istausbau ab· 
OB86_MDL_ADDR: logische Basisadresse des IO-Controllers·    OB86_Z23:- 
Bit 0 bis 10: Stationsnummer-    Bit 11 bis 14: IO-System-ID-    Bit 15: 1- 
Bit 16 bis 30: logische Basisadresse der Station-    Bit 31: I/O-Kennung

B#16#CE
PROFINET IO-Stationswiederkehr, Fehler bei der Baugruppenparametrierung·
OB86_MDL_ADDR: logische Basisadresse des
IO-Controllers·
OB86_Z23:-    Bit 0 bis 10: Stationsnummer-    Bit 11 bis
14: IO-System-ID-    Bit 15: 1-    Bit 16 bis 30: logische Basisadresse der
Station-    Bit 31: I/O-Kennung
```
die Taste "F1" gibt weitere Information wenn du den OB86 anklickst


----------



## KNEFI (12 Mai 2010)

*re*

Danke für eure zahlreichen antworten...

Aber es ist irgendwie noch nichts für mich dabei....ich möchte nicht wissen das mein ganzes profinet nicht mehr funktioniert (das bekommt der Kunde schon mit wenn nichts mehr funktioniert) sondern ich möchte den Fehlerhaften teilnehmer identifizieren um den Kunden gezielt dort hinschicken zu können. Darum brauche ich auch keine diagnosen von den Teilnehmern oder sowas sondern nur das sie gestört sind.


----------



## rostiger Nagel (12 Mai 2010)

das müsstest du mal probieren, ist ungetestet


```
[B][U]OB86[/U][/B]
[B][/B] 
//Kommendes Ereignis
      L OB86_EV_CLASS
      L B#16#39
      ==I
      = #kommend
 
//gehendes Ereignis
      L OB86_EV_CLASS
      L B#16#38
      ==I
      = #gehend
 
//Fehler Code für PROFINET IO-Stationsausfall/Stationswiederkehr
       L OB86_FLT_ID 
       L B#16#CB
       ==I
       = #Profinet_IO
 
//Teilnehmer Nr aus Bit 0 bis 10 ausmaskieren
      L OB86_Z23
      SRD 22
      T #Teinehmer_Nr
```


----------



## styrax (12 Mai 2010)

Mithilfe der Systemzustandslisten (SZL) kannst du eine Auswertung für die Profinetteilnehmer schreiben die so arbeitet wie der FC125.


----------



## KNEFI (12 Mai 2010)

*re*

Ja die Systemzustandsliste...mmh 
kenn ich mich leider nicht mit aus. kann mir einer ein besipiel für das auslesen eines teilnehmers geben?


----------



## styrax (12 Mai 2010)

Schau mal bei Simatic. Beitrags ID 24000238
Vieleicht hilft das schon.

Gruß Styrax


----------



## KNEFI (12 Mai 2010)

*@Helmut*

Ich habe mal versucht dein Programmstückchen in meine CPU zu schreiben...dabei ist mir aufgefallen das der OB86 oder 82 nicht angesprochen werden obwohl keine Projektierte Hardware nicht angeschlossen ist. Die CPU springt in den OB122 und sagt mir in der Diagnosepuffer Peripherie-Zugrifsfehler, lesend aber auch schreibend.
Weißt du wie diese Aufrufe der OB funktionieren?

Habe den OB 122 auch schon gelöscht da ist die CPU in stopp gegangen. und der OB 86 wurde trotzdem nichangesprochen.

Hilfe???


----------



## rostiger Nagel (12 Mai 2010)

der OB86 muß aufgerufen werden wenn eine Baugruppe ausfällt


> Das Betriebssystem der CPU ruft den OB 86 in folgenden Fällen auf:
> · Der Ausfall eines zentralen Erweiterungsgeräts (nicht bei S7-300) wird erkannt (sowohl bei kommendem als auch bei gehendem Ereignis).
> · Der Ausfall eines DP-Mastersystems wird erkannt (sowohl bei kommendem als auch bei gehendem Ereignis).
> · *Der Ausfall einer Station bei Dezentraler Peripherie (PROFIBUS DP oder PROFINET IO) wird erkannt (sowohl bei kommendem als auch bei gehendem Ereignis).*
> ...


 
schreib doch mal folgenden Code rein um zu kontrolleren ob er wirklich
aufgerufen wird.

```
SET
      = M 10.0
```
 
Den Merker 10.0 kannst du dann in einer Variablentabelle beobachten.


OB82 ist für den Diagnosalarm da, dazu muß die Baugruppe Diagnosefähig 
sein und diese muß dann auch Scharfgeschaltetet werden.


> Wenn eine diagnosefähige Baugruppe, bei der Sie den Diagnosealarm freigegeben haben, eine Änderung ihres Diagnosezustands erkennt, stellt sie eine Diagnosealarmanforderung an die CPU:
> · Es liegt eine Störung vor oder eine Komponente muss gewartet werden oder beides (kommendes Ereignis).
> · Es liegt keine Störung mehr vor, und keine Komponente muss mehr gewartet werden (gehendes Ereignis).
> Daraufhin ruft das Betriebssystem den OB 82 auf.
> ...


----------



## KNEFI (12 Mai 2010)

Habe ich schon gemacht er wird nicht von der Cpu aufgerufen...verstehe ich nicht .


----------



## Schnicker (12 Mai 2010)

Hallo Helmut!
Ich wollte das ganze hier mal ausprobieren. Dabei ist mit aufgefallen, dass mein OB86 keine Variable OB86_Z23 hat. Mache ich da was falsch?
Gruß Schnicker


----------



## KNEFI (12 Mai 2010)

*re schnicker*

Hey wird bei dir der Ob86 aufgerufen bei einem Baugruppenausfall??? wenn ja kannste mir mal eine übersicht deiner eingebundenen OB geben.


----------



## Schnicker (12 Mai 2010)

Hi nochmal!
Also bei mir wird bei Baugruppenausfall der OB86 aufgerufen - hab´s probiert. Das Programm von Helmut ist auch - bis auf die Teilnehmer_Nr (siehe oben) - voll funktionsfähig.
An OB´s hab´ ich OB81-86, OB100, OB101, OB102 und OB122 drin.
Ach ja - CPU ist ne 414.
Falls ich nochwas probieren soll gib bescheid, ich habe hier gerade Leerlauf und sogar eine komplette Anlage zum Testen.
Gruß Schnicker


----------



## KNEFI (12 Mai 2010)

Also bei wir wird der OB86 nicht aufgerufen. habe allerdings keinen Baugruppenausfall simuliert sondern einfach nur eine Cpu 317f und mehrere teilnehmer. wobei die teilnehmer nur in der Hardware der Cpu existieren. 

Also der Fehler ist quasi nicht aufgetreten sondern war schon immer da. wenn du verstehst was ich meine. vllt wird desahlb der Ob 86 nicht aufgerufen. vllt muss der ausfall erst nach dem anlauf der cpu passieren..oderso??


----------



## dalbi (12 Mai 2010)

Hi,

anbei ein kleines Beispiel als AWL-Quelle mit der Auswertung über den SFC51 "RDSYSST". Hier kannst Du dann ganz einfach einen Ausfall eines Teilnehmers erkennen.

Gruss Daniel


----------



## KNEFI (12 Mai 2010)

hey das sieht ja schon nicht so schlecht aus. kannst du das etwas näher errläutern...wo was gemacht werden muss??? ist etwas aus dem zusammenhang. Und das sieht mir verdammt nach vb aus oder???


----------



## dalbi (12 Mai 2010)

Hi,

VB? das ist eine AWL Quelle, die kannst Du in Step7 importieren.

Gruss Daniel


----------



## dalbi (12 Mai 2010)

http://sps-forum.eu/showthread.php?t=19497

Gruss Daniel


----------



## Schnicker (12 Mai 2010)

Hallo,
ich habe jetzt Helmuts Lösung so probiert (sry Helmut mit der Frage nach der Variable OB86_Z23 - wer die F1-Taste bedienen kann ist klar im Vorteil):

```
//Kommendes Ereignis
      L     #OB86_EV_CLASS
      L     B#16#39
      ==I   
      =     #kommend
//gehendes Ereignis
      L     #OB86_EV_CLASS
      L     B#16#38
      ==I   
      =     #gehend
//Fehler Code für PROFINET IO-Stationsausfall/Stationswiederkehr
      L     #OB86_FLT_ID
      L     B#16#CB
      ==I   
      =     #Profinet_IO
//Teilnehmer Nr aus Bit 0 bis 10 ausmaskieren
      L     #OB86_Z23
      L     DW#16#7FF
      UW    
      T     #Teinehmer_Nr
```
und das ganze funktioniert prima!
Werde jetzt mal noch den Baustein von Daniel ausprobieren.
Gruß Schnicker


----------



## rostiger Nagel (12 Mai 2010)

Hallo Schnicker,
danke mit der Teilnehmer Nr. war jetzt auch so ins Blaue geschossen,
habe es nicht getestet, deshalb sollte der Kollege es mal machen


gruß helmut


----------



## Schnicker (12 Mai 2010)

Hallo Daniel,
habe dein Programm auch mal ausprobiert. Ist auch ne schöne Lösung. Erinnert auch am meisten an den PB-FC, da ich auch ein Bit pro Teilnehmer auswerten kann.
Gruß Schnicker


----------



## KNEFI (17 Mai 2010)

*@ all*

Ich habe deine Awl-Quelle ausprobiert und werde jetzt damit arbeiten. Sie Funktioniert so wie ich es brauche.

Danke für eure Hilfe.


----------



## Rodewijn (5 April 2011)

*Kommende und gehende Erreichnisse*

Ich habe die Ausfalldiagnose sehr ähnlich gemacht wie in diesem Thread vorgeschlagen wurde. Wenn OB86 meldet, dass ein Profinet-Station ausfällt, also ein "kommendes Erreichnis" wird ein zu diesem Station gehörendes Alarmbit gesetzt, und wenn das "gehende Erreichnis" kommt wieder zurückgesetzt. Leider habe ich hier noch nicht die Hardware um es auszuprobieren. Jetzt ist aber meine Frage: wird ein "kommendes Erreichnis" von OB86 irgendwann wiederholt, z.B. nach einem Versuch nochmals Kontakt mit dem Teilnehmer aufzunehmen, oder kommt es nur einmal. Des weiteren habe ich noch ein wenig Bedenken, es könnte irgendein Situation geben, dass mein Programm das "gehende Erreichnis" verpasst und der Alarm dann "für immer" stehen bleibt, dann wäre so eine wiederholung des "kommende Erreichnis" ganz nützlich, ich könnte dann nach einem Time-Out den Alarm automatisch zurücksetzen. Weiss jemand hier genaueres?


----------



## Rycker (26 Oktober 2011)

dalbi schrieb:


> Hi,
> 
> anbei ein kleines Beispiel als AWL-Quelle mit der Auswertung über den SFC51 "RDSYSST". Hier kannst Du dann ganz einfach einen Ausfall eines Teilnehmers erkennen.
> 
> Gruss Daniel


 
Hallo !
 Beim übersetzen der Awl Qulle bekomme ich immer 7 Fehler 
Syntax Error usw. Mache ich was falsch ?
Kopiere den Code und füge ihn in einer neuen AWl Quelle ein 
anschl. übersetze ich ihn .


----------



## Flinn (26 Oktober 2011)

Rycker schrieb:


> Hallo !
> Beim übersetzen der Awl Qulle bekomme ich immer 7 Fehler
> Syntax Error usw. Mache ich was falsch ?
> Kopiere den Code und füge ihn in einer neuen AWl Quelle ein
> anschl. übersetze ich ihn .


 
Symbole fehlen bestimmt.

Gruß,
Flinn


----------



## Zombie (31 Januar 2016)

dalbi schrieb:


> Hi,  anbei ein kleines Beispiel als AWL-Quelle mit der Auswertung über den SFC51 "RDSYSST". Hier kannst Du dann ganz einfach einen Ausfall eines Teilnehmers erkennen.  Gruss Daniel


  Die Quelle ist sehr hilfreich, aber was mich noch interessieren würde ist, ob ich den Baustein auch im OB86 aufrufen kann. Eigentlich muss der nicht in jedem Durchlauf angestossen werden, sondern nur wenn es wirklich einen Ausfall gab, oder sehe ich das verkehrt?  Danke schonmal


----------



## Thomas_v2.1 (31 Januar 2016)

Zombie schrieb:


> Die Quelle ist sehr hilfreich, aber was mich noch interessieren würde ist, ob ich den Baustein auch im OB86 aufrufen kann. Eigentlich muss der nicht in jedem Durchlauf angestossen werden, sondern nur wenn es wirklich einen Ausfall gab, oder sehe ich das verkehrt?  Danke schonmal



Dann solltest du die Diagnose aber zusätzlich einmal nach dem SPS Neuanlauf aufrufen. Andernfalls würde deine Diagnose nicht funktionieren, z.B. wenn du schon mit ausgefallenem Teilnehmer die SPS hochlaufen lässt. Aber ich glaube so viel Rechenzeit benötigt der Baustein auch nicht, als dass man ihn nicht zyklisch aufrufen könnte.


----------



## Zombie (31 Januar 2016)

Danke für den Hinweis.


----------



## Zombie (7 Februar 2016)

Ich kann jetzt nur sagen, dass der Aufruf im OB 86 und OB 100 nicht funktioniert. Da der SFC 51 wohl mehrere Zyklen lang braucht bis er das komplette Netzwerk untersucht hat, schafft er das wohl nicht wenn er im OB 86 oder OB 100 nur einmalig aufgerufen wird. Es stimmt, dass er nicht viel Zykluszeit verbraucht, aber man muss ihn trotzdem nicht in jedem Zyklus anstossen.  Nunmehr rufe ich ihn mit dem MX.5 Blinker auf und bekomme mit nur einer kurzen Zeitverzögerung mit wenn ein PN Teilnehmer ausfällt.


----------



## vollmi (7 Februar 2016)

Zombie schrieb:


> Nunmehr rufe ich ihn mit dem MX.5 Blinker auf und bekomme mit nur einer kurzen Zeitverzögerung mit wenn ein PN Teilnehmer ausfällt.



Was versprichst du dir dadurch? Ein Zyklus, dann wenn der blinker den SFC51 auslöst ist ja dann trotzdem länger. 
Nichts dagegen etwas das Zykluszeitbelastend ist zu optimieren, aber dann verteilt man die Aufgabe gleichmässig über mehrere Zyklen. Das tut die Funktion aber offenbar schon also würde ich solche Sachen nicht noch erweitern.

Es gibt nämlich auch Leute die Packen einen fetten Bubblesort in jeden 1000. Zyklus was zu recht lustigen Zykluszeitschiebungen führt die ein späterer Programmierer nur sehr schwer findet.

mfG René


----------



## Zombie (7 Februar 2016)

vollmi schrieb:


> Was versprichst du dir dadurch?


  Ich möchte schlicht den Traffic auf dem Netzwerk verringern und Anfragen die mir nichts bringen soweit wie möglich reduzieren/ ganz verhindern.  Wenn alles Fehlerfrei läuft ist das schön, aber ich muss es nicht jeden Zyklus nachfragen, sondern nur dann wenn es einen Ausfall gab.  





vollmi schrieb:


> Ein Zyklus, dann wenn der blinker den SFC51 auslöst ist ja dann trotzdem länger.


  Natürlich, aber alle X00 Zyklen einen Zyklus länger ist schneller wie jeder Zyklus länger.   





vollmi schrieb:


> Nichts dagegen etwas das Zykluszeitbelastend ist zu optimieren, aber dann verteilt man die Aufgabe gleichmässig über mehrere Zyklen. Das tut die Funktion aber offenbar schon also würde ich solche Sachen nicht noch erweitern.


  Ich wollte halt mal üben wie ich solch eine Diagnose in ein Programm einbauen kann, dass sie so klein und unauffällig ist wie nur möglich. Der SFC Aufruf in jedem Zyklus in dem er nicht bereits aktiv ist, erscheint mir unnötig und etwas in mir sträubt sich gegen Unnötiges. 





vollmi schrieb:


> Es gibt nämlich auch Leute die Packen einen fetten Bubblesort in jeden 1000. Zyklus was zu recht lustigen Zykluszeitschiebungen führt die ein späterer Programmierer nur sehr schwer findet. mfG René


  Ja, solche Leute soll es ja geben. Ich habe in meiner kurzen Berufslaufbahn bisher nicht viel gesehen, aber was ich teilweise von Firmen gesehen habe, teilweise sogar sehr namhaften weltweit bekannten und agierenden Firmen, bringt etwas in mir echt zum sträuben. In dem Sinne ist mir gerade noch eingefallen, dass ich den Start der Abfrage über "Bit setzen" doch in den OB 86 und OB 100 legen kann, die Bearbeitung dann aber über mehrere Zyklen danach im OB1 erfolgt.


----------



## vollmi (7 Februar 2016)

Den Request, lege ich oft auch in den entsprechenden OB. Das funktioniert ganz gut. Wird immer etwas Tricky wenn man den SFC auch für andere Aufgaben nutzt und diesen aber nicht paralell über mehrere Aufträge ackern lassen will oder kann, bei der 400 ist das oft schnell mal kritisch, nicht weil sie weniger Aufträge paralell kann, sondern weil man bei der oft mehr Wissen will.

mfG René


----------



## Thomas_v2.1 (7 Februar 2016)

Zombie schrieb:


> Ich möchte schlicht den Traffic auf dem Netzwerk verringern und Anfragen die mir nichts bringen soweit wie möglich reduzieren/ ganz verhindern.


Die Abfrage der entprechenden SZLs über den SFC erzeugt aber keinen Traffic auf dem Netzwerk, er fragt nur die intern vorhandenen Informationen ab. Die Steuerung weiß in jedem Fall immer, ob ein Profinet-Teilnehmer vorhanden oder ausgefallen ist, auch ohne dass du den SFC anstößt.


----------



## 0815prog (16 August 2017)

dalbi schrieb:


> Hi,
> 
> anbei ein kleines Beispiel als AWL-Quelle mit der Auswertung über den SFC51 "RDSYSST". Hier kannst Du dann ganz einfach einen Ausfall eines Teilnehmers erkennen.
> 
> Gruss Daniel




Vielen Dank für die AWL-Quelle, konnte was Hübsches daraus entwickeln. Der Grundgedanke hat echt weitergeholfen.
_________________________________________________________________________________________________

Gruß


----------

