Störungsmanagement

    Hallo zusammen,


    für eine Automatisierung nutze ich eine KR C4 Steuerung und programmiere das gesamte Automatisierungsprogramm in C auf einem Windows-PC. Zur Kommunikation mit der Robotersteuerung wird die Automatik Extern Schnittstelle verwendet. Der Roboter hat im Grunde nur einfache Handlingjobs.
    Die Schnittstelle ist soweit eingerichtet, so dass ich Programmnummern übertragen kann, die refktierten auswerte und dann PGNO_VALID setze. Funktioniert alles bestens.


    Jetzt weiß ich aber nicht, wie man am besten nach einem Not-Aus, oder einem PC-Absturz reagiert. Bis jetzt ist es so, dass ich nach Not-Aus mein Windows-Programm neu starte, damit wird auch die Extern-Schnittstelle neu initialisiert, und der Roboter fährt sein vorheriges Programm weiter. Das kann ich aber ohne auf das KCP zu schauen nicht überprüfen. Deshalb würde ich es gerne abbrechen, sodass ich nach Not-Aus (wenn während Unterprogrammabarbeitung) per Hand in T1 die SAK-Fahrt machen muss. Ist das möglich?

    • Schritt für Schritt zum Roboterprofi!

    Also ich habe erst heute einen Test mit dem Not-Aus gemacht. Ich konnte problemlos danach über die Automatik-Extern Schnittstelle den Roboter sein Programm zu Ende fahren lassen.
    Also ich frage

    Code
    Not $PRO_ACT And Not $PGNO_REQ And $STOPMESS


    ab, ob ein Fortsetzstart möglich ist.
    Wenn Du natürlich immer nach NOT-AUS eine SAK Fahrt machen willst, kannst Du ja bei neg. Flanke von $ALARM_STOP (NOT-AUS) das Programm abbrechen und aus den Cell-Loop springen. Dann bleibt dem Bediner ja nichts anderes übrig als eine SAK-Fahrt zu machen.


    Mike

    Zitat von BIM


    Also ich habe erst heute einen Test mit dem Not-Aus gemacht. Ich konnte problemlos danach über die Automatik-Extern Schnittstelle den Roboter sein Programm zu Ende fahren lassen.


    Ich glaube, das will ich gar nicht. In einigen Jobs arbeitet der Roboter mit erwärmten Teilen. Wenn dann die Bewegung unterbrochen wird (z.B. weil Bedienerschutz offen, Not-Aus, Programmabsturz) soll der Roboter immer von Hand in HOME gefahren werden. Das Teil kühlt sonst zu sehr ab und der Prozess ist nicht reproduzierbar.


    Kann man ein Unterprogramm während der Ausführung abbrechen? Was würde dann passieren? Dann müsste ja das cell-Programm wieder aktiv sein, jedoch ist der Roboter nicht in der Grundstellung, d.h. die Programmnummeraufforderung würde auch nicht kommen, oder?

    Hi,


    du kannst dein Programm über einen INTERRUPT Abbrechen. Im INTERRUPT Programm verwendest du ein RESUME das den Programmlaufzeiger in das Programm zurück springen lässt in dem du den INTERRUPT deklariert hast.
    Zusätzlich kannst du über eine Steuervariable im INTERRUPT Programm eine Aktion im SPS submit auslösen der dir das Programm so zurücksetzt als währe es frisch angewählt worden.


    Guckst du hier:


    ;--- Programmreset
    IF bReset AND ($EXT OR $AUT) THEN
    IF ($PRO_STATE1==#P_ACTIVE) THEN
    CWRITE($CMD,STAT,MODE,"STOP 1")
    ELSE
    IF ($PRO_STATE1==#P_STOP) OR ($PRO_STATE1==#P_END) THEN
    CWRITE($CMD,STAT,MODE,"RESET 1")
    bReset = FALSE
    ENDIF
    ENDIF
    ENDIF


    Danach kannste Automatisiert neu starten. Oder ganz abwählen:


    ;--- Programm abwahl
    IF (bCancel OR NOT bNotFault) AND ($EXT OR $AUT) THEN
    IF ($PRO_STATE1==#P_ACTIVE) THEN
    CWRITE($CMD,STAT,MODE,"STOP 1")
    ELSE
    IF ($PRO_STATE1==#P_STOP) OR ($PRO_STATE1==#P_RESET) OR ($PRO_STATE1==#P_END) THEN
    CWRITE($CMD,STAT,MODE,"CANCEL 1")
    bCancel = FALSE
    ENDIF
    ENDIF
    ENDIF


    So kannste auch den Bediener zwingen seine HOME fahrt zu machen.


    Gruss Matze

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

    Und das kommt dann direkt in den Submit-Interpreter? Was passiert dann, wenn der Roboter nicht in HOME ist, und das Unterprogramm abgebrochen ist? Da das cell Programm ja noch aktiv ist, fährt der Roboter doch mit PTP den ersten Punkt des neuen Programmes direkt an, weil SAK ja nur bei cell-Anwahl statt findet?


    Gibt es irgendwo zu der Thematik weitere Beschreibungen, oder Dokus? Zumindest Erklärungen, was welche Variablen sind, z.B. was ist bReset? Oder ist das eine eigene Variable?

    Hi,


    also bReset usw. sind eigene Variablen. Der Interrupt wird im Programm verwendet. Das Reseten oder abwählen wird vom Submit aus durchgeführt.


    Ich hab mal was von KUKA angehängt. Dort wird die Interrupt Geschichte beschrieben. Die Beschreibung ist zwar von der KRC2 funktioniert aber in der KRC4 genauso.


    Die "CWRITE($CMD,STAT,MODE,"STOP 1")" Geschichte sollte direkt schon im SPS Submit funktionieren, da KUKA da schon von Haus aus alles deklariert hat. Lediglich die Steuervariable um das ganze vom Interrupt Programm über den Submit anzustossen sind Global zu deklarieren. So bekommt der Submit mitgeteilt das der Interrupt das Programm Abbrechen/Abwählen möchte.


    Gruss Matze

    Dateien

    KSS_52_53_54_SI_de.pdf 6,98 MB – 77 Downloads

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

    Moin,


    also ich denke jetzt beide Teile (Programmreset und Programm abwahl) verstanden zu haben und würde beides in den Submit in eine Endlosschleife schreiben, richtig?.
    Nach meinem Verständnis müssten bReset und bCancel global deklarierte Variablen sein, die ich aus jedem Programm setzen kann. Was ich jetzt noch nicht verstehe ist die Verbindung zu den Interrupts. Durch was werden die aktiviert und auf was reagieren die?


    :danke:,
    h_robot


    P.S.: Hast du zufällig auch die "Experten-Dokumentation CREAD/CWRITE"? Dazu habe ich nur einen Hinweis im Handbuch "Bedien- und Programmieranleitung für Systemintegratoren", aber finde die Doku nicht auf meiner DVD.

    Nun,


    der Interrupt wird durch eine Variable oder einen Eingang ausgelöst. Wenn der Interrupt auslöst dann startet er das Deklarierte Programm. In diesem Programm setzt du dann deine Globale Variable auf true. Und schon macht der Submit das was du willst -> rücksetzen abwählen.


    Der Interrupt reagiert nur auf einen Flanken wechsel. Ist das Programm angehalten oder der Interrupt disabled, dann bekommt der Interrupt den Signalwechsel nicht mit. Sollte das ein Problem sein, dann muste den Interrupt im Submit einbauen.


    Ja, der Reset oder Abwahl muss in die LOOP Schleife und lauscht dort auf deine Globale variable.


    Edit: eine Doku zu Cread/Cwrite hab ich leider keine brauchbare. In der hinsicht suche ich schon lange eine.


    Gruss Matze

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

    Einmal editiert, zuletzt von MaBo ()

    Hallo MaBo,


    ich habe nun Programmreset und die Programmabwahl mit Deinem Quellcode getestet und es funktioniert. (Einziger Unterschied: ich habe vor bReset ind bCancel jeweils ein $ gesetzt, und es in der Datenliste global deklariert. "OR NOT bNotFault" habe ich weggelassen, weil ich nicht wusste, wozu ;)
    Warum machst Du eigentlich erst "STOP 1" und dann "RESET 1" bzw. "CANCEL 1"? Könnte man das auch direkt nacheinander tun?


    Der Reset wird z.Zt. noch durch einen Interrupt bei Not-Aus ausgeführt. Leider kommt die Aufforderung, in T1 zu fahren, erst nachdem ich zwei Mal nach Not-Aus Rücksetzen wieder Starten möchte. Bekommt man das für den Bediener noch eindeutiger hin? (Sobald Not-Aus zurückgesetzt wird, soll die SAK/HOME-Aufforderung kommen).


    Grüße,
    h_robot

    Hi,


    also zu deiner ersten Frage:
    Dieser Code ist Ursprünglich auf der KRC2 entstanden. Dabei hat die Steuerung manchmal ein merkwürdiges verhalten gezeigt, so das der RESET1 oder CANCEL1 Befehl von der Steuerung nicht durchgeführt wurde. Eine Erklärung für dieses Verhalten hab ich nicht. Allerdings nachdem ich den Code so verwendet habe wie ich in gepostet hab, hat die Steuerung sich immer richtig verhalten.
    Es kann auch sein das das Problem in dem Schnecken langsamen Submitinterpreter der KRC2 steckt und in der KRC4 nicht mehr.


    Deine zweite Frage kann ich jetzt nicht ganz nachvollziehen. Soll das eine Systemeigene Meldung sein oder möchtest du sie generieren. Kannst du das etwas Detailierter beschreiben?


    Gruss Matze

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

    Zitat von MaBo


    Deine zweite Frage kann ich jetzt nicht ganz nachvollziehen. Soll das eine Systemeigene Meldung sein oder möchtest du sie generieren. Kannst du das etwas Detailierter beschreiben?
    Gruss Matze


    Hi,


    also nach Betätigen vom Not-Aus und anschließendem Rücksetzen ist die Steuerung in einem für den Bediener undefinierten Zustand. Wie die einzelnen AUT-EXT Ausgänge nun aussehen, müsste ich vor Ort wieder nachsehen, kann ich dann später hier schreiben. Zumindest gebe ich dann einen Fehlerquit- und Startimpuls. Das ganze mache ich dann nochmal, und erst dann steht in den Meldungen, dass die HOME-Position in T1 angefahren werden soll.


    Grüße

    OK,


    ich nehm mal an deinen Wunsch verstanden zu haben. Du willst wohl offentsichtlich den Bediener zwingen bei einer Not-Aus Situation eine manuelle Home fahrt zu machen. Das ist eigentlich ganz einfach. Du verriegelst dein Hauptprogramm so das es gleich zu beginn abfrägt ob der Roboter in Home steht, also so mach ich das immer, und dann kann auch gleich eine Meldung dazu Platziert werden.


    Als nächstes machst du ein zweites Programm das nur im T1 oder T2 benutzt werden kann. Dieses macht nichts anderes als den Roboter auf Home fahren. Steht der Roboter wieder auf Home wird die Automatik wieder normal startfähig.


    Wenn du eine Homeposition hast die nicht über die Automatik Externschnittstelle abgefragt werden kann, dann kannst du das auch mit dieser funktion machen.



    Diese Funktion funktioniert aber nur in Verbindung mit einer Axis Position.


    In deinem Hauptprogramm kannst du das in etwa so verriegeln.


    Code
    WHILE a_chk_axis(xHOME)
   a_ctl_message(#Q,14,nChoice)
   HALT
ENDWHILE


    Das Message Programm musst dir jetzt als eigenständiges Programm das nur Messages generiert verstanden werden.


    So kannst du dein Hauptprogramm absichern wenn die Signale aus der Automatikexternschnittstelle nicht gehen.


    Dein Manuelles Homefahrprogramm könnte dann in etwa so aussehen.



    Dadurch das du bei der ersten PTP die Achse A1 stehen lässt klappt der Roboter sich nur zurück. Mit der zweiten fährt er dann auf Home.
    So hast ein sehr einfaches Home fahren für den Bediener.


    Ich hoffe dir damit geholfen zu haben. Wenn nicht dann beschreib deine Idee etwas ausführlicher.


    Gruss Matze

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

    Moin,


    Also, ich bin in der cell.src und habe von extern ein Unterprogramm gestartet. Während der Programmbewegung kam der Not-Aus, der jetzt wieder zurückgesetzt ist. (Taster nicht mehr gedrückt).
    Folgender Zustand: Steuerung bereit=1, Schnittstelle aktiv=1, Fehler=1.
    Auf dem KCP: S grün, O für Antriebe aus, R ist rot, Ext ist grün
    Es stehen keine Meldungen auf dem KCP. Das meine ich mit unklarem/undefiniertem Zustand.


    Hier sollte dem Bediener klar gemacht werden (z.B. durch einen Ausgang), dass er zu T1 soll, dann SAK/HOME, und dann wieder Ext zum starten.


    Wenn ich quittiere und die Antriebe einschalte, gebe ich wieder einen Start - Impuls. Das R sprigt dann kurz auf grün und wird gelb. Erst nach nochmaligem Start - Impuls wird das R grün und die Meldung "Home Position in BA T1" erscheint.


    Ist das so üblich, oder wäre es anders praktischer? Eigentlich will ich nur, dass nach Not-Aus oder Schutzzaunverletzung (oder nach einem anderem Grund für Programmreset) der Bediener über einen Ausgang aufgefordert wird, nach HOME zu fahren.


    Grüße

    Nun,


    du kannst über den SPS Submit eine Meldung auf dem SmartPad ausgeben das er eine Homefahrt machen muss. Zur Sicherheit kannst du dem Roboter das $MOVE_ENABLE wegnehmen bis du erkennst das er auf $T1 umgeschaltet hat. Das ist dann sehr Sicher verriegelt. Nach dem du über die Automatikextern Schnittstelle das Signal hast das er auf Home Steht, dann kannste $MOVE_ENABLE für $EXT wieder zulassen.
    Aber bedenke das der Roboter wenn er manuell in Home gefahren werden soll den $MOVE_ENABLE im $T1 benötigt. Sonst ist der Roboter gesperrt


    Zu deiner Frage. Ja, es ist üblich einen Roboter erst in Automatik starten zu lassen wenn er auf einer gewissen Ausgangsposition steht, in diesem Fall HOME. Das verhindert das übliche kaltverformen, das Roboter in unkontrollierten zuständen ausüben :biggrins:

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

    Jetzt ist es aber so, dass ich die SAK-Fahrt machen muss, wenn ich Not-Aus während einer Bewegung betätige. Das ist denke ich ganz ok so.


    Wenn der Roboter aber steht und kein Programm ausführt gibt es zwei verschiedene Verhaltensweisen, die sich im Wiederanlauf unterscheiden:
    1. Das Geräusch der Antriebe (ein Summen, ich weiß nicht genau was es ist) ist noch zu hören
    2. Nach automatischem Abschalten des Summens (einige Sekunden nach letzter Bewegung)


    Warum ist es für die Steuerung ein Unterschied, in welchem der beiden Zustände ich den Not-Aus betätige und was ich zum Wiederanlauf tun muss?


    Grüße,
    h_robot

    Hi,


    also die wenn die Antriebe Summen dann sind sie noch in Regelung und sollte dann ein Not-Halt kommen kann es sein das dies dazu führt das der Roboter nicht mehr ganz genau auf seiner letzten Position steht und somit nicht mehr mit der Bahnplanung übereinstimmt. Das könnte wahrscheinlich eine Minimalabweichung sein. Habe selbst auch schon mal solch ein verhalten bemerkt. Habe sogar schon einmal erlebt das ein Roboter in solch einer Situation an der Achse 3 zwar den Regelbetrieb eingestellt hat, aber die Bremse kam etwas seeeeeeeeehr zeitverzögert. Dabei ist der Arm runtergeplumst. Das ist kein Witz. Ich habs live gesehen. :angel:


    Eine Abhilfe ist in dem du kurz PTP $POS_ACT machst und den Roboter so Quasi über seine aktuelle Position auf die Bahn zurück holst.


    Wenn die Antriebe nicht mehr summen dann sind die Bremsen bereits eingefallen und ein Not-Halt hat dann keinen Einfluss auf die derzeitige Roboterposition. Somit ist nach dem Reset der Roboter gleich wieder bereit.


    Ich vermute mal das das der Unterschied ist den du meinst.


    Gruss Matze

    Man muss nicht Verrückt sein, aber es hilft ungemein.<br />Meine Roboter verspeisen SPS-Programmierer zum Frühstück.<br />Lass niemals einen Dipl. Ing. an den Roboter, die machen immer alles kaputt und sind viel zu Banane im Kopf.

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