Beiträge von simon1516

    7.Achse asynchron schalten - Greifer holen - 7.Achse wieder synchron schalten

    $async_axis='B0001' <- letztes Bit entspricht der 7. Achse, wenn so konfiguriert.

    1= asynchron / 0=synchron

    Ich kenne jetzt deine KSS Version nicht, aber ggf. in der Datei steu/$option.dat die Variable $ASYNC_OPT auf True setzen

    Hi,


    wir haben von Kuka die Information erhalten, dass sich Linearchasen als Zusatzachse nicht asynchron schalten lassen.


    Gibt's noch andere Wege?

    Guten Tag,


    folgende Situation:


    Wir haben einen Roboter auf einer Linearachse. Das World-Koordinatensystem liegt am Anfang der Linearachse.


    Ziel ist es, dass der Roboter einen Greifer während der Fahrt auf der Zusatzachse (Linearachse E1) aufnimmt. Dieser Greifer liegt auf dem Roboterpodest auf und fährt sozusagen mit.


    Nun ist es mir aber nicht möglich eine Bewegung zu programmieren, die den Greifer aufnimmt, da die E1 Achse ja kontinuierlich ihren Wert verändert. Beim Greiferwechsel das Robroot in ein beliebiges Base schreiben und dann einen Punkt in diesem Base anfahren geht leider nicht, wenn sich der Roboter währenddessen auf der E1 bewegt.


    Ist mein Problem verständlich?


    Grüße


    Simon


    Das wäre natürlich am besten, wenn, wie du es beschrieben hast, die Meldung automatisch quittiert werden würde. Ich glaube ich weiß sogar welche Liste du meinst. Bei KRC 4 zu finden unter:


    \KRC\Roboter\Config\User\Common\KrcExtConfMsg.xml


    Für die dort aufgeführten Meldungsnummern gilt:


    "allow confirmation in EXT "


    Danke dir :)

    Da wird es dann wohl keine universelle Strategie geben.

    Aber was spricht denn dagegen in dem einen Unterprogramm, in dem der genannte Fall zu 99% vorkommen wird einen 'Spezialfall' zu programmieren:

    Den globalen Interrupt ausschalten, einen lokalen deklarieren, den dann im Fall des Falles mit Resume beenden, und die Fehlerbehandlung machen, dann den lokalen abschalten und den globalen wieder einschalten.

    Das Programmiererleben ist halt nicht so einfach wie man sich das manchmal vorstellt.

    Das würde wohl gehen. Schade, leider keine 100% Lösung :)


    Danke an euch alle!

    Edith sagt: Deklaration des Interrupt im Hauptprogramm, auslösen des Interrupt im Unterprogramm. Der PZ springt in die Interruptroutine macht dann so Interruptdinge und springt mit "RESUME" wieder in das UP wo der Interrupt ausgelöst wurde.

    Er springt eben mit "RESUME" NICHT wieder in das UP...sondern in das Hauptprogramm, weil er dort deklariert wurde - oder ich versteh was komplett falsch.

    Ich verstehe ehrlich gesagt nicht richtig, was mir "Resume" bringen soll. Derzeit ist der Interrupt im Hauptprogramm deklariert. Ich möchte aber immer in dem Ablauf weitermachen, in dem ich mich gerade befinde. Durch "Resume" müsste ich mich doch festlegen, wo ich den Interrupt deklariere, oder nicht?

    Hier gehe ich mit! Du brichst die Bewegung durch Interrupt, "BRAKE F" ab, um dann mit PTP $POS_RET wieder auf den Kollisionspunkt zu fahren? Warum?

    Der Interrupt wird ausgelöst wenn der Roboter irgendwo aufsetzt. Das wird zu 99% beim Aufnehmen oder Ablegen des Produkts (hier Kisten) geschehen.


    Roboter setzt auf --> Interrupt löst aus --> Bewegung wird gestoppt --> Bediener bekommt auf SPS Meldung "Wiederholen" oder "Abbruch"


    Wiederholen: Erneuter Versuch die Kisten aufzunehmen. Der Bediener hat die Kisten gradegerückt, besser positioniert, was auch immer, damit der Greifer die Kisten nun aufnehmen kann. Programm geht ganz normal weiter. Erste Fahrt: LIN $POS_RET.


    Abbruch: Kein erneuter Versuch die Kisten aufzunehmen. Programmabbruch, Grundstellung.

    Ich verstehe das so, dass der Robi wieder auf die Position vor dem Interrupt zurück fährt...

    Das ist korrekt. Soll auch so sein. Problem ist, dass die Bewegung LIN $POS_RET im Interrupt-Programm gefahren wird und damit nicht von selbigem Interrupt überwacht wird. Es könnte also zu einem Aufsetzer/Crash während dieser Bewegung kommen.

    Da sollte man eher mit resume arbeiten, d.h. dann dass die Bewegung wirklich abgebrochen wird, und in das aufrufende Programm zurückgesprungen wird. Da muss man dann allerdings den Abbruch separat behandeln und wieder auf die Zielposition fahren.

    Hier im Forum nach "Resume" suchen, da findet sich sicherlich was.

    Es handelt sich hier um eine Überwachung , dass der Greifer nicht aufsetzt. Diese soll immer aktiv sein und wurde daher als globaler Interrupt deklariert. Somit kein "Resume" möglich.

    Zitat

    Hast du versucht die vorhergehende Bewegung im Interrupt abzubrechen?

    Ja. Und zwar genau so, wie du es gepostet hast.


    Vereinfacht sieht mein Interrupt-Programm so aus:

    Der Greifer soll immer ein Stück hochfahren, wenn er aufsetzt. Problematik ist hier die Bewegung LIN $POS_RET, da diese ohne Interrupt-Überwachung gefahren wird. Ich muss sie aber fahren, um keine Quittiermeldung bzgl. der Rückpositionierung zu erhalten.

    Hi,


    ich habe ein Problem mit der automatischen Rückpositionierung des Roboters, wenn dieser von der Bahn abkommt.


    Folgendes Szenario:


    - Roboter setzt irgendwo im Programm bei einer Bewegung von Punkt A nach Punkt B mit dem Greifer auf und löst einen Interrupt aus.

    - Im Falle eines Aufsetzens fährt der Roboter automatisch Z LIN REL 300 nach oben.

    - Programm läuft dann an der ursprünglichen Stelle weiter.

    - Roboter setzt dann Quittiermeldung "Rückpositionieren" ab. Wenn man diese quittiert, fährt der Roboter wieder zurück auf seine ursprüngliche Bahn, von der er die Bewegung fortsetzt.


    Es gibt wohl zwei Möglichkeiten damit umzugehen:


    1: Problem ist die Quittierung. Muss das sein oder kann man konkrete Quittierungsnummern vom Quittieren befreien?

    2: Was ich auch versucht habe, ist eine Bewegung LIN $POS_RET am Ende des Interrupt-Programms. Danach geht's dann ohne Quittierung weiter, so wie es sein soll. Problem hier: die Bewegung LIN $POS_RET geschieht im Interrupt-Programm, d.h. die Bewegung selber wird nicht vom Interrupt überwacht.


    PTP POS_ACT/ LIN POS_ACT bringt hier nix.


    Der Roboter soll einfach Punkt B anfahren, ohne das etwas quittiert werden muss. Weiterhin sollen natürlich alle Bewegungen vom Interrupt überwacht werden.


    Habt ihr dafür eine Idee? Es handelt sich um die KRC4.


    Danke und Gruß


    Simon