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

Example: 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 software is better than others, but in general, they will lack the usability and functionality found in the agnostic solutions. Why? Because the software is an afterthought for the robot manufacturers since 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 with 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.

• At least one demo must use your CAD. A real-world part that you are cutting. Don’t let the suitor get away easy by demonstrating their solutions on the perfect part they’ve chosen to demo 300 times before.

• 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 you have a dual-robot cell with a rotary positioner?

• 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 is 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?

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:

When I talk to our prospective customers, I remind them of the following:

The soft costs to deploy a piece of software are often 3x+ higher than the direct costs. The training time and the business process changes all have a cost. There is also work involved to trial the software on top of your already existing duties, etc.

The time investment cost is high. If the software fails to work as expected, a customer loses the time invested in evaluating, trialing, and deploying the software.

So, picking the wrong vendor can be a huge mistake in terms of time and productivity. It’s bad enough if the implementation fails. But what if you’d picked the “right” vendor instead, and it worked right away? That decision could save you a year or more of time. 

To learn more about InduSuite Solutions, please visit our CONTACT US page and submit your request. We look forward to speaking with you!