SRVO-115 Limit error bei linearen Bewegungen

    Moin,


    über einen kleinen Umweg kann man bei ABB vorab die Erreichbarkeit eines (Ziel)punktes ermitteln. Falls er nicht erreichbar ist, wird ein abfangbarer Fehler ausgegeben:



    Gibt es sowas in der Art auch bei fanuc? Von mir aus auch irgendwie als workaround. :/


    Ich frage deshalb, weil mein Programm ab und an mit der Meldung SRVO-115 Limit error stehenbleibt: von einer Startposition soll der Roboter linear eine (von einer Kamera ermittelte) Zielposition anfahren. Wenn aber z.B. Achse 6 an der Startposition bei 182° steht und an der Zielposition einen Winkel von 253° hätte kann das nicht gehen, weil der Achsbereich der Achse von -220° bis 220° geht.


    Blöderweise kann diese spezielle Bewegung nicht in joint erfolgen, weil es die Bewegung auf das Bauteil ist. Meine Idee wäre deshalb vorher zu prüfen, ob die Position erreichbar ist, und, falls nicht, eine Zwischenposition über dem Bauteil per joint anzufahren. Immer eine entsprechende Zwischenposition anzufahren soll möglichst vermieden werden, weil es unnötig die Taktzeit verlängern würde.


    Gruß

    Jörn

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

    • ANZEIGE

    Hi halbesYoyo


    In TP wird's schwierig... ggf. MROT-Option.


    es gibt mehrere Karel-Built-In's mir denen du so etwas machen kannst.


    Ich würde jetzt mal zu

    CHECK_EPOS
    tendieren, auch wenn du keine Rail/Ext Achse hast.


    IN_RANGE Built-In Function


    Purpose: Returns a BOOLEAN value indicating whether or not the specified position argument can be reached by a group of axes


    Syntax : IN_RANGE(posn)


    Function Return Type :BOOLEAN


    Input/Output Parameters:


    [in] posn : XYZWPREXT


    %ENVIRONMENT Group :SYSTEM


    Details:


    • The returned value is TRUE if posn is within the work envelope of the group of axes; otherwise, FALSE is returned.

    • The current $UFRAME and $UTOOL are applied to posn .


    J_IN_RANGE Built-In Function


    Purpose: Returns a BOOLEAN value indicating whether or not the specified joint position argument

    can be reached by a group of axes


    Syntax : J_IN_RANGE(posn)



    CHECK_EPOS Built-In Procedure


    Purpose: Checks that the specified position is valid and that no motion errors will be generated

    when moving to this position


    Syntax : CHECK_EPOS (eposn, uframe, utool, status <, group_no>)


    Input/Output Parameters :


    [in] eposn :XYZWPREXT


    [in] uframe :POSITION


    [in] utool :POSITION


    [out] status :INTEGER


    [in] group_no :INTEGER


    %ENVIRONMENT Group :PBCORE


    Details:


    • eposn is the XYZWPREXT position to be checked.

    • uframe specifies the uframe position to use with eposn.

    • utool specifies the utool position to use with eposn.

    • status explains the status of the check. If the position is reachable, the status will be 0.

    • group_no is optional, but if specified will be the group number for eposn . If not specified the

    default group of the program is used.


    Beste Grüße

    PnsStarter

    Moin PnsStarter,


    vielen Dank für die unzähligen Stunden Sucherei, die Du mir erspart hast. ^^


    Über das MROT bin ich im englischen Forum schon gestolpert. Das wäre, so wie ich es verstanden habe, eigentlich ziemlich genau das, was ich suche. Blöderweise ist das eine "Optional Function".


    KAREL ist kein Problem. Ich hab bereits ein paar Programme geschrieben, u.a. einen tauglichen Zufallszahlengenerator. Von den Beschreibungen her würde IN_RANGE reichen, es wird aber eher CHECK_EPOS, weil ich da nicht erst auf den passenden UFrame und das TOOL wechseln muss. Ich teste das mal.


    Gruß

    Jörn

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

    Moin,


    sooo, das KAREL-Programm ist fertig. 8)


    Der erste anzufahrende Zielpunkt ist per JOINT anfahrbar. Bei LINEAR gibt es eine Meldung MOTN-023 In Singularity (sogar bevor der Roboter sich bewegt). CHECK_EPOS gibt 0 (also erreichbar) zurück.


    Beim zweiten anzufahrenden Zielpunkt hab ich genau unsere Situation nachgebildet. Achse 6 steht bei rund 170°, der Zielpunkt ist etwa -300° entfernt, Beim Anfahren mit JOINT dreht er fast komplett rum. Mit LINEAR nimmt er den kürzeren Weg, fährt dabei in die Achsgrenze und gibt den bekannten Fehler SRVO-115 Limit error aus. Auch hier gibt CHECK_EPOS eine 0 (erreichbar) zurück.


    Ich hab auch einen mit X=3471.0 ganz bestimmt nicht erreichbaren Punkt getestet. Da gibt CHECK_EPOS korrekt keine 0, sondern den Wert 15018 zurück, was der Fehlermeldung MOTN-018 Position not reachable entspricht.


    Es sieht danach aus, als funktioniere CHECK_EPOS nur mit JOINT-, aber nicht mit LINEAR-Bewegungen!? Falls das in den Handbüchern steht, hat FANUC das (mal wieder) gut versteckt.


    Gruß

    Jörn

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

    Naja eigentlich ist das schon klar. Damit Check_EPOS die Erreichbarkeit eines linearen Punktes ermitteln kann, müßte auch der Startpunkt mit angegeben sein, wie soll der sonst ermitteln, ob es für die Bewegung eine kinematische Lösung gibt.

    Ich vermute mal, es wird die reine Erreichbarkeit des Punktes geprüft, deswegen auch die Position not reachable Meldung ausgegeben und nicht Limit Error.


    just my 2 cents

    Der Startpunkt ist die aktuelle Position - er soll sich ja von dort mit dem Fahrbefehl zur Zielposition bewegen. ;)


    Bei J-Bewegungen wird ja im Voraus berechnet, wie sich alle Achsen bewegen müssen, damit sie gleichzeitig dort ankommen. Deshalb ergibt sich bei diesen Berechnungen auch die Erreichbarkeit und es gibt ggf. ein Not reachable.


    Bei L-Bewegungen kommt es drauf an, wie es programmiert ist. Wenn einfach nur die min. Differenz zwischen Start- und Zielposition ermittelt und dann - ohne weitere Prüfung - die Bewegung gestartet wird, dann endet es halt u.U. mit einem Limit error.


    Ich hab zwischenzeitlich Hinweise auf die Option MROT gefunden und diese getestet. Wenn man die mit einer L-Bewegungen nutzt, nimmt der Roboter ebenfalls den kürzesten Weg von Start- zu Zielposition, achtet dabei aber auf die Achsgrenzen. Wenn der Zielpunkt "hinter" einer Achsgrenze liegt, wenn er den (real) kürzeren Weg nähme, bewegt sich der Roboter stattdessen anders herum. 8)

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

    Moin, gibt es zu diesem Fall eine Lösung? Habe genau das gleiche Problem:


    Roboter fährt in J auf die Vorpos, welche 100mm über dem Bauteil liegt und muss dann in L das Bauteil abholen, tut er aber nicht, aufgrund Axis Limit. Achse 4 würde über die -200 grad müssen.

    Die Vorpos wird in MROT angefahren.


    Den Punkt selber kann ich keinesfalls umteachen o.ä., da die Depalletier Daten von der SPS kommen..


    Vielen Dank im Voraus und LG

    Moin,


    das hängt vom Modell, der genauen Stellung der Achsen und den Achskonfigurationen ab.


    Wenn der FANUC ziemlich gestreckt steht, könntest Du probieren eine zweite Vorpos über dem Bauteil mit L ... MROT anzufahren.

    (In dem Beispiel wird vorausgesetzt, daß +Z Stoßrichtung ist und das Bauteil genau in Stoßrichtung liegt)


    Code
    J PR[1:Vorpos] 100% FINE

  ! 10mm von Vorpos Richtung Bauteil in +Z
  PR[3:Offset]=PR[3:Offset]-PR[3:Offset]
  PR[3,3:Offset]=...
L PR[2:Bauteil] 50mm/sec FINE Tool_Offset,PR[3:Offset] MROT

L PR[2:Bauteil] 50mm/sec FINE


    Das Offset (Zeile 5) musst Du dabei so wählen, dass Achse 4 da bereits das Achslimit überschritten haben würde. Dann sollte der FANUC wegen des MROT Achse 4 passend umorientieren. Je weniger gestreckt der FANUC steht, desto wilder könnte auf dem Weg zu dieser Position der Tanz ausfallen, den Achse 5 und/oder 6 aufführen, weil die u.U. sehr viel umorientieren müssen.


    Bei mir ging das so leider nicht. Ich bekomme auch Zielpositionen von der SPS. Ich habe testweise in 100mm Raster alle Positionen angefahren, um zu schauen, mit welcher Achskonfiguration sie erreichbar sind. Im Programm lade ich nun vorab anhand der Zielposition ein PR mit einer passenden Achskonfiguration aus und schreibe die Zielkoordinaten (XYZWPR) noch dazu. Es bläht den Code auf und sieht nicht schön aus, aber es funktioniert immerhin.



    Gruß

    Jörn

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

    Einmal editiert, zuletzt von halbesYoyo () aus folgendem Grund: Zielennummern entfernt. Copy'n'paste-Fehler beseitigt.

    vielen lieben Dank für diese ausführliche Antwort, bei mir hat es tatsächlich gereicht, die Vorpos auf 75mm über Bauteil zu verringern, dann war wohl der Weg über das Achslimit gespart :)

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