Notorious error MOTN-017 Limit error (G:1, A:6)

  • Dear All,


    I have got an issue, with error MOTN-017 Limit error (G:1, A:6). From the documentation:

    Cause: Limit error.

    Remedy: Reteach the position out of limits.


    I believe that this means error with axis 6.

    After some analysis, I understand the following. As you see on attached picture, from conveyor side, the angle of J6 is under 180° (the configuration of coordinates id NUT 0,0,0). After robot approach the pallet side (when cross the thick red line), the angle of J6 becomes more than 180° and the configuration of coordinates becomes NUT 0,0,1. The position register I use, the configuration of coordinates id NUT 0,0,0. So my robot stops with error MOTN-017 Limit error (G:1, A:6).

    To sort the issue I put a new intermediate point (orange one on the picture) with configuration NUT 0,0,1. All position register used below red line (in pallet side) are with configuration NUT 0,0,1.

    I thought that the problem is sorted out but suddenly, on the way from pallet side to conveyor side, my robot stops again with the same error. I was in orange point (NUT 0,0,1) and next position was on conveyor side (NUT 0,0,0). Why that happen – no idea.

    In addition, because of the gripper mounting, my J6 is at angle 105°. This cannot be changed because of the mounting of the gripper and cables an air duct installed.


    Please share you experience and advise me how to resolve the issue – on my way from pallet side to conveyor side, the robot stops again with the same error.

    Any advice and information are highly appreciated!


    Best regards,

    Svetozar Yolov

  • AD
  • kwakisaki

    Approved the thread.
  • Problem is likely to be caused if you are using a L move, on L moves turn data on the positions is ignored so the robot find the shorter(but not always faster) path to the next point.


    If you have a lot of previous L moves and you don't have a J move on positions where a config change is needed (or if robot passes though a singularity on his way to that point), the robot may turn again and again the 6th axis instead of the 4th axis and it may reach the limit.


    Check on the position tab, with "joint" selected the degrees of the 6th axis when this happens.



    Also remember that if you move the robot with the instruction "move to" that appears on the PR data panel, the robot will always move to that position with an L move, so try to not teach the PR directly from there if you have not moved to that point though the program.

  • How to attach picture to the post?

    When drag & drop picture (PNG) green and blue area appears, depending where mouse is - on the icon menu or text area. When I drop the file - nothing happens.

    If I press Image icon, a dialog appears with source and link fields. I put window's path of the image in both fields or make different variations - I got "The entered link is invalid."


    How to attach image to the post?


    Svetozar

  • Here is my code. With asterisk, I pointed rows I changed to "survive" MOTN-017 fault.


    21: !commented line are the ones which make fault MOTN-017 ;

    23: //PR[29:47ToolOffset]=PR[4:47toolOffset] ;

    24: //PR[7:ConvEmptyOffset]=PR[64:incXn500] ;

    25: //J PR[22:47ConvEmpty] 100% CNT25 Offset,PR[7:ConvEmptyOffset] Tool_Offset,PR[29:47ToolOffset] ;

    21: !this the line, which replace rows 23-24. PR[23] is with configuration NUT 0,0,1 ;

    * 26:J PR[23:47ConvEmptyEvac] 100% CNT25 ;


    - - - - - - - some code


    58: !pick up from pallet ;

    59: !pallet position over KLT ;

    : !PR[20] is with configuration NUT 0,0,1 ;

    60:L PR[20:47PalEmptyBgn] 2000mm/sec FINE Offset,PR[5:PalEmptyOffset] Tool_Offset,PR[29:47ToolOffset] ;


    - - - - - - - some code


    47: !this code also cause a problem with raising MOTN-017;

    49: //J PR[22:47ConvEmpty] 100% CNT25 Offset,PR[7:ConvEmptyOffset] Tool_Offset,PR[29:47ToolOffset] ;

    * 50:L PR[23:47ConvEmptyEvac] 2000mm/sec CNT25 ;

    51: ;

    52: ;

    53: !move KLT little bit down ;

    54: PR[7,3:ConvEmptyOffset]=PR[7,3:ConvEmptyOffset]-80 ;

    : !this code was with motion type J but cause a problem (MOTN-017). That is why I changed to L. Now it is fine. PR[22] configuration is NUT 0,0,0 ;

    * 55:L PR[22:47ConvEmpty] 2000mm/sec CNT25 Offset,PR[7:ConvEmptyOffset] Tool_Offset,PR[29:47ToolOffset] ;


    Best regards,

    Svetozar

  • Hi

    I have questions

    1) When you pick from pallet. do you pick CW and CCW ?

    2) and when you place, is it one orientation only or you follow the CW/CCW from the pallet ?

    3) I'm assuming you use the orange point both ways. Is this point orientation CW or CCW. or half way in between ?

    4) I know is a copy and paste editing but on the program you show , the order of the line numbers don't match ? Are you missing something

    5) I bit confused because I don't see a point call PICK and another PLACE and I understand you can call them whatever your want but it's hard to follow the program

    6)make sure the offsets PR don't have any other value than the one you want and that they don't get overwritten

    7) how do you know where the boxes in the pallets are ? Vision. Just wondering because maybe, vision introduces an unnecessary value


    My thoughts

    I've seen these issues (personal experience) when the program accumulates the rotations. Sometimes you don't see the problem until you pick 3 or 4 parts. That is why I use a mid point (your orange) to unwind in joint configuration. The rest is easy , program should look like


    One PR (orange)

    One PR for picking and a couple PRs for offsets , and also the PRs to do calculations

    One PR (orange)

    One PR for placing and a couple PRs for offsets

    One PR (orange)


    One more things are you using values on you six axis such a 0 or 180 ? Try +/-179.999 and +/-0.001

    somar

  • Do you have PR calculations betwheen motions?


    I've experienced a bug on various controllers some time ago, this is what happened to me:


    If on the first lines of the program you select an UFRAME and one UTOOL diferent than 1 and then you do the PR calculations like adding offsets or getting coordinates from the PLC and putting them on different PR, for some reason the controller changes the tool number automatically to the UTOOL_NUM=1 without changing it using the UTOOL_NUM instruction.

    This was causing on my program a weird behaviour because I had 2 tools pretty similar, only changing the value of the tool Z... this caused the robot to reach axis limit sometimes because it was using the wrong tool when palletizing (the upper position was near the axis limit and a 10cm difference betwheen tools was enought to trigger the axis limit alarm when exiting the palletizing zone)

    All motions from that robots were calculated, so no P points on the program, and every routine started with a call to another subroutine to get data and calculate all points from the trajectory.



    This code was giving problems:

    UTOOL_NUM=2

    UFRAME_NUM=1

    CALL PR_CALCULATIONS (no tool change inside subroutine)

    .... logic and motion program ...

    J PR[X] 100% CNT100

    L PR[Y] 500MM/SEC CNT100

    L PR[Z] 500MM/SEC FINE

    ....



    I fixed it doing this:

    CALL PR_CALCULATIONS (no tool change inside subroutine)

    UTOOL_NUM=2

    UFRAME_NUM=1

    .... logic and motion program ...

    J PR[X] 100% CNT100

    L PR[Y] 500MM/SEC CNT100

    L PR[Z] 500MM/SEC FINE



    On PR_CALCULATION subroutine there was not any strange logic, only additions and substractions, copying from a PR the turn and NUT/FUT configs and then overwritting the XYZWPR values + doing all calculus from the place point backwards on a symetrical trajectory... so I do not understand how this could happen since no utool was selected again middle program.


    It was very weird and I think this issue may happpen on some firmware versions.

    Moving the utool and uframe instructions solved completelly the issue so check it if you can.


    I've seen a lot of strange things happen, and this is not the worse one... from robots colliding middle air because someone loaded a file not related to the calib data to collisions mid air after a "CALL" that was solved moving the call next to a fine point...





    If you can provide the full module logic without cutting and paste code maybe we can help you more.

    Edited once, last by Shellmer ().

  • Also... another thing... as fas as I remember, axis fault codes are represented in hexadecimal. That's the reason you sometimes see alarms like "Limit error G:1 A:10"... when you only have 6 axis and no external axis.


    So... "Limit error G:1 A:6" in reality refers to axis "Hex" 6, that in binary is 000110... each bit represents an axis, so you may have a problem with the axis 2/3 interaction limit. Is your robot very streched when going from that 2 problematic positions? Are that 2 points precalculated or are they static and do not change over time when depalletizing?


    If the robot is very streched, I suggest you to switch that 2 points to static ones or maybe limit the Z calculated coordinate from that 2 points to a lower value...

  • So a general rule of thumb: don't apply offsets to joint moves.


    A joint move must hit it's target wrist turn number. If you offset or dynamically calculate a joint move, you put yourself at risk of violating the turn number.



    Instead use a plain old taught joint move to a fixed position to move to approach positions of different areas. Once you are in an area, then use only linear moves, and feel free to offset as needed.


    Then when you move back to another area you can use a regular joint move to unwind the wrist.


    If you follow that rule of thumb you will be fine.


    I have had times where I needed to violate that rule, but that's best not done unless you really understand the implications.

  • That is a good advice...

    I also had problems with J moves when precalculating Z positions.

    Some times I had run into axis limits and the only way to avoid that was to limit the Z position so my config doesn't change on the previous J pos movement, then moving lineary to the destination point. This was also proven usseful when movements passed through singularity.


    Also as another rule of thumb do not try to use the modifier "Wjoint" since its very unreliable if you are calculating positions on the fly... it works well when you use it from fixed point to fixed point but if your program mess with coordinates its better to avoid it because sometimes unexpected motion occour due to config changes.




    In case you could not put a fixed point, you can always try to check for reachability using Karel before moving to the actual point... there is one function to check it before moving providing the position, utool and uframe.


    If NUT 000 is not reachable, you can check the same position with NUT 001 and if it reports ok, then use that other configuration, but this should be handled with care as you may need to also check if axis 6 is on a correct degree range converting the point from cartesian to axis values.



    Currently I'm doing that on an application... splitting the trajectory into little sections to check reachability and if config and turn numbers are correct before execuring a calculated trajectory on the fly. But to do that you must use karel... its complex but pretty satisfactory when it works.


    I think the best you can do is to put a fixed positions.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now