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

There is no attached picture. Also post your code.

Without seeing what you are doing, my best guess is that you need change that movement to a Linear move.

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.

Quote from yolovs

How to attach picture to the post?

At the bottom of the entry field, there is a paperclip symbol. Click on that symbol, you will see an upload button.

Can you post your program too. You must have a motion type that needs changed. Are you using L or J for your moves across that line. What about your first move to a starting position?

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

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.

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.

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.

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.