OLRP: What are your options? What is important?

Jon House, Head of Sales and Marketing

What is Offline Robot Programming (OLRP)?

If you’re new to OLRP, we have a couple of resources to get you familiar.

What are your industry options for OLRP? Who offers OLRP?

Once you decide that OLRP will provide value to you, where do you look? Here is a breakdown of your options:

1. Robot Manufacturers (OEM) Solutions
   
   
2. Agnostic OLRP
   1. Low-Cost solutions
   2. Mid-Range solutions 
   3. High-Cost solutions

OEM Solution
I.e. Roboguide for Fanuc. Motosim for Motoman. Etc.

These have their place, so you should look at them! Some things to consider.

1. From a cost perspective, as a rule of thumb, these will be ~ 1/3rd the price of the Mid-Range Agnostic Solutions.
   
   
2. The integration with the robot will be very tight with the OEM solution. For example, Motosim will have support for all the Motoman specific functions found on your controller. Also, Post Processors will require almost no customization. This software can also be considered a virtual teach pendant. Lastly, aligning the virtual world with the real world should be relatively seamless.
   
   
3. They are brand specific. So, if you have multiple brands of robots, you will have to pay for, learn, and maintain multiple different software with varying capabilities.
   
   
4. Certain OEM softwares are better than others, but in general, they will lack the usability and functionality found in the agnostic solutions. Why? I believe it is because the software is an afterthought for the Robot Manufacturers, as their focus is on the hardware. So, what problem are you trying to solve with an OLRP solution? And how important is it to fix that problem?
   
   
5. How often do they improve their software with impactful new features? Ask them to show you. 

Agnostic OLRP
Some things to consider:

1. Do you want to solve the entire problem or just part of the problem? The low-cost solution may be better than nothing, but it will likely not truly solve your problem. Why? The low-cost solution can likely not program paths on even semi-complex geometry. They likely do not have support for advanced functions, like error avoidance. They likely do not have a robust training and support program. So, do you want to fully solve the problem?
   
   
2. Do you need 100% accurate cycle times? Or just something close enough? The high-cost solutions will likely have the RCS (Realistic Controller Simulation) modules built-in, which will give you spot on cycle times. 100% accurate cycle times are important for certain industries like automotive. But if you are in General Industry, this is likely not critical for you. The mid-range solution will provide you relatively accurate cycle times at a much lower price.
   
   
3. The implementation process (calibrating the virtual world with the real world) is an extremely critical part of the solution. Don’t just trust that the pretty picture on the screen will translate flawlessly to the real world. Ask for customer references. OLRP is not very valuable if it is not driving the robot to the exact right coordinates in the real world. More on implementation here.

What to look for in a demo

The demonstration is the key meeting in the evaluation process. It’s where you get a feel for how the software flows and what it’s capable of. You try to envision yourself or your team using the software. Here are my recommendations for you, the potential customer, going into the demo stage.

1. At least one demo must use your CAD. A real-world part that you are cutting. Don’t let the suitor getaway easy by demonstrating on their perfect part that they’ve demoed on 300 times before.
   
   
2. The demo should at least mimic your real-world cell. Don’t let the suitor build a demo cell that is oversimplified and leaves out important real-world features. Why would you want to see a demo of a single robot cell when in reality you have a dual-robot cell with a rotary positioner?
   
   
3. It should look easy, the interface should be nice, and all that stuff. But at the end of the day, the three most important aspects of the software for you should be, 1) How effectively can the software create the correct paths for your application? 2) How effectively can the software avoid errors (joint limits, collisions, singularities, etc.). And 3) How effectively can the software post out the correct program to my robot? Everything beyond those three items are just nice-to-haves. Go deep with evaluating how functional the software is on items 1, 2 & 3. Here are some questions:
   1. How do I create a path?
   2. Can I copy that path elsewhere?
   3. How do I go back in to edit that path?
   4. How do I edit multiple paths at the same time?
   5. How do I ensure my program is error-free?
   6. Can I import and program CAM paths on my robot?
   7. Can you show me what the finished code looks like?
   8. What’s the last feature you developed and pushed out to your customers related to 1, 2, or 3. When did you release it, and why did you develop it?

And some red flags to watch for:

1. Be concerned if the vendor shrugs off the specifics related to your equipment because they are probably making a lot of assumptions that will undoubtedly result in major hiccups when implementing and supporting. The vendor should want to know quite a bit about your equipment (make & models, options, robot backups, expectations, etc.)
   
   
2. Be concerned if the vendor does not want to offer a trial. It is free for the vendor to do this.
   
   
3. Be concerned if the vendor does not want to offer references. Somebody who is using the software every single day to create programs.
   
   
4. Be concerned if the vendor has not pushed out any impactful features in the last 3-5 months. 

A final thought to leave you with.

When I talk to our prospective customers, I remind them that:

• The soft costs to deploy a piece of software are often 3x+ higher than the direct costs. The training, The business process change. The work to trial the software on top of your already existing duties. Etc. Etc.
  
  
• The time investment cost is high. If the software fails to work as expected, the customer loses all that time invested in evaluating, trialing, and deploying the software.
  
  
• Picking the wrong vendor can be a huge mistake in terms of time + productivity. It’s bad enough if the implementation fails. But what if you’d picked the “right” vendor instead, and it actually worked right away. That could have saved you a year or more. A year or more is a long, important amount of time…