KRC1 Steuerung friert beim Wegnehmen von Profibussignalen ein

    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

    Einmal editiert, zuletzt von SJX ()

    • Schritt für Schritt zum Roboterprofi!

    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

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

    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 ^^

    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.

    Zitat von roemhild


    Wir haben das Problem gefunden.


    Der Fehler kam über den Bus von der SPS´s her.


    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

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

    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.

    Zitat von 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.


    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.

    never touch a running system

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden