Wie Offset bei wechselnder Achsstellung angeben?

  • Moin,


    das mit der Achsstellung (Flip / Noflip, Up / Down, fronT / Back) hab ich grundsätzlich begriffen. Mir ist nur nicht ganz klar, ob der Roboter begriffen hat, was ich von ihm will. ^^


    Der Roboter soll auf berechnete Positionen innerhalb eines Userframes fahren. Es gibt eine geteachte Startposition, die 24 Startpositionen darüber werden berechnet. Von der jeweiligen Startposition aus soll eine Folge von Bewegungen an Zwischenpositionen gemacht werden, die (von der jeweiligen Startposition ausgehend) mit Offsets realisiert sind. Eine der Zwischenpositionen des Bewegungsablaufes kann ich nur für die Startpositionen bis 4 erreichen, für alle weiteren bekomme ich den Fehler MOTN-018 Position noch reachable angezeigt.


    Zuerst hatte ich nur einen Offset für diese Zwischenposition, PR[20].

    Für diese Zwischenpositionen ab Höhe 6 habe ich immer die Fehlermeldung MOTN-018: Position not reachable bekommen.

    Also bin ich auf die Zwischenposition in Höhe 4 gefahren und hab den Roboter mit JOG nach oben bewegt.

    Wie man auf den Bildern erkennt, ändert sich dabei die Achskonfiguration von FUT auf NUT.

    Also hab ich ein zweites Offset angelegt, PR[21]. Da hab ich die Achskonfiguration von FUT auf NUT geändert.

    Alle Zwischenpositionen ab Höhe 6 sind aber nach wie vor nicht erreichbar. Ich bekomme immer noch die Fehlermeldung MOTN-018: Position not reachable.


    Hier mal der Programmausschnitt an dieser Stelle. (Die Zwischenposition für Höhe 5 liegt in einer Singularität, J5 ~1,6°. Darum kümmere ich mich aber später. ^^ )


    Wie muss ich das Offset anpassen, damit der Roboter auf die Zwischenpositionen ab Höhe 6 fährt? :/


    Gruß

    Jörn



    (1) Von dieser Zwischenposition kommt der Roboter



    (2) Offset und Achskonfiguration der Zwischenposition für Startposition Höhe 4



    (3) Offset und Achskonfiguration der Zwischenposition für Startposition Höhe 6

    In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

  • ANZEIGE
  • halbesYoyo

    Hat den Titel des Themas von „Wie Achsstellung vorgeben?“ zu „Wie Offset bei wechselnder Achsstellung angeben?“ geändert.
  • Für die Lösung des Problems gibt es eine ganze Reihe von Möglichkeiten, z.B.:


    1. Die Positionen so setzen, damit du die Änderung der Konfiguration vermeiden kannst.


    2. Die Position in PR[14] einmal mit der Conf FUT und einmal mit NUT in zwei verschiedene PRs schreiben und diese dann abhängig von deinen Bedingungen in das PR[14] kopieren. Die Offsets kannst du in der Default Conf belassen.


    3. Die betreffende Zwischenposition als lineare Bewegung (L PR[14] ...) ausführen. Wenn das nicht funktioniert, dann kannst du hinter die lineare Bewegung noch den Wrist Joint (Wjnt) Modifier setzen.


    4. etc. pp.


    Ich würde an deiner Stelle überlegen, ob 1. möglich ist und ansonsten mit 3. starten.

  • Guten Morgen,


    ich hab mal ein bissl was getestet.


    Vorschlag 3 hatte ich vorher schon probiert, das funktioniert nicht.


    Vorschlag 2 ist ja eine Umsetzung von Vorschlag 1: Ich kann den Bewegungsablauf für die Höhen 1-4 komplett mit der Konfiguration FUT und für die Höhen 6-20 komplett mit der Konfiguration NUT abfahren. Dafür brauche ich aber drei zusätzliche PR[] und drei IF-THEN-ESLE-Blöcke im Code. Einmal für die Auswahl der Startposition (NUT / FUT), einmal für die Auswahl passender Zwischenpositionen (andere Anfahrt wegen Kollisionsvermeidung) und einmal für die Auswahl der Offsets der Scanposition (NUT / FUT).

    Ne, moment. Ich brauche sogar für alle Positionen und Offsets zwei PR[] (jeweils mit Konfiguration FUT und NUT) und zwei große IF-THEN-ELSE-Blöcke für die Höhen 1-4 und 6-20.


    Das muss doch auch irgendwie anders gehen. Sonst wäre man ja auf Bewegungsabläufe beschränkt, bei denen die Konfiguration niemals wechselt. Anders gesagt: Ein Bewegungsablauf, bei dem die Konfiguration mehrfach hin und her wechselt, wäre nicht möglich. :/


    Gruß

    Jörn

    In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

    Einmal editiert, zuletzt von halbesYoyo ()

  • Das muss doch auch irgendwie anders gehen. Sonst wäre man ja auf Bewegungsabläufe beschränkt, bei denen die Konfiguration niemals wechselt. Anders gesagt: Ein Bewegungsablauf, bei dem die Konfiguration mehrfach hin und her wechselt, wäre nicht möglich. :/

    Selbstverständlich ist das möglich, die Position muss aber logischerweise irgendwie erreichbar sein.


    Hast du dich mal mit den drei Turnwerten, d.h. dem 000 in der Conf beschäftigt? Fahre mal die Positionen, an denen es hakt, an und schau dir die jeweils die Achswinkel an. Vielleicht liegt hier der Hund bergraben und du musst die Turnwerte anpassen, damit die Position erreicht werden kann.

  • Selbstverständlich ist das möglich, die Position muss aber logischerweise irgendwie erreichbar sein.


    Hast du dich mal mit den drei Turnwerten, d.h. dem 000 in der Conf beschäftigt? Fahre mal die Positionen, an denen es hakt, an und schau dir die jeweils die Achswinkel an. Vielleicht liegt hier der Hund bergraben und du musst die Turnwerte anpassen, damit die Position erreicht werden kann.

    Erreichbar sind die Positionen. Ich kann den Roboter in der Scan-Position von Höhe 1 bis auf die Scan-Position auf Höhe 20 per JOG hoch und runter fahren. Dabei ändert sich die Konfiguration.


    Deshalb hab ich aktuell 2 Offsets. Jeweils mit FUT und NUT (PR[20] und PR[21], auf den Bildern 2 und 3 oben zu sehen), die ich in Abhängigkeit von der anzufahrenden Höhe benutze (Im Code oben Zeile 48-52).


    Deshalb die Frage, wie ich die Offsets angeben muss, damit der Roboter weiß, daß sich durch das Offset die Konfiguration ändert. Einfach das FUT in NUT ändern scheint nicht zu reichen.


    Die Fehlermeldung sagt mir doch nur, daß Motion Group 1 betroffen ist?! Die betroffene Achse, 5, sehe ich da nicht.


    In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

  • Den Roboter an eine Position zu joggen und die gleiche Position im Programmablauf anzufahren kann einen gewaltigen Unterschied machen.


    Wie in meinem ersten Post geschrieben, kannst du die Conf in den Offsets auf Default belassen (ich glaube NDB 000), da dies keinen Einfluss hat. Die maßgebende Conf muss in deinem P oder PR stehen, welche angefahren werden soll, bei dir das PR[14].


    Sorry, mein Fehler. Ich war beim Limit error. Hier steht noch die Info zu den betroffenen Achsen.


    Hast du dir im Handbuch mal die Abhilfe zum Fehler MOTN-018 angeschaut?

  • ...


    Wie in meinem ersten Post geschrieben, kannst du die Conf in den Offsets auf Default belassen (ich glaube NDB 000), da dies keinen Einfluss hat. Die maßgebende Conf muss in deinem P oder PR stehen, welche angefahren werden soll, bei dir das PR[14].


    ...

    Also muss der P / das PR, worauf das Offset verrechnet wird, schon die passende Konfiguration haben? Es gibt keine Möglichkeit die Konfiguration durch Angabe eines entsprechenden Offsets anzupassen? Oder meinethalben durch einen zusätzlichen Befehl? :/


    Das ist bestimmt "lustig" für Programme, wo ausgehend von einer bestimmten Startposition Zwischenpositionen mit anderen Achskonfigurationen berechnet und angefahren werden sollen / müssen. ^^


    Ich hab jetzt die Startposition mit beiden Konfigurationen angelegt und nutze zum Berechnen der Offsetpositionen die dazu passende Startposition. Nicht unbedingt hübsch, aber funktioniert! Vielen Dank für Deine Hilfe. :thumbup:

    In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

  • Also muss der P / das PR, worauf das Offset verrechnet wird, schon die passende Konfiguration haben? Es gibt keine Möglichkeit die Konfiguration durch Angabe eines entsprechenden Offsets anzupassen? Oder meinethalben durch einen zusätzlichen Befehl? :/

    Soweit ich weiß gibt es da keine Möglichkeit, zumindest nicht in TP. Wenn dann eher mit Karel. Ich lasse mich aber gerne eines besseren belehren.

    Das ist bestimmt "lustig" für Programme, wo ausgehend von einer bestimmten Startposition Zwischenpositionen mit anderen Achskonfigurationen berechnet und angefahren werden sollen / müssen. ^^

    Das ist bei berechneten oder mit Offsets versehenen Positionen natürlich immer zu beachten bzw. stellt ein "Risiko" dar. Wobei sich das meiner Meinung nicht nur auf FANUC beschränkt.

    Ich hab jetzt die Startposition mit beiden Konfigurationen angelegt und nutze zum Berechnen der Offsetpositionen die dazu passende Startposition. Nicht unbedingt hübsch, aber funktioniert! Vielen Dank für Deine Hilfe. :thumbup:

    Du könntest in deiner IF-Anweisung bei "Move to scan pos" die jeweilige Position mit der passenden Conf deinem PR[14] zuweisen und dann nach der IF-Anweisung den Fahrbefehl machen. Vorteil wäre, dass du im ganzen Programm für die Bewegungen nur das PR[14] brauchst.

  • Soweit ich weiß gibt es da keine Möglichkeit, zumindest nicht in TP. Wenn dann eher mit Karel. Ich lasse mich aber gerne eines besseren belehren.


    Ich hab mal in der KAREL-Referenz geschaut. Für mich liest sich das so, als gehe es nicht:


    Zitat von KAREL Reference Manual (MARRC75KR07091E, Rev H), Kap. 8-2, S. 164

    Note The KAREL system provides a way to create and manipulate position data but it does not support motion instructions. All motion must be initiated from a teach pendant program.


    Ich könnte also in KAREL die Konfiguration der Position anpassen, also den IF-THEN-ELSE-Block aus dem TP-Programm ins KAREL verschieben. Die Bewegung selber macht dann wieder das TP-Programm. Das erscheint mir aber wenig sinnvoll.



    Das ist bei berechneten oder mit Offsets versehenen Positionen natürlich immer zu beachten bzw. stellt ein "Risiko" dar. Wobei sich das meiner Meinung nicht nur auf FANUC beschränkt.

    Bei einem KUKA-Programm hatte ich mal ein ähnliches Problem. Es ging darum je 4 Bauteile (aus 3 unterschiedliche Typen) von 2 Trays abzuholen. Bei einer der Bewegungen (Bauteiltyp 3 von Platz 2 aus Tray 2) hat er die Handachsen einmal komplett im Kreis gedreht. Ich musste dann bei genau dieser einen Konstellation Status und Turn mit passenden Werten überschreiben und die Geschwindigkeit auf 80% reduzieren. Die Bewegung sah etwas holprig aus, aber es ging zumindest. :S

    In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

  • Sooo ... ich hab jetzt einiges getestet und hier ist die eine Lösung, die ohne langwierige Berechnungen in KAREL auskommt:


    Die Startposition einer Bewegung und/oder die Zielposition einer Bewegung darf nahe einer Singularität sein.

    Auf dem Weg von Startposition zur Zielposition kann eine Singularität durchfahren werden.

    Ob World oder UserFrame ist dabei unerheblich.


    Auf der Steuerung muss dazu die Option R792 Singularity Avoidance vorhanden sein und ggf. für das entsprechende TP-Programm unter [SELECT] -> [DETAIL] -> [NEXT] -> [TRUE] aktiviert werden.


    Ist die Startposition nahe einer Singularität, die Zielposition aber nicht und wird auf dem Weg keine Singularität durchfahren, dann ist jeder Fahrbefehl für diese Bewegung möglich.


    Ist die Zielposition einer Bewegung nahe einer Singularität oder muss auf dem Weg von Startposition zur Zielposition eine Singularität durchfahren werden, dann können ausschließlich folgende Fahrbefehle für die Bewegung zu der Zielposition genutzt werden:

    L ... CNT

    L ... FINE

    L ... CNT ... Offset ...

    L ... FINE ... Offset ...

    Alle anderen Fahrbefehle resultieren in der Fehlermeldung MOTN-018 Position not reachable (G:<Nr. der Motion Group>).


    Ist die Zielposition nahe einer Singularität wird ggf. die Meldung MOTN-209 Modify Singular Dest (L:<Zeilennummer>) angezeigt.

    Wird eine Singularität durchfahren wird ggf. die Meldung MOTN-205 (<Progname>, <Zeilennummer>) Singularity angezeigt.

    Die Meldungen können mit dem Systemparameter $RA_PARAMGRP[].$WARNMESSENB = FALSE deaktiviert werden.



    Im Prinzip war der Lösungsvorschlag von DS186 schon der Richtige:

    3. Die betreffende Zwischenposition als lineare Bewegung (L PR[14] ...) ausführen. Wenn das nicht funktioniert, dann kannst du hinter die lineare Bewegung noch den Wrist Joint (Wjnt) Modifier setzen.

    Ich hatte beim ersten Lesen übersehen, daß das Wjnt hinzugefügt werden soll, wenn es nur mit einer linearen Bewegung nicht funktioniert. :whistling:

    In der Theorie sind Theorie und Praxis identisch. In der Praxis nicht.

  • Besten Dank für deine Rückmeldung. Noch eine kurze Info zur Option R792. Diese ist z.B. in der Option R809 (Motion Package) enthalten.


    Die Singularity Avoidance kann dann, wie von halbesYoyo beschrieben, in jedem Programm aktiviert werden, welches eine Bewegungsgruppe enthält.

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