Content area
Full Text
A robot technologies continue to improve and evolve, the choices facing today's robotics buyers continue to expand as well. How do you know what type of robot to choose? How can you avoid mistakes that you may not be aware of, even if you've successfully applied robotics technologies in the past? With investments ranging from tens of thousands to potentially millions of dollars, it's critical to make the right choice the first time and to avoid common mistakes that could add substantial unnecessary cost or result in project delays. To help engineers and manufacturing personnel avoid the worst pitfalls, I've listed the top ten robotics application mistakes I've seen in my 20 years in the automation business.
1
Mistake 1: Underestimating Payload And Inertia Requirements
The No. 1 application mistake made by robot users is underestimating the payload associated with a given application. The most common cause is failure to include the weight of the end-of-arm tool in the payload calculation. The second most common cause is underestimating or completely ignoring the inertia forces generated by offcenter payloads. Inertia forces can overload a robot axis. It is very common to overload the rotational axis on a SCARA robot. Failure to correct the problem also may cause damage to the robot.
Reduction of payload and/or reduction of speed parameters could remedy the situation. Reducing the speed, however, may cause an unwanted increase in cycle time - a cycle time which may have been part of the ROI calculations in justifying the purchase of the robot in the first place. That's why it's critical to consider all load-related factors from the very beginning.
2
Mistake 2: Trying To Do Too Much With the Robot
Sometimes the awesome capability and flexibility of a robot can cause a designer to over task the robot and make the work cell too complex. The result once again could be failure to make cycle time, or it could lead to extremely difficult programming solutions or even to difficulties with processor speed limitations. This mistake is further magnified when users other than the system designer try to troubleshoot the work cell once in production. Unplanned down time can be very costly in a production environment.
Another common manifestation of over tasking the robot...