Peripherie Zugriffsfehler

[hoelle1985]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey @ all,

folgendes Problem habe ich seit gestern an einer Anlage.

Die Anlage hat eine CPU316 2DP mit mehreren ET200 Stationen.

Seit gestern habe ich Störungen an der Anlage. Beim Auslesen des Diagnosepuffers ist herausgekommen, dass es in unregelmäßigen Abständen zu Peripherie Zugriffsfehlern kommt. Allerdings immer nur ganz kurz und immer an anderen ET200 Stationen.

Die Stationen kommt auch immer wieder sofort zurück ins System. Ausfall und Wiederkehr passiert innerhalb von 100ms.

Meine Vermutung liegt darin, dass die CPU einen Schaden hat. Was meint Ihr?

Diagnosepuffer der Baugruppe CPU 316-2 DP

Bestell-Nr./ Bezeichn. Komponente Ausgabestand
6ES7 316-2AG00-0AB0 Hardware 1
- - - Firmware V 1.2.0


Baugruppenträger: 0
Steckplatz: 2
Ereignis 1 von 10: Ereignis-ID 16# 38C4
Dezentrale Peripherie: Station Wiederkehr
Adresse des betroffenen DP-Slaves: Stationsnummer: 17
DP-Mastersystem-ID: 1
Log. Basisadresse des DP-Slaves: Eingangsadresse: 2038
Log. Basisadresse des DP-Masters: Eingangsadresse: 2047
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
Prioritätsklasse: 26
externer Fehler, gehendes Ereignis
10:19:37.913 26.03.2012
(Kodierung: 16# 38C4 1A56 C054 07FF 07F6 0111)




Ereignis 2 von 10: Ereignis-ID 16# 2943
Peripherie-Zugriffsfehler, schreibend
P-Bereich , Wortzugriff, Zugriffsadresse: 288
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse: 1
externer Fehler, kommendes Ereignis
10:19:37.817 26.03.2012
(Kodierung: 16# 2943 017A 0020 0120 0000 0000)




Ereignis 3 von 10: Ereignis-ID 16# 2943
Peripherie-Zugriffsfehler, schreibend
P-Bereich , Wortzugriff, Zugriffsadresse: 286
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse: 1
externer Fehler, kommendes Ereignis
10:19:37.816 26.03.2012
(Kodierung: 16# 2943 017A 0020 011E 0000 0000)




Ereignis 4 von 10: Ereignis-ID 16# 2943
Peripherie-Zugriffsfehler, schreibend
P-Bereich , Wortzugriff, Zugriffsadresse: 288
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse: 1
externer Fehler, kommendes Ereignis
10:19:37.718 26.03.2012
(Kodierung: 16# 2943 017A 0020 0120 0000 0000)




Ereignis 5 von 10: Ereignis-ID 16# 2943
Peripherie-Zugriffsfehler, schreibend
P-Bereich , Wortzugriff, Zugriffsadresse: 286
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse: 1
externer Fehler, kommendes Ereignis
10:19:37.718 26.03.2012
(Kodierung: 16# 2943 017A 0020 011E 0000 0000)




Ereignis 6 von 10: Ereignis-ID 16# 2943
Peripherie-Zugriffsfehler, schreibend
P-Bereich , Wortzugriff, Zugriffsadresse: 288
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse: 1
externer Fehler, kommendes Ereignis
10:19:37.619 26.03.2012
(Kodierung: 16# 2943 017A 0020 0120 0000 0000)




Ereignis 7 von 10: Ereignis-ID 16# 2943
Peripherie-Zugriffsfehler, schreibend
P-Bereich , Wortzugriff, Zugriffsadresse: 286
Angeforderter OB: Peripheriezugriffsfehler-OB (OB 122)
Prioritätsklasse: 1
externer Fehler, kommendes Ereignis
10:19:37.618 26.03.2012
(Kodierung: 16# 2943 017A 0020 011E 0000 0000)




Ereignis 8 von 10: Ereignis-ID 16# 39C4
Dezentrale Peripherie: Station Ausfall
Adresse des betroffenen DP-Slaves: Stationsnummer: 17
DP-Mastersystem-ID: 1
Log. Basisadresse des DP-Slaves: Eingangsadresse: 2038
Log. Basisadresse des DP-Masters: Eingangsadresse: 2047
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
Prioritätsklasse: 26
externer Fehler, kommendes Ereignis
10:19:37.582 26.03.2012
(Kodierung: 16# 39C4 1A56 C054 07FF 07F6 0111)




Ereignis 9 von 10: Ereignis-ID 16# 38C4
Dezentrale Peripherie: Station Wiederkehr
Adresse des betroffenen DP-Slaves: Stationsnummer: 10
DP-Mastersystem-ID: 1
Log. Basisadresse des DP-Slaves: Eingangsadresse: 2032
Log. Basisadresse des DP-Masters: Eingangsadresse: 2047
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
Prioritätsklasse: 26
externer Fehler, gehendes Ereignis
10:12:59.445 26.03.2012
(Kodierung: 16# 38C4 1A56 C054 07FF 07F0 010A)




Ereignis 10 von 10: Ereignis-ID 16# 39C4
Dezentrale Peripherie: Station Ausfall
Adresse des betroffenen DP-Slaves: Stationsnummer: 10
DP-Mastersystem-ID: 1
Log. Basisadresse des DP-Slaves: Eingangsadresse: 2032
Log. Basisadresse des DP-Masters: Eingangsadresse: 2047
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
Prioritätsklasse: 26
externer Fehler, kommendes Ereignis
10:12:59.376 26.03.2012
(Kodierung: 16# 39C4 1A56 C054 07FF 07F0 010A)

 

[Paule]

Meine Vermutung liegt darin, dass die CPU einen Schaden hat. Was meint Ihr?

Mein erster Tipp wäre:
Buskabel defekt (verletzt, wackler, lockere Klemme, ...)

 

[Manuel137]

Zuviel Werbung?
-> Hier kostenlos registrieren

Buskabel , würde ich auch mal checken

habe eigentlich selber noch keine defekt siemens cpu gesehen ,die im betrieb verrecken

 

[Larry Laffer]

Hallo,
ich würde mir darüber hinaus auch vielleicht mal die Versorgungsspannung der betroffenen Slaves anschauen - also welche Spannung liegt an und ist die vielleicht "ein wenig" EMV-belastet ?

Gruß
Larry

 

[Tigerente1974]

Wenn die Anlage schon länger unverändert läuft, unbedingt auch das Umfeld einbeziehen. Z.B. Große Verbraucher die aufgestellt wurden, neu verlegte Kabel im gemeinsamen Schacht, etc...
Die Busstecker sind i.d.R. auch ein Kandidat. Hat evtl. jemand an den Terminierungsschaltern gestellt? Sicherheitshalber auch da noch einmal checken.

 

[hoelle1985]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also die Anlage lief 5 Jahre ohne Probleme und es wurde auch nichts verändert.

Die Bus Kabel hatte ich in Verdacht, allerdings ist immer wieder auf eine andere Station kein Zugriff möglich und das auch nur für ca. 100 ms. Wäre da ein Wackelkontakt oder ähnliches würde der Fehler länger anliegen und der Teilnehmer würde sich nicht sofort wieder kommen. Ich hatte es bis jetzt noch nicht einmal das zweimal hintereinander die gleiche Station ausgefallen ist. Der Rest der Anlage läuft auch ohne weiteres weiter, nur auf die Station kann nicht mehr Zugegriffen werden.

Das Problem ist das die Anlage das gesamte Werk versorgt und der Handbetrieb scheinbar nicht wirklich funktioniert.

Wir werden zuerst die CPU tauschen weil es doch am wahrscheinlichsten scheint aufgrund der Tatsache das immer andere Stationen ausfallen, dies nur für einen sehr kurzen Augenblick passiert. Selbst der Frequenzumrichter hat sich einmal kurz abgemeldet und ist dann wieder innerhalb von wenigen ms zurückgekommen.

Muss am Panel halt noch ein wenig quittiert werden bis der Tausch vollzogen ist .

 

[Dr.M]

Hatte mal so was ähnliches. Bei mir wars ne Beckhoff Klemme die als DP-Slave ne Kopplung zu ner anderen Anlage herstellte. Die störte alle 30-40 min den Bus dermaßen, dass einige Teilnehmer für 200-300 ms ausfielen. Tödlich wenn F-Technik im Einsatz is

 

[Deltal]

Ich würde erstmal prüfen ob die Abschlusswiderstände i.O. sind. Ich hatte einmal einen Reperatureinsatz wo ein Bediener die Terminierung ausgeschaltet hat, weil das Bedienpult auch als Aufbewahrungsort für seine Pausenbrot-Tasche diente.

Ganz übel sind die Fälle wo ein Slave den Bus stört, da braucht man viel Glück oder ein gutes Messgerät.

 

[rekrue]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
möchte das Thema nochmal aufrufen, da ich jetzt ein ähnliches Problem habe: Anlage ist ca. 5 Jahre alt, und es kommt zu einen (fast) sporadischen Ausfall von nur einer ET200S-Station von 14 Stationen. Die Station fällt aus (hex 39c4) und meldet kurz darauf wieder Ok (hex 38c4). An der Anlage wurde nichts geändert. Im selben Schrank befindet sich noch eine weitere ET200S-Station die davon nicht betroffen ist, daher würde ich erstmal die Spannungsversorgung ausschließen. PB-Stecker ist ein älteres Siemens-Modell (972-0BA50-0XA0), die andere Station hat den PB-Stecker (972-0BA51-0XA0). Da es eine 24/7 Anlage ist, kann ich so ohne weiteres nicht mal schnell etwas testen. Die IM151 wurde vor 3 Wochen getauscht ohne Erfolg. Mir bleibt da jetzt noch die Busverbindung (PB-Stecker sind bestellt) und die Spannungsversorgung. Den FB125 (Diagnose-FB) habe ich jetzt mit eingebunden um evtl. ein Modulfehler zu detektieren. Vielleicht noch andere Ideen?

 

[ThreeSixty]

Ich weiß der Thread ist schon Uralt aber ich bin heute auf das gleiche Problem gestoßen, deswegen wollte ich keinen neuen Thread aufmachen.

Wenn ich nur mit PLCSIM arbeite momentan, kann es dann sein das er die Physikalische Hardware einfach nicht findet, da sie programmiert aber nicht vorhanden ist?

MFG

 

[emtewe]

Tja, ich habe auch ein interessantes Problem mit einem Peripherie Zugriffsfehler, und wollte dazu keinen neuen Thread aufmachen.

Es geht um eine CPU 314C-2 PN/DP.
Das Problem ist, ich bekomme einen Peripherie Zugriffsfehler, ohne Busfehler.
Die LED SF leuchtet, im Ferhlerspeicher sind die Meldungen 16#2943 und 16#2942 zu finden, aber es scheint kein Busfehler vorzuliegen. Die LEDs BF1 und BF2 sind dunkel, nur SF ist da.
Die Anlage läuft seit 3 Jahren ohne Probleme, am gleichen Ort sind noch 50 weitere Anlagen gleicher Bauart, normalerweise bei Profibusstörung sind immer SF und BF1 an, diesmal nur SF.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Problem ist, ich bekomme einen Peripherie Zugriffsfehler, ohne Busfehler.

Das muss ja nicht zwingend mit einem Busfehler zusammenhängen. Es müsste doch dran stehen, bei welcher Adresse er ein Problem hat
z.B. Lesend oder schreibend => Adresse 256

 

[PN/DP]

Auf welche Peripherieadresse zugegriffen werden soll steht in dem Diagnosepuffereintrag.
Stehen da nur ein paar Zugriffsfehler-Einträge (wie ist Datum/Uhrzeit der Einträge?) oder läuft der Diagnosepuffer über, weil jede Sekunde zig Einträge dazukommen?

Hast Du was am Programm gemacht? Was?

Harald

 

[emtewe]

Danke schonmal für die Antworten!

Die Anlage steht beim Kunden, der hat (angeblich) nichts geändert.
Der Diagnosepuffer läuft über mit Einträgen, die Adresse bezieht sich auf ein Profibusgerät.

Ich habe auf der SPS den Webserver aktiviert, der Kunde konnte den Diagnosbuffer als CSV runterladen und schicken.
Da drin steht einmal der 16#38C4, und sonst nur die ganzen Zugriffsfehler lesend und schreibend.

Für mich wäre alles klar und einfach, wenn der Busfehler dazu käme, der fehlt aber merkwürdigerweise.
Ich habe den Kunden angewiesen das entsprechende Gerät mal zu tauschen. Er hat mehrere gleichartige Anlagen. Mal sehen ob der Fehler mit diesem Profibusgerät wandert, oder an der Anlage bleibt.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

und sonst nur die ganzen Zugriffsfehler lesend und schreibend

Ja, und hier wäre es halt wichtig nachzuschauen, um welche Adresse es sich handelt. Steht ja dabei.
Dann kann man diesen Fehler auch einem Gerät zuordnen.

 

[emtewe]

Habe ich ja, alle lesenden und schreibenden Peripheriezugriffsfehler sind einem einzigen Profibusteilnehmer zugeordnet. Der deckt einen gewissen Bereich ab (je 4 Doppelworte Eingang und Ausgang) und all diese Adressen tauchen im regelmäßigen Zyklus auf. Das wäre für mich ein ganz klarer Busfehler, wenn die BF1 LED noch an wäre...

 

[PN/DP]

Ist der betreffende Profibusteilnehmer mit SFC12 D_ACT_DP deaktiviert und es wird trotzdem noch auf die Peripherie-E/A-Adressen des Teilnehmers zugegriffen?

Vielleicht ist die BF1-LED oder deren Ansteuerung kaputt?
Man könnte mal einen anderen Profibusteilnehmer vom Bus trennen und schauen ob dann die BF1-LED leuchtet.
Oder die CPU spannungslos machen, dann beim wieder Zuschalten der 24V müssen ein paar Sekunden lang alle 8 Status-LED der CPU leuchten.
Bei Zielsystem > Baugruppenzustand im Register "Allgemein" steht unten bei Status welche Fehler-LED leuchten.

Harald

 

[Fabpicard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das wäre für mich ein ganz klarer Busfehler, wenn die BF1 LED noch an wäre...

Die BF1 sollte aber nur so lange an sein, wie der Bus-Fehler auch ansteht... Gibt ja keine Möglichkeit den zu quittieren außer das die Meldung wieder gegangen ist.
Kommt jetzt dieser Zugriffsfehler ständig aber nicht dauerhaft, muss die auch nicht leuchten

MfG Fabsi

 

[emtewe]

Die BF1 sollte aber nur so lange an sein, wie der Bus-Fehler auch ansteht...

Ja, der SF aber auch. Bei einen Problem an der Profibusverdrahtung gehen normalerweise beide LEDs gemeinsam an und je nachdem auch gemeinsam wieder aus, wenn der Fehler nicht mehr ansteht.

Ich habe den Kunde jetzt angewiesen mal einen anderen, leicht zugänglichen, Busteilnehmer zu lösen. Mal schauen ob dann der BF1 dazu kommt. Da sich der Kunde seit Freitag nicht mehr gemeldet hat, ist das Problem inzwischen wahrscheinlich sowieso wieder verschwunden.