Achsenkonfigurationen als Input für LIN() oder Berechnung von Status/Turn

    Hallo!


    Ich möchte für einen KUKA KR210_L180-2 ein Program mit linearen Bewegungen exportieren.
    Die linearen Bewegungen wurden allgemein simuliert und sind möglich.
    Ich wechsle während den linearen Bewegungen aber auch den Status/Turn-Bereich.


    Wie kann ich dem KUKA Controller die LIN-Kommands mit den Achswinkeln nun mitteilen?
    LIN(E6AXIS) würde mein Problm lösen, was allerdings nicht erlaubt ist.


    Ich habe schon gesucht, aber noch nichts Zufriendenstellendes gefunden.


    Vorschlag 1:
    Verwende LIN( FRAME). Da muss man weder Status noch Turn angeben.
    Aber wird da auch sicherlich die nächst gelegene Konfiguration im JointSpace angefahren?
    Aber selbst wenn das funktioniert, wollte ich eigentlich einen Konveyor über die externe Achse E1 ansteuern
    und parallel den Roboter linear verfahren. Was mit FRAME wohl nicht funktioniert.
    Oder funktionert das mit einer Base-Verschiebung?


    Vorschlag 2:
    Verwende LIN( POS) wenn ich im selben S/T-Berreich bleibe. Bei Bereichswechsel schalte ich auf PTP um.
    Dafür muss ich mir S/T für meine Achskonfigurationen berechnen.
    Für getStatusAndTurn(joints, int &status, ind &turn) kann ich die Tabelle von
    http://www.roboterforum.de/rob…rgeben/msg17192/#msg17192
    verwenden.
    Da sind aber noch 3 Fragen offen:
    (1) Wie wird der Grundbereich definiert?
    Meine Annahme: angle(flangePose's z-axis, robotBasis' z-axis) > 90°
    (2) Wie wird der Überkopfbereich definiert?
    Meine Annahme: angle(flangePose's z-axis, robotBasis' z-axis) < 90°
    (3) Wie lautet phi aus der Tabelle für meine Roboter KUKA KR210_L180-2?


    Vielleicht kann mir da jemand weiterhelfen.


    MFG,
    Bernhard

    Einmal editiert, zuletzt von bstoeffler ()

    • Schritt für Schritt zum Roboterprofi!

    Bei LIN werden Angaben zu Status und Turn grundsätzlich ignoriert. Der Strecke des TCP wird linear interpoliert, die daraus folgenden Achswinkel ergeben sich zwangsweise, im Guten wie im Bösen.


    E6POS sollten auch mit gelöschten S u. T funktionieren.


    Grüße,
    Michael

    Ich würde Lin(Frame) fahren. Ich fahre bis jetzt alle Palletier Aufgaben so. Anfänglich hatte ich das auch mit einer E6pos gemacht und bin genau da angekommen wie du. Mit der Lin(Frame) anweisung kannst du ohne gross rechnen und Prüfen einfach fahren.


    1. PTP E6pos <- Sichere Vorposition (z.B. über der Palette) wo alle Achsen schon annähern so stehen wie du Sie für die Pick/Place Pos brauchst.#
    2. Lin Frame <- berechnete Position
    3. Greifen oder was auch immer
    4. Lin ($POS_ACT:{X 0,Y 0,Z +100, A 0, B 0, C 0})
    5. PTP E6pos <- Sichere Vorposition



    Punkt 4. eventuell entfallen und direkt mit Punkt 5 weiter gemacht werden, das muss man mechanisch abwägen



    Gruß
    Sebbi

    Vielleicht habe ich auch das Problem nicht richtig verstanden. Hatte auch noch nie eine Zusatzachse an einem Robi, aber was ich bis jetzt davon gehört bzw. gelesen habe wird die doch bei der E6pos mit positioniert und das wird er wohl auch brauchen sonst weis man ja nicht wo sie steht.


    Und was hier in der Aufgabenstellung steht geht ja eh nicht

    Zitat

    Wie kann ich dem KUKA Controller die LIN-Kommands mit den Achswinkeln nun mitteilen?
    LIN(E6AXIS) würde mein Problm lösen, was allerdings nicht erlaubt ist.


    den bei einer Lin bewegung, kommt natürlich auf die länge der Lin Bwegung bzw. auch auf die Startpos an, wie nahe die an einem S/T wechsle ist, kommt zu einer sehr hohen warscheinlichkeit immer ein S/T wechsel. Das zu beeinflussen geht auch nicht mit Vorgabe von Achsewickeln.

    Wir haben einen Roboter an der Decke hängen, der lineare Bewegungen relative zu einem Werkstück fahren muss.
    Das sehr große Werkstück wird auf einem sehr präzisen Conveyor verfahren.


    Ich war bereits bei dem Kunden und die ersten Tests mit E6Pos haben gut funktioniert.
    Ich hatte auch Bedenken bzgl. Status/Turn-BEreich, die immer noch nicht zu 100% ausgeräumt sind. Dafür muss ich mehr Tests machen.


    Aber in unserer Sotware AutomaPPPS (Convergent-IT) simuliere ich die Bewegung des Roboter und ich weiß, dass keine Rekonfiguration während dem Prozess notwendig ist.
    Ich war mir nur nicht sicher was KUKA bei einem Status/Turn-Wechsel macht.

    Da ich aber immer nur eine IklId (InverseKineamticSolutionId: Elbow Up/down, Left/right shoulder, 360° Alternativen sind auch nicht gestattet) während dem Prozess verwende,
    sollte KUKA keine Rekonfiguration verursachen (wenn sie so smart sind wie ich annehme).


    In den LinearCommands habe ich dann immer die Position relative zum Workpiece und die ConveyorPos mit E6POS definiert.


    Danke nochmals!


    Grüße,
    Bernhard

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