# Profibusteilnehmer fällt aus und bringt den gesamten BUS zum erliegen



## Hoppi (10 Oktober 2016)

Hallo liebe SPS-Kollegen,

leider fällt immer wieder bei einem ehemaligen Projekt in der Wasserversorgung ein Busteilnehner aus.

Der Ausfall als solches währe nicht weiter von Besonderheit wenn dazu nicht immer der gesamte Bus mit allen dazugehörigen Slaves ebenfalls ausfallen täte.

Nach wiederkehr des einst ausgefallenen Teilnhemer bleibt der BUS weiterhin ausgefallen. 

Es ist unabhängig welcher von den zwei Teilnehmenern ausfällt. Der Bus geht in Störung und bleibt gestört bis die Versorgungsspannung entfernt und wieder aufgelegt wird oder ein Kaltstart über das PG durchgefügrt wird.

Es befinden sich zwei Slaves an einem Master CP. Fällt der BUS aus so leuchtet die SF-LED und Error-LED am Master-CP. Der Master CP versucht dann nach einiger Zeit selbständig neu zu "lernen" und anzulaufen jedoch ohne Erfolg.

Zur besseren Veranschaulichung ist ein kleiner Übersichtsplan(-skizze) angehängt.


----------



## Larry Laffer (10 Oktober 2016)

OK ...
Du könntest jetzt folgendes machen :
- du kaufst dir z.B. von Fa. Helmholtz einen PB-Multiplexer. Damit machst du aus deinem PB ein Stern-Netz bei dem aus dem MUX je ein Strang nach dem jeweiligen Slave und einer nach dem PB-Master geht. Nun würde der Ausfall eines Slaves den Bus selbst nicht mehr beeinträchtigen.
- du programmierst nun in der CPU einen Fehler-OB, der den Ausfall des Slaves erkennt und dann (ggf. nach gewisser Zeit) den beschriebenen HW-Reset über SPS-Ausgänge realisiert. Gleichzeitig würde so die CPU selbst auch nicht mehr in den Stop gehen.

Gruß
Larry


----------



## Ing_Lupo (10 Oktober 2016)

Hallo

wie alt sind die PB Extender ?


----------



## Hoppi (10 Oktober 2016)

Larry Laffer schrieb:


> OK ...
> Du könntest jetzt folgendes machen :
> - du kaufst dir z.B. von Fa. Helmholtz einen PB-Multiplexer. Damit machst du aus deinem PB ein Stern-Netz bei dem aus dem MUX je ein Strang nach dem jeweiligen Slave und einer nach dem PB-Master geht. Nun würde der Ausfall eines Slaves den Bus selbst nicht mehr beeinträchtigen.



Hallo Larry,

stimmt...diese Varianta hätte ich mir gern als aller lezte Reis-aus-Möglichkeit reserviert. Vielen Dank!!


----------



## Hoppi (10 Oktober 2016)

Ing_Lupo schrieb:


> Hallo
> 
> wie alt sind die PB Extender ?



Hallo Lupo,

die Bauteile sind vor ca. 6 Monate von Phoenix an uns geliefert worden.



die PB Extender sind diese hier:


Strecke 1 = 2-Draht-Übertragung




https://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetailid=2313656&library=dede&tab=1





Strecke 2 = Funkübertragung

https://www.phoenixcontact.com/onli...2901541&library=dede&pcck=P-26-03-05-01&tab=1


----------



## Ing_Lupo (10 Oktober 2016)

Hallo

Sind die PNO zertifiziert für Profibus ?


----------



## Hans-Ludwig (11 Oktober 2016)

Hallo Hoppi

Besteht die Chance den Ausfall mit zu schreiben. Z. B. Mit dem Amprolyser und mir den für die Analyse zuzuschicken. Unter Amprolyser Download findest Du die Freeware.

Hlg@i-v-g.de
Www.i-v-g.de


Gesendet von iPhone mit Tapatalk


----------



## Hoppi (11 Oktober 2016)

Ing_Lupo schrieb:


> Hallo
> 
> Sind die PNO zertifiziert für Profibus ?



Hallo Lupo,

nein, nach meinem Wissensstand sind weder das eine, noch das andrer Gerät PNO zertifiziert.


----------



## Hoppi (11 Oktober 2016)

Hans-Ludwig schrieb:


> Hallo Hoppi
> 
> Besteht die Chance den Ausfall mit zu schreiben. Z. B. Mit dem Amprolyser und mir den für die Analyse zuzuschicken.



Hallo Hans-Ludwig,

leider habe ich keine möglichkeit die Software Amprolyser zu benutzen da ich als Betriebssystem Windows 7 besitze. Amprolyser benötigt jedoch XP oder 2000.

Gibt es ein weiteres Tool?


----------



## Hans-Ludwig (11 Oktober 2016)

Wir könnten Dir ein Pt 2 ausleihen
07031-607880


Gesendet von iPhone mit Tapatalk


----------



## Hoppi (12 Oktober 2016)

Hallo Hans-Ludwig,

mittlerweile bin ich des Rätzels Lösung etwas weiter voran geschritten.

Der Aktuelle Anlagenzustand beschreibt sich wie folgt.

Die Steuerung funktionierte so lange Fehlerfrei bis einer von beiden Slaves kurzzeitig den physikalischen BUS-Kontakt verliert.
Ist dies der Fall so bleibt die CPU (Vipa 200V / S7-300er / 315-2-DP) weiter im RUN und die SF LED leuchtet rot.
Nach dem ich gestern in den Eigenschaften der CPU unter dem Registerkartenreiter "Taktmerker" die Einstellung.

"OB85-Aufruf bei Peripheriezugrifshehler" von "KEIN OB-85 aufrufen" auf "Nur bei kommenden und gehenden Fehlern" umgestellt habe wird nun im Fehlerspeicher der Fehler

Ereignis 1 von 100:  Ereignis-ID 16# 2942
Peripherie-Zugriffsfehler, lesend  
P-Bereich , Wortzugriff, Zugriffsadresse: 102
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse:  1
externer Fehler, kommendes Ereignis

Der OB 122 ist jedoch in meinem Program vorhanden.

Ich habe daruf hin den OB 122 online entfernt und wieder neu erzeugt. Die o.a. Fehlermeldung bleibt jedoch.

Aktueller Stand ist.

DP-Slave verliert wegen schlechter Funkverbindung KURZZEITIG einen Kontakt. Darauf hin:

-Bleibt dei CPU im RUN
-dei LED SF leuchtet durchgehend.
-im Fehlerspeicher erscheint die o.a. Fehlermeldung
-Der CP-Master bekommt einen totalausfall
-der weitere zweite angehängte Slave wird von CP-Master daher nicht weiter behandelt
-somit gesamter Prozessausfall der Anlage.

Erst nachdem die CPU kurz spannungslos geschaltet wird läuft der SP-Master wieder korrekt an.

Leider ist meinem Anfängerwissen absolut Ausgeschöpft.


----------



## Larry Laffer (12 Oktober 2016)

OK ... wie ich schon beschrieben habe kommst du mit Programm alleine hier nicht weiter.
So lange du einen PB-Strang hast wird sich ein Fehler eines Teilnehmers möglicherweise immer auf alle Teilnehmer auswirken. Da solltest du (nach meiner Meinung) zunächst ansetzen.
Dann käme für mich die spannende Frage : warum oder wie verliert einer der Teilnehmer (Slaves) kurzzeitig physikalisch den Buskontakt ? Wird die Strecke irgendwie unterbrochen ? Wenn ja, dann ist das ja möglicherweise gar nicht zu umgehen und du mußt an der Stelle dann etwas machen um wieder an den Start zu kommen. Das hat aber ggf. auch etwas mit den Teilnehmern selber zu tun ...

Gruß
Larry


----------



## PN/DP (12 Oktober 2016)

Was für SPS und evtl. Profibus-CP sind das bei Dir genau, besonders was für eine SPS ist der DP-Master? Ich würde ein Firmware-Problem des Masters oder der Gateways/Extender vermuten.
Hilft es evtl. für das wieder-Anlaufen des Profibus, das Phoenix PSI oder das Phoenix RAD am Profibusstrang des Masters kurz spannungslos zu machen, anstatt die CPU auszuschalten? Funktioniert das wieder-Einbinden (Ausfall/Wiederkehr) des anderen DP-Slaves?
Die ordnungsgemäße Profibus-Terminierung mit RS485-Abschlußwiderständen und Pullup+Pulldown-Widerständen und deren 5V-Versorgung wurden sicher schon überprüft?

Harald


----------



## Larry Laffer (12 Oktober 2016)

@Harald:
das liest sich für mich so, als wenn durch die "physikalische Unterbrechung" zumindestens auf einer Seite die Terminierung wegfällt.
Möglicherweise wäre das auch noch so ein Ansatz - eben eine aktive Terminierung noch hinter den jeweiligen Slave zu setzen ...


----------



## JesperMP (12 Oktober 2016)

Ich glaube das es ist vielleicht der Verbindung zwischen VIPA CPU und CP (CP342-5 ? Genau welche MFLB ?) der meckert.
Hat der CP342-5 ein Peripherieadresse 102 ?(wegen "P-Bereich , Wortzugriff, Zugriffsadresse: 102") ?
Bei Profibus CP's addressiert der CPU nicht direkt das Prozessabbild, sondern ein Zwischen-Daten Bereich der mit DP_SEND und DP_RECV geschrieben und gelesen werden. Deswegen deutet der Fehler "Peripherie-Zugriffsfehler, lesend" an dass das Problem ist zwischen CPU und CP, nicht zwischen CPU und die E/A.

Der CP342-5 hat auch ein interne Diagnose-Puffer, nicht mit der Diagnose Puffer in der CPU zu verwechseln.
Du kannst versuchen diese Diagnose-Puffer zu checken, ob da was steht.
Kann aber sein das der Verbindung zwischen CPU und CP total unterbrochen ist.

Ich kann mir gut vorstellen das es gibt irgendeiner obskure inkompatibilität zwischen VIPA CPU und Siemens CP342-5.


----------



## PN/DP (12 Oktober 2016)

@Larry Laffer
Ja Ralf, der Ausfall und die Wiederkehr von DP-Slaves darf für den DP-Master kein Problem sein. Es sei denn, die Kommunikation auf dem Profibus ist generell nicht mehr möglich, z.B. wegen elektrischen Störungen. Man kann ja mal schnell einen aktiven Abschlußwiderstand bei dem Funk-Gateway hinsetzen, oder einen Repeater zur elektrischen Trennung des Profibus des Masters zum Profibus am Gateway.

Harald


----------



## Hoppi (12 Oktober 2016)

@ Larry



Larry Laffer schrieb:


> ... warum oder wie verliert einer der Teilnehmer (Slaves) kurzzeitig physikalisch den Buskontakt ? Wird die Strecke irgendwie unterbrochen ?
> Gruß
> Larry



Die Funkstrecke des einen Slaves wird vermutlich hin und wieder kurzzeitig durch Wettereinflüsse unetrbrochen. Dies ist nicht weiter dramatisch da "nur" der Pegelstand eines Trinkwasserbehälter übertragen wird. Der Pegelstand des Behälters oder die Wertänderung des PEW ist extrem träge. Selbst ein Ausfall von 30min währen nicht weiter schlimm. Von daher darf der Master CP nach einer Unterbrechung m.m.n. ruhig wieder anlaufen.


----------



## Hoppi (12 Oktober 2016)

@PN/DP

im Einsatz steht eine 

https://www.epsystem.de/produkte/fernwirken-und-automatisieren/signamatic-ep600/

der CP-Master ist ein EP6-CP-21-12 von EP-Systemtechnik

VIPA ist ein OEM-Part von EP-Systemtechnik.

EP-Systemtechnik wiederum ist ein Unternehmen welches sich durch Ihre VIPA-OEM-SPS-Technik im bereich der Fernwirktechnik angesiedelt ist.

Die EP-600 Baugruppen sind dem der 300er-SPS bzw. der VIPA 200V physikalisch identisch. Jedoch wurde eine eigenene Fernwirk-Firmware von EP entwickelt.

Diese hauseigene Firmware wird letzendlich auf die OEM VIPA-Produkte als "Fernwirkkopf" oben aufgesetzt.

Programmiert wird in der Classik-Welt.


----------



## JesperMP (12 Oktober 2016)

Ein Profibus Master soll automatisch wenn der Fehler verschwindet wieder an den Bus anschliessen können. Also liegt es mMn. ein Problem in der Master CP.

Ich kenne nicht diese EP6-CP-21-12 und kann also nicht sagen ob es funktioniert wie ein Siemens CP342-5. 
Wenn der EP6-CP-21-12 funktioniert wie ein CP342-5, dann guck mal was ich in Eintrag # 15 geschrieben habe. 
Wenn der EP6-CP-21-12 nicht funktioniert wie ein CP342-5, dann musst du dich an der Hersteller wenden.

N.B. Es hätte auch schön gewesen sein wenn du das ganze System in den ersten Eintrag detailiert beschrieben hatte.


----------



## Hoppi (12 Oktober 2016)

Als nächste werde ich in den Hardware-Eigenschaften des PD-Slaves testweise den Hacken "Ansprechüberwachung" bei beiden Slaves entfernen. 

Ich bin gespannt ob der Fehler bei einer simmulierten DP-unterbrechung dann immer noch zu tragen kommt.


----------



## Hoppi (12 Oktober 2016)

JesperMP schrieb:


> N.B. Es hätte auch schön gewesen sein wenn du das ganze System in den ersten Eintrag detailiert beschrieben hatte.



Ich werde deinen Wunsch bei meiner nächsten Anfrage natürlich berücksichtigen. Hoffentlich meldet sich dann überhaupt noch jemand.

Ich werde bei nächster Gelegenheit als Versuch die "Ansprechüberwachung" in den Hardwareeigenschaften der Slaves ausschalten. Ich bin gespannt welches Verhalten sich mit dieser Änderung einstellt.


----------



## PN/DP (12 Oktober 2016)

Die "Ansprechüberwachung" hat mit Deinem Problem nichts zu tun. Sie sorgt dafür, daß der Slave in einen "sicheren" Zustand geht (z.B. seine Ausgänge abschaltet) wenn der Master ausfällt. Bei Dir friert der Master ein und nicht die Slaves.

Einen Profibus-DP muß man jederzeit an jeder beliebigen Stelle unterbrechen können und nachdem die Unterbrechung beseitigt ist, muß der Profibus von alleine wieder weiterlaufen, sprich der DP-Master muß die ausgefallenen DP-Slaves wieder aufnehmen. Wenn das nicht so funktioniert, dann funktioniert der Master nicht korrekt. Ruf den Hersteller Deiner SPS-Hardware an.

Harald


----------



## Larry Laffer (13 Oktober 2016)

Ich sehe das auch so wie Harald.
Eine Unterbrechung von z.B. der Funkstrecke würde ja auch die Terminierung des PB nicht beeinträchtigen.
Hier scheint es also ein generelles Problem zu geben. Zugegeben, wir sind da ggf. Siemens-verwöhnt. Ich kannte dieses von dir eingesetzte System bislang noch nicht einmal vom Hören-sagen.
Du solltest das wirklich mal mit dem Hersteller der HW besprechen - die werden dich wegen so einer Anfrage ganz sicher nicht "beissen" ...

Gruß
Larry


----------



## Hoppi (17 Oktober 2016)

Ich habe nun mit der Firma EP-Systemtechnik (unser Fernwirk-Vertragspartner) gesprochen.

Fazit: 

Da der Fehlerspeicher meiner SPS sagt:

Ereignis 1 von 100:  Ereignis-ID 16# 2942
Peripherie-Zugriffsfehler, lesend  
P-Bereich , Wortzugriff, Zugriffsadresse: 102
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse:  1
externer Fehler, kommendes Ereignis

sollte ich versuchen erst die Fehlermeldung in den zu beseitigen.

Wie schon beschrieben ist der OB122 jedoch definitif bestandteil des Progammes...auch Online.

Habe sogar den OB122 gelöscht und erneut gesetzt....keine linderung der Problematik

dei Fehlermeldung kommt erneut, immer wenn ich mein Profibus-Signal (künstlich kurzzeitig) Unterbreche.

Ich werde mich nochmal intensiv mit der Fehlermeldung beschäftigen müssen.......


----------



## JesperMP (17 Oktober 2016)

Das ist kein "Fazit" sondern ein Sachgasse. Diese Fehlermeldung kannst du ignorieren. Es kommt weil der CPU ein Adresse (102) nicht lessen kann, was nur logisch ist wenn der Profibus Verbindung unterbrochen ist.

Du musst den Hersteller fragen, warum der CP nicht automatisch den Verbindung wiederherstellt.


----------



## PN/DP (17 Oktober 2016)

JesperMP schrieb:


> Du musst den Hersteller fragen, warum der CP nicht automatisch den Verbindung wiederherstellt.


100% ACK *ACK*

Harald


----------



## Hoppi (17 Oktober 2016)

JesperMP schrieb:


> Das ist kein "Fazit" sondern ein Sachgasse. Diese Fehlermeldung kannst du ignorieren. Es kommt weil der CPU ein Adresse (102) nicht lessen kann, was nur logisch ist wenn der Profibus Verbindung unterbrochen ist.
> 
> Du musst den Hersteller fragen, warum der CP nicht automatisch den Verbindung wiederherstellt.




Ich fange an zu verstehen.....die Fehlermeldung OB122 s.o. ist der Grund weil auf meine Pheriepherie Slave nicht zurück gegriffen werden kann weil mein CP-Master nicht wieder anfängt zu arbeiten.

Der Fehlerablauf ist dann somit also:

1. Funkverbindung reißt kurz ab
2. somit kein Profibus-Signal
3.dann CP-Master ausfall
4. Programm möchte auf Slave-Werte (PEW´s) greifen
5. Keine Slave-Werte vorhanden weil CP-Master ausgefallen
6. dann

Peripherie-Zugriffsfehler, lesend  
P-Bereich , Wortzugriff, Zugriffsadresse: 102
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse:  1
externer Fehler, kommendes Ereignis

7. CP-Master bleib ausgefallen


----------



## PN/DP (17 Oktober 2016)

Richtig, bis 6. ist alles völlig normal.
Jetzt müßte einfach nur noch die Verbindung zum Slave wieder aufgebaut werden, sobald die Funkverbindung wieder hergestellt ist.

PS:
Test: ziehe mal am Master das Profibus-Kabel ab --> die Verbindung zu beiden DP-Slaves ist unterbrochen --> Kabel wieder anstecken --> beide Verbindungen müssen wieder aufgebaut werden --> keine Zugriffsfehler und keine roten Fehler-LEDs mehr

Harald


----------



## Ing_Lupo (17 Oktober 2016)

Hallo

und wenn nicht, halten sich die Teilnehmer nicht an die PNO Normen. Was bei der Zertifizierung geprüft wird. 

Deshalb mein Einwand vom Anfang.


----------



## Hoppi (15 Dezember 2016)

Aktueller Stand:

Phoenix Contact trifft die Aussage dass das Problem mit dem CP-Master von der EP-Systemtechnik Baugruppe EP-600  ausgeht.
EP-Systemtechnik trifft die  Aussage das dies am Funkmodul von Phoenix liegt.

Ich werde mich daher wohl zukünftig von beiden Herstellern etwas distanzieren. Weiterhin werde ich die Datenübertragung an diesem Punkt neu konzipieren.

Viele Köche verderben den Brei.

Vielen Dank an alle beteiligten Helfer und Berater!!!!

An den lieben Mod:

Das Thema kann von meiner Seite geschlossen werden.

Grüße

Hoppi


----------



## PN/DP (15 Dezember 2016)

Moin Hoppi,

Danke für die Information zum aktuellen Stand.

Hattest Du eigentlich mal ausprobiert was passiert, wenn der komplette Profibus direkt am Master abgezogen und wieder aufgesteckt wird? Wird da die Verbindung zu allen Slaves wieder aufgebaut oder passiert der Nicht-wieder-Aufbau zu dem einen Slave nur, wenn es die Funkstrecke betrifft?

Harald


----------



## Hoppi (15 Dezember 2016)

Hallo Harald,

wird auch nur ein Profibusteilnehmer vom Bus kurzzeitig entfernt kommt es zum gesamten
erliegen des BUS. Der Bus läuft erst nach einer Unterbrechung der Versorgungsspannung an der CPU wieder an.


----------



## PN/DP (15 Dezember 2016)

Hoppi schrieb:


> wird auch nur ein Profibusteilnehmer vom Bus kurzzeitig entfernt kommt es zum gesamten
> erliegen des BUS. Der Bus läuft erst nach einer Unterbrechung der Versorgungsspannung an der CPU wieder an.


Das spricht dann wohl eher für fehlerhaftes Verhalten des Master-CP

Harald


----------

