# Define working range for robot axis (not safety limits)

• Hello,

I'm working on a pick & place project where the robot picks from a conveyor and deposits the products in predefined positions. The products have to be picked from a certain orientation so that they're placed correctly everytime. The coordinates and orientation are sent by a camera so I don't have the exact Status and Turn for the place the robot needs to go to pick the product.

My problem is that the controller maintains the S and T from the previous motion so sometimes it performs the shortest motion and sometimes A6 turns 360° more than it should. I want to be able to limit the motion range of axis A6 on a KR3 R540 robot so that it works between -180 and 180.

The only solution I could come up with is geometrically calculate the position of A6 on the end point and set the bit 5 of Turn so that it takes the path I prefer. This is a complicated solution because it works for this particular setup, so what I want is a way to set conditions for the motion planner to take into account. For example to choose the shortest path and disregard the previous Turn or set working limits for an axis (but not the ones that stop the robot for safety purposes). Is this possible?

I've been reading all the manuals I think can be relevant for this but I couldn't find anything.

Thanks

• so you do have a solution...

2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

• Yes, but one that is only suitable for these exact conditions. I'd like something more applicable to different situations.

• check KUEWEG.SRC. it is supplied with every robot and shows pretty much general case - how to make wrist motions minimal.

2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

• My problem is that the controller maintains the S and T from the previous motion

What does this mean, exactly? Do you mean that the robot stays physically in the last S&T combination?

If so, the simplest solution would be to use an E6AXIS point to "unwind" the wrist axes to an optimum set of angles during the path from dropoff back to the pickup area. And sticking to LIN motions after this "unwind" motion, so that the S&Ts that result from the camera data don't have any effect.

Limiting the camera Rz range also helps -- what range does the camera send over? +/- 90? +/-180? 0-360?

• Quote

What does this mean, exactly? Do you mean that the robot stays physically in the last S&T combination?

Yes, the KSS manual says for SPTP motion instructions:

Quote

If not all components of the end point are specified, the controller takes the values of the previous position for the missing components.

The start point for the motion I want to perform is completely defined with S&T, but the end point isn't because I didn't know how the robot axis would end up when picking up the object with the coordinates from the camera.

And sticking to LIN motions after this "unwind" motion, so that the S&Ts that result from the camera data don't have any effect.

I didn't want to use LIN motions because they can be much slower than PTP and speed is critical in my application as one whole pick & place cycle should take just 1s.

This way the axis always "unwinds" but my problem was how to determine the optimal path for the A6 axis to take. For some end points A6 would turn 270° in one direction for example instead of 90° in the opposite direction, just to maintain the start point's Turn.

As my problem can be reduced to a 2D situation, I calculated an equation which, from the relative position of the pick location to the robot, calculates A6 (assuming A4 stays in or near 0° and knowing A1 is always positive), and I set the bit 5 of Turn accordingly. This works fine but I wanted to know if there was a more general way to solve this issue. I still have to try to implement the solution panic mode suggested but it seems that is what I was looking for.

Thanks to the both of you!

• Ah. Yes, KUEWEG should serve in this case.

An alternate approach would be to program your camera-guided points as FRAMEs rather then POSs. Even with PTP motions, using FRAMEs (which have no S or T value) will cause the path planner to automatically choose a least-motion path (in axis space) to the destination. The downside of this approach is that, if you set up these points as Inline Forms, anyone renaming the points or adding new points will cause them to be (re)created as E6POSs.