Profibusfehler im Slavekreis - CPU geht in Stop

s_alpen

Level-1
Beiträge
11
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusamen,

ich arbeite gerade an einem Projekt, bei dem eine ET200 und eine Robotersteuerung über eine CP 5614 Slave über Profibus mit einer CPU 315-2DP kommunizieren sollen. Habe die Teilnehmer im HW-Manager projektiert...siehe Bild im Anhang

Die Kommunikation steht also soweit und die Daten werden ausgetauscht. Sobald ich den Profibusstecker von der CPU abziehe, geht diese in STOP.

Dieses Verhalten möchte ich gerne verhindern. Zu diesem Thema habe ich schon einiges hier im Forum gelesen und habe dementsprechend die Bausteine OB82, OB86 und OB122 eingelesen.

Jedoch zeigen diese keine Wirkung und die CPU geht trotzdem in STOP. Habe ich bei der Projektierung noch etwas vergessen?

Vielen Dank dür Eure Hilfe...
 

Anhänge

  • Konfig_DP_Mastersystem.png
    Konfig_DP_Mastersystem.png
    12 KB · Aufrufe: 44
Was sagt denn das Alarmlogging WARUM sie auf STOP geht?

Und warum willst Du den Stecker abziehen? ohne den läuft doch der Bus nicht... ;)
 
hallo,

das Alarmlogging kenne ich nur aus WinCC. Mit dem Stecker abziehen sollte ein Beispiel sien und representativ für den ausfall der Et200 oder Slavekarte sein. Neben den Teilnehmern am Bus, werden auch E/A Karten direkt an der CPU betrieben.

Wenn der Bus ausfällt, soll die CPU mit den lokalen E/As weiter arbeiten können.

Habe jetzt gerade noch einmal im Handbuch nachgeschlagen.

OB82 -Diagnosealarm (z.B. Kurzschluss in der Eingangsbaugruppe)
OB86 -Baugruppenträherausfall
OB87 -Kommunikationsfehler (z.B. falsche Telegrammkennung bei Globaldaten-Kommunikation)
OB 122 -Peripheriezugriffsfehler (z.B. Zugriff auf eine Signalgruppe. die nicht vorhanden ist

Ich werde gleich mal hoch in Halle und den OB87 testen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Soweit mir bekannt, kommt dies bei Kuka öfters :cool:

Da war doch mal etwas wegen der GSD bzw. der Karte welche im Kuka steckt! Kollegen haben mal deshalb auf DP/DP umgestellt!

Ist aber schon nen weilchen her ...
 
Kellerprogrammierer ja, aber Fenster sind genügend da :).
Öfters kommen auch schonmal Hasen vorbei gehoppelt...

Naja, Spass bei Seite
Habe gerade mal den OB87 mit geladen. Aber leider ohne Erfolg.

Das sagt der Diagnosepuffer dazu:

STOP: Inkonsistenz der Projektierungsdaten
aufgetreten bei Prüfung von Parametern für interne Konsistenz
kein Konsistenzeintrag zuordenbar
Fehlerart: Parameterblock nicht vollständig
Bisheriger Betriebszustand: ANLAUF (Neustart/Warmstart)
Angeforderter Betriebszustand: STOP (intern)
externer Fehler, kommendes Ereignis
09:34:11.444 01.07.2011

Also scheint etwas nicht richtig projektiert zu sein, oder?
Wäre für einen Denkanstoß sehr dankbar!
 
Das ist glaube ich ein Fall für den OB85.

Das Betriebssystem der CPU ruft den OB 85 auf, wenn eines der folgenden Ereignisse auftritt:
· Startereignis für einen nicht geladenen OB (außer OB 80, OB 81, OB 82, OB 83 und OB 86)
· Fehler beim Zugriff des Betriebssystems auf einen Baustein
· Peripheriezugriffsfehler bei der systemseitigen Aktualisierung des Prozessabbilds, falls der OB 85-Aufruf nicht per Projektierung unterdrückt wurde.
 
Zurück
Oben