Offline Robot Programming (OLRP) enables robot functions to be programmed in a virtual environment, independent of the actual real-world robot cell. Realistically, however, there are challenges in ensuring the virtual-world and the real-world align; this alignment is critical for the success of OLRP. "Which real-world robot functions assist with successful OLRP implementation & deployment?" We've seen this question come up often, so we pulled together a list.
1. Mastered Robot
In the virtual world, the robot is always mastered and therefore perfect; it'll drive exactly where it needs to go. In the real world, that is not always the case. If the robot is not mastered, the robot will think it's in a different position than it actually is. If that’s the case, your offline program will not work as expected; it is going to drive to the wrong place. Buying a new robot? Make sure your integrator “masters” the robot. Not sure if your existing robot is “mastered”? Call your integrator!
2. Robot Backup
A robot backup file taken from the real-world robot gives your OLRP provider an understanding of what needs to be supported, as every robot controller is set up a little differently. Your robot backup files contain unique options and code structures that are critical for dialing in the post-processors which generate the robot code.
3. Seam Finding & Seam Tracking
CAD is perfect. Or, it should be perfect. But the real-world never is. To account for discrepancies, touch sensing, and/or seam tracking and/or vision systems are all critical in ensuring the real-world robot correctly locates the area of the part to perform its desired function. Without these systems, touch-ups can be expected.
4. Accurate CAD Geometry
Pretty obvious, right? But this is something we see often. If your CAD drawing is off or is of low-quality, then OLRP will be off. OLRP is only as good as its CAD.
5. Precise References
Even with a mastered robot, your program will require touch-ups if your Tool Center Point, or TCP, and/or your User Reference System (Uframe, BASE_DATA, work object, etc.) aren’t precise. Ensuring these references are where they need to be before executing a program will save you a lot of headaches.