"STOPP wegen Betriebsartenwechsel"

    Hallo zusammen,


    ich habe einen Roboter bei einem Kunden stehen.
    Am Wochenende war ich dort für eine Programmänderung.


    Beim Programmtest kam es viermal sporadisch vor, dass der Roboter NICHT-BAHNTREU gestoppt hat (war ziemlich unschön!).


    Fehlermeldung:
    1362 "STOPP wegen Betriebsartenwechsel"
    108 "Drehzahl-STOPP aktiv"
    220 "Antriebe aus, Zwischenkreisspannung noch geladen"
    1140 "Satzwechsel bei STOPP"
    310 "Antriebsfreigabe fehlt (extern)"
    203 "Fahrfreigabe gesamt"
    364 "Ungültige Betriebsart (?)"


    Ausschlaggebend war wohl "STOPP wegen Betriebsartenwechsel". Es hat jedoch niemand etwas gemacht.
    Und eigentlich sollte hier der Roboter ja bahntreu stoppen!?
    Danach war der Spuk vorbei. Ist das einem von Euch auch schon passiert?


    Zuerst dachte ich, dass eine Überwachung über die SPS zugeschlagen hat, da ich dem Roboter die Fahrfreigabe
    via Profibus wegnehme, wenn ein bestimmter Pulsor an der Anlage frei wird (Greifer könnte dann in seinem Fahrbereich sein).
    Doch in diesem Fall würde ja ein "Fahrfreigabe gesamt" am KCP auftauchen und der Roboter würde BAHNTREU stoppen.


    Woran kann das gelegen haben? KCP defekt? Es ist wohl schon mal runtergefallen (zumindest sieht es nimmer neu aus)!


    Gruß
    Stefan

    • Schritt für Schritt zum Roboterprofi!

    Hallo Schui,


    wegen des nicht-bahntruen Notaus:
    Kontrollier mal in R1/$machine.dat den Wert $EMSTOP_PATH. Da ist in Abhängigkeit von der Betriebsart konfiguriert ob der Notaus Bahntreu oder nicht bahntreu (d.h. Drehzahlstopp) ausgeführt werden soll.


    Ansonsten kann es auch bei einem bahntreuen Notaus vorkommen, dass während des Stopps auf Drehzahlstopp umgeschalten werden muss, da die Notausrampe zu starke Verzögerungen hervorruft, die Momentengrenzen des Roboters verletzen. Eventuell kannst du dazu in R1/$robcor.dat mal auf $EMSTOP_ADAP schauen. Steht da true drin ist die Notausrampe modellbasiert und in eurer Anwendung könnten dann die Lastdaten nicht korrekt programmiert sein.


    Gruß
    Fubini

    Hallo,


    wenn es eine KRC1 ist, könnte es vielleicht die FE201-Karte sein (ein Schütz-Problem, weil die Fehlermeldung: Ungültige Betriebsart (?) kam, das würde mir auch erklären, wieso es zu dem Problem kam, obwohl niemand am Betriebsartenschalter gedreht hat). Oder Kabelbruch der Leitung zum KCP, vielleicht mal vorsichtig die Leitung am Leitungsaustritt des KCP bewegen.


    Gruß


    PA

    Hallo,


    Fubini:
    Habe die Variable in der STEU/Mada/$machine.dat gefunden:


    DECL EMSTOP_PATH $EMSTOP_PATH={T1 #ON,T2 #ON,AUT #ON,EX #ON}
    ;PROJEKTIERUNG DES BAHNTREUEN NOT-AUS FUER T1,T2,AUT,EX


    Sollte eigentlich passen.


    In R1/Mada/$robcor.dat steht:


    BOOL $EMSTOP_ADAP=TRUE ;NOT-AUS MIT DYNAMIKMODELL


    Daran könnte es liegen!?


    PA:
    Es handelt sich um eine KRC2-Steuerung. Aber ein Problem mit dem KCP könnte es doch dennoch sein? Das würde doch auch die Meldung "STOPP wegen Betriebsartenwechsel" erklären.


    Gruß
    Stefan

    Hallo, schui74,


    es könnte durchaus das KCP sein. Mal die Leitung, wie beschrieben, bewegt? Wenn das KCP schon mal runtergefallen ist, kann auch an der Verdrahtung drinnen was kaputt sein. Ich habe mir mal sagen lassen, dass man das Ding besser nicht selbst aufschraubt, weil einem im Extremteil Teile entgegenkommen.


    Gruß


    PA

    Hallo,


    die Meldung ungueltige Betriebsart bekommst du dann nur durch einen Reset vom ESC-Board weg?
    KCP. Leitung oder Stecker sind nicht auszuschliessen - ich wuerde aber ein Relais auf dem ESC-Board verdaechtigen.


    Der nicht bahntreue Stop ist in diesem Fall normal.


    Aehnlich rustikal kann man den Roboter mit der SPS stoppen. $Drives_off = 0 - gibt einen Bahnnahmen Notaus mit fixed ramps.



    Gruss Stefan

    Hatte neulich auch so ein Problem. An einem neuen Roboter.
    Hat sich dann rausgestellt das das neue KCP defekt war.
    Antriebe I-Taste war defekt. (Hatte dauerhaft Kontakt).


    Bin 1000 km zum Kunden gefahren deswegen :wallbash:. Neues KCP und alles war OK.


    Gruß Roland

    Hallo!


    Danke für die Info!
    Nachdem das KCP nun seit Wochen in der Halterung hängt, ist nichts mehr passiert.
    Ich denke, dass es am KCP liegt. Sollte es nochmals vorkommen, dann werden wir dieses mal tauschen.


    Gruß
    Stefan

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