21. Januar 2019, 06:30:07
Roboterforum.de - Die Industrieroboter- Anwender und Experten Community

[gelöst] KRC1 Steuerung friert beim Wegnehmen von Profibussignalen ein


normal_post Autor Thema: [gelöst] KRC1 Steuerung friert beim Wegnehmen von Profibussignalen ein  (Gelesen 1010 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

28. November 2018, 15:07:48
Gelesen 1010 mal
Offline

roemhild


Hi,

Ich bin zwar schon über einige ähnliche Themen hier gestlpert aber leider waren doch alle ein wenig anders.

Zunächst die Grundsituation:
Eine bestehende Anlage mit 4 Robotern (3x KRC1, 1xKRC2) wurde um einen Roboter(KRC4) erweitert. Erst mal kein Hexenwerk. Jedoch haben sich nur 3 der 4 Roboter wieder in Betrieb nehmen lassen. Einer der KRC1 Roboter hat ganz offensichtlich ein Problem mit den Profi Bus:

Starte ich den Roboter ohne angestecktes Profibuskabel, dann startet der Roboter ohne Probleme. Stecke ich nun das Kabel an und das Signal "Move_Enable" ist true ist alles schön. Ist es aber False oder wird dann auf False gesetzt, reagiert das Panel auf keine Taste mehr und man sieht kurzzeitig das im Meldungsfenster eine Zeile flackert, bzw im Hohen Takt sich 2 Meldungen abwechseln. Die eine ist "Quit Fahrfreigabe" die andere kann man nicht lesen (ich vermute aber "Fahrfreigabe gesamt")  und nach ca 30 Sekunden friert die Steuerung ganz ein.

Starte ich den Roboter mit angesteckten Profibuskabel, dann tritt folgendes Phänomen auf:

Move_Enable = False  --> Steuerung bleibt bei der Initialisierung hängen
Move_Enable = True  --> Steuerung startet Problemlos, aber fehlerbild von oben setzt ein beim wegnehmen der Fahrfreigabe

Von Kuka kam nach mehreren Tagen nun keine Lösung und daher wende ich mich nun an euch, bitte helft mir

Gruß

Michael
« Letzte Änderung: 30. November 2018, 10:16:45 von SJX »
  • gefällt mir    Danke

Heute um 06:30:07
Antwort #1

Werbung

Gast

28. November 2018, 17:37:35
Antwort #1
Offline

SJX

Global Moderator
Softwarestand der KRC1?
Was für ne Profibuskarte hast Du drin?
Auch der Fall, wenn SPS Prog gestoppt / manuell Signale / Move_enable forcen?
Irgendwelche CMD Kommandos im Submit / passierts auch mit abgewähltem Submit?
Kannst Du mal ein Archiv posten?
Hat KUKA ein CrossLog ausgewertet / angefordert?

Gruss SJX
  • gefällt mir    Danke
Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

28. November 2018, 18:06:22
Antwort #2
Offline

roemhild


BOF Version: V3.3.79 B31 (V)KRC1 V3.3/V4.1
Grundsystem Version: KS V4.97

PB-Karte: CP5614

Der Fehler tritt nur im Bezug Move_enable auf, egal auf welche weise es geschaltet wird, ob über Automatik oder per Hand

Kuka hat noch nichts weiter verlangt außer einem Archiv
auch mit abgewählten Submit tritt der fehler auf
Bei dem Archiv das Datum mal ignorieren, es ist von gestern ^^
  • gefällt mir    Danke

29. November 2018, 09:16:06
Antwort #3
Offline

Hermann


Vom Fehlerbild ausgehend vermute ich, dass das Signal von der SPS her nicht dauerhaft auf 0 liegt, sondern sehr schnell hin- und herwechselt. Dadurch kommt es zu einem Überlauf des Meldepuffers.
Um hinter den Fehler zu kommen:
würde ich mal das move_enable Signal auf einen anderen Eingang legen, der sicher dauerhaft auf 0 liegt (unbelegter Eingang, z.Bsp. 1000).
Und evtl. in der pfbms.ini ERROR_ACTION auf 1 setzen.
  • gefällt mir    Danke

29. November 2018, 09:23:24
Antwort #4
Offline

roemhild


Wir haben das Problem gefunden.


Der Fehler kam über den Bus von der SPS´s her.
  • gefällt mir    Danke

Heute um 06:30:07
Antwort #5

Werbung

Gast

29. November 2018, 11:21:14
Antwort #5
Offline

SJX

Global Moderator

Der eine oder andere würde es interessieren, was genau die Ursache SPS-seitig war.

Noch so als Tipp:
- Räum mal den Log-Ordner auf. Bläst Dein Archiv künstlich auf und kann zu Archivierungsfehlern führen. Aktuell gerade an max. Diskettengrösse. Meiner Meinung nach ist z.B. Ordner C\KRC\Roboter\Drivers schon nicht komplett, vermisste hier z.B. den pfbmsdrv.o , Treiber für den Profibus.
- Stell das Datum richtig. Kann zu dummen Fehlern mit der Meldungsausgabe / kukalog.mdb bei der V4.1 führen.

Gruss SJX

  • gefällt mir    Danke
Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

29. November 2018, 13:54:12
Antwort #6
Offline

roemhild


Move_enable wurde noch von einen zweiten versteckten Baustein in der SPS angesteuert, wodurch mit jeden Zyklus das Signal am Anfang weggenommen wurde und am ende wieder auf true gesetzt wurde, Ergebnis waren 2 Wechsel in weniger als einer Sekunde. Durch die ständigen Signalwechsel ist der Meldepuffer vollgelaufen und dadurch wiederum die Steuerung eingefroren.
  • gefällt mir    Danke

29. November 2018, 18:35:40
Antwort #7
Offline

Otto Sieben


Das Problem scheint mir nicht gelöst, irgendwas stimmt da nicht. Eine SPS schreibt das Prozessabbild der Ausgänge immer nur am Ende eines Zyklusses auf den Bus. Ausnahme: Direkter Perepheriezugriff. Das heißt, selbst wenn der Status von MoveEnable innerhalb des SPS Zyklusses wechselt, so wird dies nicht zwischendurch auf den Bus übertragen.  Ich vermute mehr ein Problem mit Doppelzuweisungen auf den Ausgang, am besten diesen Ausgang mal komplett referenzieren.
  • gefällt mir    Danke
never touch a running system


Teile per facebook Teile per linkedin Teile per pinterest Teile per reddit Teile per twitter
 

über das Roboterforum

Nutzungsbedingungen Impressum Datenschutzerklärung

Sponsoren des Roboterforums

ROBTEC GmbH