Step 7 PB steigt sporadisch aus

[Hoffe69]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

habe ein Problem, dass mir an einer Anlage der PB sporadisch aussteigt.(Anlage läuft seit ca. 10 Jahren, Fehler ca. alle 2 Tage)

HW: S7 314C-2DP CP342-5 als Master an dem ein KUKA als Slave hängt. (Anlage hab ich nicht projektiert.Warum nen CP, wenn man PB Onboard hat?)

Hardwarediagnose ergibt einen Peripheriezugriffsfehler lesend im FC 102 und der OB 122 wird versucht aufzurufen, ist aber nicht programmiert(CPU geht in STOP).

Wenn ich die CPU auf STOP und danach wieder auf RUN stelle, läuft die Kommunikation und die CPU wieder.(Also ist doch nichts "richtig dauernd kaputt")

Fest steht, dass die CPU die Peripherie nicht lesen kann. Meine Frage ist jetzt: Wo fange ich an zu suchen oder Bauteile zu ersetzen? PB-Verkabelung habe ich überprüft. Terminierungswiderstände, Kabel und Stecker sind unauffällig. Kann es sein, dass der CP langsam anfängt sich zu verabschieden oder könnte es auch am Rückwandbus liegen?
(Ich muss zu meiner Schande gestehen, dass ich nicht darauf geachtet habe welche LED BF,SF geblinkt oder geleuchtet hat).

Hat jemand ne Idee, wie ich gezielt suche kann?

 

[vollmi]

Anfangen würde ich bei den typischen Objekten. Also Stecker und Kabel. das ein CP den Geist aufgibt gehört eher zu den seltenen Momenten (ich hatte noch keinen defekten).
Ist da nur ein PB Slave dran?
Schonmal einen Profibustester für ne Weile angehängt? Machen und Qualität überwachen.

mfG René

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auf welche E-Adresse wird denn der Peripheriezugriffsfehler gemeldet? Was ist unter dieser Adresse projektiert?
Profibus-/Teilnehmerausfall an CP342-5 erzeugen keine Peripheriezugriffsfehler, weil die Teilnehmer nicht im EA-Adressraum der CPU liegen.

Harald

 

[Hoffe69]

Der Fehler wird unter der Adresse 308 lesend gemeldet. Projektiert sind die Eingangsadressen 304 32 bit lang und die Ausgangsadressen 304 32 bit lang.

 

[Hoffe69]

Ich komme nur auf den CP, da wir das Problem kurz nach der Inbetriebnahme hatten. (ca. 10 Jahre her) Da kam nach dem Einschalten der Steuerung keine Kommunikation zustande. CP erneuert, ging.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Fehler wird unter der Adresse 308 lesend gemeldet. Projektiert sind die Eingangsadressen 304 32 bit lang und die Ausgangsadressen 304 32 bit lang.

Nochmal: Was ist unter der E-Adresse 308 projektiert? Da mußt Du suchen. "Eingangsadressen 304 32 bit lang" hat mit der gemeldeten Adresse 308 nichts zu tun.

Was macht der FC102? Kann es sein, daß da indirekt auf PE.. zugegriffen wird und da vielleicht ein selten auftretender Bug drin ist (z.B. falsche Verwendung von TEMP)?

Harald

 

[Hoffe69]

Der Lesefehler tritt an der Adresse 308 auf. Unter dieser Adresse ist der CP projektiert, welcher die Eingangs- und Ausgangsadresse 304 jeweils 4 Byte lang hat.
Der FC 102 liest vom PB ("DP_RESV") mit CPLADDR: W#16#130 (304dez) nach P#DB35.DBx0.0 (obwohl bei einem Any-Pointer die Anzahl Bytes noch angegeben werden müssten. Läuft aber schon so seit 10 Jahren).
Aber Moment mal. Nach den Angaben wird doch das Byte 304, 305, 306 und 307 gelesen. Der Fehler tritt bei Adresse 308 auf. Dieser ist aber gar nicht projektiert.
Könnte das die Ursache sein? Ich habe die Anlage nicht programmiert.

 

[Hoffe69]

Entschuldigung, ich gerade völligen Unsinn geschrieben.
Also als Slave hängt eine DP Karte von KUKA am CP. In der HW Konfiguration ist als Anfangsadresse des CPs die 304 angegeben. Die jeweilige Länge beträgt 32 Byte.
Der KUKA-Slave hat je 2 Ein/Ausgangsmodule jeweils 16 Byte breit. Ergibt jeweils eine Breite von 32 Byte pro Ein- oder Ausgang.
Jetzt liegt die Adresse 308, in welcher der Peripheriezugriffsfehler gemeldet wurde doch im Bereich 304 bis 335.
Oder habe ich jetzt schon wieder einen Denkfehler?

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst du den Inhalt von fc102 mal posten?


Sent from my iPhone using Tapatalk

 

[Hoffe69]

Der FC 102 wird im Programm von einem FC aufgerufen und liest den Eingangsbereich des CP in einen DB auf der CPU aus.

Call "DP_RECV" ; FC 102
CPLADDR:= W#16#130 ; 304 dez
RECV :=P#DB35.DBx0.0 ;hier müsste eigentlich noch die Länge des Zeigers angegeben werden, ist aber nicht
NDR :=M162.0
ERROR :=M162.1
STATUS :=MW164
DPSTATUS:=MB166

 

[vollmi]

Ich habe da früher auch immer eine länge angegeben. Aber wenn ich einen udt symbolisch anhänge, zeigt der mir absolut auch keine Länge an und funktioniert trotzdem. Aber dann siehts doch so aus als würde der cp sich vom rückwandbus verabschieden.


Sent from my iPad using Tapatalk

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist was im Kuka Slave etwas geändert geworden ?
in STEP7 auch der Hardware Diagnositcs checken, nicht nur der Diagnostics Puffer von der CPU. Leider sieht man bei der Hardware Diagnostics nur wenn ein Fehler aktiv ist.

RECV :=P#DB35.DBx0.0 ;hier müsste eigentlich noch die Länge des Zeigers angegeben werden, ist aber nicht

Wurde ich auch sagen. Und vielleicht hat es zu tun mit das der Fehler taucht auf nach den 4 Byte. Bin nicht sicher, aber man konnte denken das ohne Länge Angabe wird 4 Byte als Default verwendet.
Aber das erklärt nicht warum der Fehler taucht auf wenn das Anlage lange ohne Probleme lief.

 

[Hoffe69]

Vielen Dank für Eure Hinweise von gestern.
Die Anlage lief gestern dann den ganzen Tag durch ohne Probleme. Dann trat der Fehler heute morgen wieder auf. Der Peripheriezugriffsfehler war wieder an der gleichen Adresse (306. Da der OB 122 nicht programmiert war, ging natürlich die CPU in Stop ind die Anlage blieb da stehen, wo sie gerade war. Nach Neustert der Steuerung funktionierte die Kommunikation wieder, aber ich musste die Anlage neu referenzieren inclusive Roboter.nervig.
Jetzt habe ich den OB122, allerdings ohne Programmierung, eingefügt, damit im Störungsfall die Anlage ihren Zyklus zuende fahren kann. Der Roboter bearbeitet sein Teilprogramm auch noch zu Ende, bekommt aber dann aufgrund des fehlenden PB keine neue Anforderung. Jetzt stehe ich schon den ganzen Tag an der Anlage, um zu sehen was passiert, wenn der PB aussteigt. Die Anlage tut mir aber nicht den "Gefallen". Sie läuft ohne Fehler.
Da anzunehmen ist, dass der CP 342-5 einen hat, habe ich in der Zwischenzeit den CP rausprojektiert und den Slave an die integrierte DP-Schnittstelle projektiert.
Ich habe noch nicht umgestöpselt und die neue HW-Config noch nicht übertragen, weil------
--an der Anlage hängt noch ein TP170B mono welcher über MPI mit der CPU vernetzt ist. Dieser TP ist noch mit Pro-Tool programmiert, was ich nicht habe. Jetzt ist in meiner HW Konfig die CPU nicht MPI vernetzt, da das TP nicht in der HW-Konfig auftaucht. Ich besitze allerdings WINCC flexible 2008 SP3. Dieses hat mir ein HMI in mein Projekt eingefügt, mit den gleichen Inhalten wie unser TP.
Da ich mich mit WINCC überhaupt noch nicht beschäftigt habe, wollte ich wissen, ob die MPI-Verbindung CPU mit TP beim übertragen der HW-Konfig auf die CPU zerschossen wird. Es bringt mir ja nichts, wenn ich das Problem mit dem PB gelöst hätte, aber die Anlage nicht mehr bedienen kann.

Wäre schön, wenn jemand mir helfen könnte
Frank

 

[JesperMP]

Jetzt ist in meiner HW Konfig die CPU nicht MPI vernetzt, da das TP nicht in der HW-Konfig auftaucht.

HMI Panele werden nie in den HW Konfig eingefügt.
Ausnahme ist wenn Direkt-Tasten konfiguriert sind, aber dies habe ich in meinen 20+ Jahren Karierre nicht einmal gesehen.
In NetPro wird der HMI auftauchen, wenn es ein integrierte Projekt ist.

Wenn der MPI Addresse nicht geändert wird, dann wird es nicht schief gehen.

Sporadische Fehler können teuflich zu lokalisieren sein. besonders bei Profibus.
Wenn das Problem eventuell bei der Profibus selber ist, dann empfehle ich ein Profibus tester wie Profitrace. Dies kann man angeschlossen behalten und über die Dauer den Bus überwachen. Wenn ain Fehler auftaucht werden alle die Infomationen über der Fehler geloggt.

Gibt es den Möglichkeit das der Fehler ist in der Koka Roboter ?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
so, wie sich das für mich liesst, würde ich erstmal die Spannungsversorgung der beteiligten PB-Baugruppen und deren Potentialausgleich überprüfen.

Gruß
Larry

 

[MSB]

Fakt ist: Der CP oder die CPU oder irgendeine Baugruppe dazwischen macht irgend einen Scheiß auf dem Rückwandbus.
P.S. Der Fehler kann in dem Fall auch vom extern angeschlossenen MPI-Bus kommen.

Was du ausschließen kannst: jegliche Problem am Profibus des CP, darauf brauchst du folglich auch nicht zu warten.
Spannungsversorgung des CP wäre natürlich auch noch eine Möglichkeit.

Mfg
Manuel

 

[Verpolt]

MPI-Verbindungen werden in Netpro angelegt.
Bei 64bit OS und Step7 V5.5 + Flex 2008 SP3 wird dir die Protool MPI-Verbindung zur CPU in Netpro nicht angezeigt
Hast du beim Öffnen des Projekts einen Hinweis auf ein fehlendes Optionspaket (Protool)?

Evtl in 32 bit VM-ware / XPmode Sepp7 starten. (wenn vorhanden)
Dort müssten die Verbindungen sichtbar sein
oder Migration protool in Flex. Ggeht mW. nur mit bis WinCCflex 2008 SP2

Es kann sein, daß trotz neuer Hardwarekonfig (ohne HMI in Netpro) das HMI (Adr. 1) trotzdem über MPI mit der CPU (Adr.2) spricht.
Für einen Test wäre mir das an der Anlage aber zu heikel.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Entschuldigung, ich gerade völligen Unsinn geschrieben.

Entschuldige, aber auch Deine folgenden Aussagen passen irgendwie nicht

Also als Slave hängt eine DP Karte von KUKA am CP.

das ist unwichtig

In der HW Konfiguration ist als Anfangsadresse des CPs die 304 angegeben. Die jeweilige Länge beträgt 32 Byte.

Ich kenne keinen CP342-5, den man so einstellen könnte, daß er je 32 Byte E/A-Adressen belegt. Da sollte unabänderbar ein Länge von 16 Byte fest eingestellt sein. Der CP würde dann die Adressen E304...319 und A304..319 belegen.
Kannst Du mal Deine HW Konfig zeigen? Wo der CP342-5 im Rack zu sehen ist? Oder die Adressübersicht?
Ein Bild wo man Deine Vernetzung der Profibus- und MPI-Schnittstellen sieht (z.B. von NetPro) wäre auch nicht schlecht

Der KUKA-Slave hat je 2 Ein/Ausgangsmodule jeweils 16 Byte breit. Ergibt jeweils eine Breite von 32 Byte pro Ein- oder Ausgang.

Das hat ebenfalls nichts mit den E/A-Adressen des CP342-5 zu tun

Jetzt liegt die Adresse 308, in welcher der Peripheriezugriffsfehler gemeldet wurde doch im Bereich 304 bis 335.
Oder habe ich jetzt schon wieder einen Denkfehler?

In der Tat liegt die Adresse 308 im E/A-Bereich des CP, wenn dieser die Anfangsadresse 304 hat.
In HW Konfig kann man sich eine Liste der belegten E/A-Adressen anzeigen lassen: Ansicht > Adressübersicht... (Ctrl+U)
In der Adressübersicht dann bei "Adressen von:" die CPU auswählen!

Ich würde sagen, der CP342-5 selber hat eine "Macke". Ich würde den einfach mal austauschen.
(Theoretisch könnte auch die CPU eine Macke haben, der Austausch der CPU ist aber aufwändiger.)
Wie MSB schon schrieb, kann der Fehler aber auch vom MPI-Bus kommen.

Ich würde nun nicht alles umprojektieren und umbauen, sondern die Fehlerursache suchen und beseitigen.

Harald

 

[Gerhard K]

Hab jetzt nicht alles gelesen, aber hast du IM 151 bei der Anlage eingebaut??

 

[Hoffe69]

Danke Verpolt,

es ist tatsächlich so, dass mit Step 7 beim Öffnen des Projektes eine fehlende Pro-Tool Installation anmeckert. Das Beste wäre es, das HMI nach flexible 2008 zu migrieren, damit ich auch selber mal was an dem TP ändern kann.(Anlage wurde 2004 fremdprogrammiert und Programmierer nicht mehr greifbar)
Wie ich das mache weiß ich noch nicht, da ich bisher gar nichts mit flexible gemacht habe.
Flexible hat mir ja schon eine HMI Station in mein Projekt eingefügt. Wenn ich diese öffne, sehen die einzelnen Seiten und Bilder genau so aus wie auf dem TP. Dieses HMI ist allerdings noch nicht vernetzt. Das Pro-Tool TP ist unter S7 5.5 SP3 nicht sichtbar.