CONTINUE

  • Hallochen miteinander,



    mal ne Bescheidene Frage. Wir haben seid zwei Tagen ein kleines Problem. Ab und zu kommt es bei unserer Anlage zu einem Crash zwischen zwei Robotern. Ich hab nur so viel herausgefunden, dass nach einer Kollision des zweiten Roboters mit dem Bauteil (ist bei der Bearbeitung herausgesprungen) der erste Robi versucht das nächste Bauteil einzulegen und natürlich gegen den zweiten Robi fährt.


    Ich kann mir das nur so erklären, dass der Programmierer der Anlage überall diese continue Befehle drin hat. Macht ja auch manchmal sinn, aber gerade bei wichtigen Sachen wie unten rot gekennzeichnet, denke ich mal ist das schlecht. Meine Version dazu ist, dass der Vorlauf schon über die diese Zeilen darüber weg war und die Bedingung erfüllt war und bein erreichen das Programmzeigers die Bedingung nicht mehr erfüllt ist, aber durch das continue ignoriert wird.


    Bitte um Hilfe :ylsuper:


    PS: Anlage ist sehr neu und ich als Grundlagenprogrammierer auch. :biggrins:
    Robi ist ein KR6




    38 ;**********************************************************
    39 ; H O L E N
    40 ;**********************************************************
    41 DEF rHolen ( )
    42
    43 $IPO_MODE=#BASE
    44 $BASE=BASE_DATA[1]
    45 $TOOL=TOOL_DATA[5]
    46
    47 $APO.CPTP=10
    48 $apo.cdis=10
    49
    50 PTP HOME Vel= 100 % DEFAULT
    51 $TIMER_STOP[5]=TRUE
    52 CONTINUE
    53 WAIT FOR ((diVakuumOK==FALSE) AND (diSchieneAblegenVor==TRUE) AND ($IN[33]==TRUE) AND (diZyklus_Run==TRUE))
    54 $TIMER[5]=0
    55 $TIMER_STOP[5]=FALSE
    56 INTERRUPT ON 20
    57
    58 PTP zwpHol_A1 Vel= 100 % PDAT1 Tool[5]:tVakGreiferA1 Base[0]
    59 CONTINUE
    60 WAIT FOR (diFreigHolen==TRUE)

    61 INTERRUPT ON 23
    62 $TIMER_STOP[8]=TRUE
    63 $TIMER[8]=0
    64 $TIMER_STOP[8]=FALSE
    65
    66 axis_vel_acc(75,50)
    67 $APO.CPTP=1
    68 $apo.cdis=1
    69 PTP XpHol_A1:{X 0, Y 0,Z -10, A 0, B 0, C 0} c_ptp C_DIS
    70 axis_vel_acc(100,100)
    71
    72 TRIGGER WHEN PATH=-3 DELAY=0 DO doAbblasenEin=FALSE
    73 TRIGGER WHEN PATH=-3 DELAY=0 DO doVakuumEin=TRUE
    74
    75 $VEL.CP=0.3
    76 LIN pHol_A1 Vel= 0.3 m/s CPDAT1 Tool[5]:tVakGreiferA1 Base[0]
    77 ;
    78 WAIT FOR (diVakuumOK==TRUE)
    79
    80 PULSE (doTeilEntnommen,TRUE,0.5)
    81 ;
    82 $VEL.CP=0.8
    83 LIN {X 0, Y 0,Z 10, A 0, B 0, C 0}:XpHol_A1 C_DIS
    84
    85 $APO.CPTP=1
    86 $apo.cdis=1
    87 INTERRUPT OFF 23
    88 PTP zwpHol_A1 Vel= 100 % PDAT1 Tool[5]:tVakGreiferA1 Base[0]
    89
    90 $TIMER_STOP[8]=TRUE
    91
    92 $APO.CPTP=10
    93 PTP HOME Vel= 100 % DEFAULT
    94
    95 INTERRUPT OFF 20
    96 END ;______________________________________________________

  • Schritt für Schritt zum Roboterprofi!
  • Hallo freudi,
    du liegst mit Deiner Vermutung genau richtig !
    Das CONTINUE sorgt dafür, dass die WAIT FOR Anweisung in Zeile 60 bereits im Vorlauf ausgewertet wird. Das dürfte bei dem Programm ungefähr zu dem Zeitpunkt sein, bei dem die Bewegung aus Zeile 58 gerade gestartet worden ist.
    CONTINUE ist zwar manchmal notwendig, aber vor Zeilen, bei denen externe Eingangssignale den Programmablauf beeinflussen (z.B. WAIT FOR ..., IF ...) hat es aber auch gar nichts verloren !!! (Es sei denn, man findet es toll, dass Bedingungen zu einem nicht genau definierten Zeitpunkt im Programmablauf ausgewertet werden)
    Gruß Hinky

  • Hallo freudi.


    Bei unseren Anlagen müssen wir auch viele CONTINUE einbauen, weil jede Zehntelsekunde zählt.
    Aber wenn sich Maschinen ins Gehege kommen können bauen wir noch andere Sicherheitsmechanissmen ein.


    Zum einen lassen wir den Roboter über die konfigurierbaren Arbeitsbereichsüberwachungen einen Ausgang setzten. Also im crash-freien Bereich soll ein Ausgang gesetzt werden. Dieser wird dann im crash-Bereich zurückgenommen.
    Über die Submit werden nun gegenseitig diese Ausgänge überwacht und falls der Fall auftritt, dass sich beide zu nahe kommen, wird der Overide in der Submit auf 0 gesetzt.
    Das ganze ist ohne teure Optionen machbar. :mrgreen:


    Teurer aber gut ist natürlich noch die Hardware-Achsüberwachung.


    Gruß Roland

  • Hallo,


    der Crash hat mit dem CONTINUE gar nichts zu tun.
    Das Signal darf auch nicht im Vorlauf anstehen - sonst waere die Verrieglung ja zeitkritisch.
    Hast du das Signal diFreigabeHolen nach dem Crash geprueft?


    Ich sehe keine Verriegelug der Roboter gegenseitig.
    Wenn eine PLC im Spiel ist, muesste dort sowas programmiert sein:


    U "diRob2InWorkSpace"
    U "diRob1WerkstPosOk"
    = "doRob1FreigabeHolen"


    Gruss Stefan

  • Moin,


    ... wenn eine übergeordnete SPS in der Anlage vorhanden ist würde ich einen "Freigabemanager" im Steuerungsprogramm der SPS programmieren.


    Jeder Roboter stellt dabei, wenn er in einen kritischen Bereich einfahren möchte, eine Anfrage auf Fahrfreigabe bei der SPS. Die SPS erteilt dann je nach Priorität dem einen oder dem anderen Roboter die Fahrfreigabe.



    Gruss ROBBert

    Woher soll ich wissen was ich denke bevor ich höre was ich sage?


  • Hallo nochmal,
    das idFreigabe Holen habe ich leider nicht geprüft. Ich weiß jetzt auch nicht, ob das noch geht, wenn man die KCP´s in der Roboterzelle sind und um da hineinzukommen auf Einrichten schalten muss. Ich werde das mal prüfen.


    Unter PLC meinst du sicherlich sowas wie eine Übergeordnete SPS. Diese ist bei uns vorhanden. Da ich nur grob Überblick über die SPS Programierung habe kann es schon sein, dass es keine richtige Verriegelung da gibt. Ich kann dies ja mal versuchen mit unserem Elektriker zu prüfen.


    Gruß René

  • CONTINUE ist zwar manchmal notwendig, aber vor Zeilen, bei denen externe Eingangssignale den Programmablauf beeinflussen (z.B. WAIT FOR ..., IF ...) hat es aber auch gar nichts verloren !!! (Es sei denn, man findet es toll, dass Bedingungen zu einem nicht genau definierten Zeitpunkt im Programmablauf ausgewertet werden)
    Gruß Hinky


    Ich finde diese Pauschalaussagen immer wieder klasse!
    "Meine Roboter" beladen Maschinen und bekommen ein Freigabesignal, dass sie in die Maschine reinfahren dürfen.
    Würde ich bei jedem Beladevorgang "mal kurz anhalten", obwohl das Freigabesignal schon längst ansteht, würden meine Kunden mit mir ungefähr das machen: :uglyhammer_2: :uglyhammer_2: :uglyhammer_2:


    Zykluszeit ca. 30 Sekunden. Vor der Anlage kurz mal anhalten wegen Vorlaufstop: Zeitverlust ca. 0,2 - 0,3 Sekunden.
    Sind bei ca. 2500 Zyklen pro Tag mal schnell 4000 Teile im Jahr weniger!
    Und das nur beim Beladen gerechnet! Ich muss natürlich auch noch entladen!



    Man muss natürlich sicherstellen, dass der Roboter stoppt, wenn das Signal wieder weggeht. Das kann man z.B. mit einem Interrupt lösen!


    Ich würde das ganze über Arbeitsbereiche der Roboter und Interrupts lösen.
    Solange der eine Roboter im Weg steht, wird der andere gestoppt, wenn er dorthin fahren will.
    Evtl. auch über die Zellen-SPS, die dann den Roboter anhält(!).

    Gruss<br /><br />Dodo

  • Hi,
    ich denke nicht das der Roboter der auf einen Eingang wartet das Problem ist!
    Schau Dir den Roboter an der das Teil verliert. Hier hast Du eventuell ein Problem mit dem Programmvorlaufzeiger. Hier is es eventuell nötig das Setzen des Profilfreisignals in einem Trigger unterzubringen. Dieser wird dann beim verschleifen der Bewegung dann nur, natürlich ja nach Einstellung, ausserhalb des mechanisch gefährdeten Bereiches gesetzt ohne das Du anhalten musst.


    Zum Thema CONTINUE: Ich benutze dies über all wo ich auf Systemvariablen zugreife. Alles andere mache ich mit Stoppostionen oder Trigger um die Signale zu gewünschten Situationen korrekt geschaltet zu bekommen. Und schon flitzt auch der KUKA wie ein ABB. Das man dann natürlich jedemenge CONTINUE's in dem Programm hat ist dann halt so. Nicht schön aber sehen und interressieren tut es ja eh keinen, weder dem Bediener noch den Kunden der Anlage.


    Sven

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!


  • Mojen noch mal,
    :gutidee:
    danke für den Tip. Der eine Robi wartet auf das diFreigabeHolen. Dies ist das Problem, da der Programierer des Roboter-Programmes sich da nur auf ein Eingang der SPS angehängt hat. Dies ist natürlich nur ein einfacher Lasertaster. Wenn der nicht mehr betätigt ist ................... Rest könnt ihr euch ja denken.


    :merci:


    Gruß und schönen Dank


    René

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