Robot Happiness

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.

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?

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:
Make sure the part is present at the fixture

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.