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

  • 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

    Retired but still helping

    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.

    Hi,


    sorry for delay answer.

    When I pic a basket, I rotate negative Z. This is because of the gripper mounting and supply of air and cables. There is a fastchanger connected to Z6 faceplate.

    I always go first negative Z and next positive Z to release the gripper. In addition I use -179.98 for negative Z and .02 to rotate positive Z.

    I provide only the rows, which I consider related to the problem I have. My program is very complex. I do not believe that someone will waste his time to study it.

    There is no PICK and PLACE part. I is rather:

    CALL ARC_KLT_LOCK – in order to lock basket with the gripper and

    CALL ARC_KLT_UNLOCK – in order to release the plastic basket.

    Unfortunately there no Vision option. It would be very nice to have it on board, but unfortunately, at the beginning of the project, my colleagues decided to get rid of it. I consider it as mistake.

    To sort the problem when I go through red line I use:

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

    Probably I must change it from J move to L move.

    On the way back I use:

    59:L PR[22:47ConvEmpty] 500mm/sec FINE Offset,PR[7:ConvEmptyOffset] Tool_Offset,PR[29:47ToolOffset] ;


    To HawkME,

    Many thanks for the advices. I consider myself still newbie in this field. From my experience, as you point, the move from one area to another it is good idea to use J (joint) moves, which are fast and do not stops at the intermediate points. When robot is into area, using L (linear) move is better.

    Please can you clarify the idea for “when you move back to another area you can use a regular joint move to unwind the wrist.”. What you mean by that? To return the twist at it start position – right?

    In the forum I also met the word “untwist” which I believe got the same meaning.


    At the end, I would like to thank you of you all for your time and knowledge you shared with me.

    Svetozar Yolov

    Right.


    As Shellmer started, if you only ever do L moves you can inadvertantly keep twisting the wrist the same direction and hit a limit or break cables. To prevent that you must use a Joint move to a fixed position to return to a known turn number (untwist the wrist). When you do that joint move, it should not use any calculated PR or offset. It should just be J P[x]. If you use a calculated PR or offset then you can inadvertantly add an extra rotation to the wrist.

    Dear Hawk,


    From my current perspective I used only PR[] im my program. My understanding is that they provide me with greater flexibility. in addition, when we need to relocate the robot from test center to real installlation, I need to teach just a few points.

    From your post, I understand that in the program is very good idea to have som key point in the program. Is that you mean? If it is so, can you give me some advice where to used them?

    At present I am working on depalletizing/palletizing solution. On robot one side there is depalletizing station. From pallet, the ropbot place basket on conveyor.

    On robot other side there is another pallet, where robot palletizimh full baskets. In this paradigm, where is good idea to use points, to untwist the robot wrist?


    Best regards,

    Svetozar

    I would create a fixed point as a perch point in front of each pallet station and your conveyor.


    It can be a P or a PR, it just needs to be something that never changes. If you use a PR just make sure everyone knows not to change that PR programmatically. Teach it once and leave it alone. Both P and PR can be relative to a user frame, so if your installed position changes the frame, they will both still work correctly.

Advertising from our partners