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

Hoppi

Level-1
Beiträge
20
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 

Anhänge

  • BUS-Topologie.pdf
    164 KB · Aufrufe: 73
  • 1Unbenannt.PNG
    1Unbenannt.PNG
    17,2 KB · Aufrufe: 89
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
 
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!!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
 
Zuletzt bearbeitet:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
@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 ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
@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
 
@ Larry

... 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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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.
 
Zuletzt bearbeitet:
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.
 
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.
 
Zurück
Oben