Robot Work Envelope Considerations

Put your robot in a good spot or suffer the consequences. It may seem obvious, but the best programming in the world may not be able to save a system where the robot has to struggle to get from point A to point B.

Palletizing

One of the first problems I had to solve as the newly appointed M-410iB product manager back in 2008 was where both an end-user and an integrator were blaming FANUC for overheat and throughput problems. “You claimed that this robot could do 28 bags per minute,” the integrator exclaimed. “We can barely do 20 without getting J2 overheats. We bought the fan kit and everything… this must be a faulty robot.”

I, Robot

It’s easy to just move on after merely getting something to work when you’re using an incredibly fast and robust robot. The robot moves the heavy thing from point A to point B and you even have a little cycle time to spare. The customer’s happy; you’re happy; time to celebrate, right?

But what about the robot? Is the robot happy too? Would you be happy performing that task all day? Certainly not, but if you had to do it for a little while, would you do it like you just taught the robot, or would you tweak a couple of things to make it a little easier?

Intelligent Part-Presence

Good material handling applications typically include many part-presence sensors: proximity switches on fixtures or machine tools, photo eyes or gripper open/closed/overtravel switches on end-of-arm tools, etc. How and when do you use them most effectively?

I check part-presence liberally. If something has gone awry with your automation, you want to realize it as soon as possible to minimize damage. Take a simple pick routine as an example:

1. Make sure the part is present at the fixture
   It doesn’t make much sense to pick a part that isn’t there.
2. Make sure the gripper is open and empty
   The robot will probably crash if the gripper is not open and will almost certainly crash if’s it already gripping a part. If the gripper IO is not functional here, you’ll hopefully detect it before it becomes a bigger problem (e.g. after you’ve picked up a 100lb part).
3. Move to the part
4. Grip the part
5. Make sure the gripper is closed and the part is present within the gripper
   If you have the IO, use it.
6. Retreat from the fixture
7. Make sure the gripper is still closed and the part is still there
   Even if the gripper IO was satisfied at the fixture, it could be a bad grip that lets go as soon as you leave.
8. Make sure the fixture is now empty If a sensor fails, you want to know about it as soon as possible. It’s more important to make this check when loading, but it’s worthwhile checking here too. On the load side, you’ll want to know that a part is incorrectly seated before you bash into that “empty” fixture at 2000mm/s on the next load cycle.

Of the 8 steps in that sequence, 5 involve part part-presence IO. Skipping any one of those checks could be a dangerous oversight.

To ACC or not to ACC

That is the question. And the answer is “probably not.”

Once a programmer learns that the ACC instruction exists (and figures out how to make it go over 100) this is often the first place they go to make the robot faster. It’s such an easy change to make with immediate results, but there are serious consequences. I’d argue that going over ACC100 should only be done as a last resort.