Offline Programming (OLP) and simulation are closely related, but they’re not the same. Confused? Here is the simple explanation of this fundamental question.
What is robotic offline programming?
What is robotic simulation?
Are they the same thing?
These terms are often used together in a way that suggests that they have equal meaning (e.g. “OLP/Simulation”) but they are not exactly the same.
You could easily get confused and exasperated if you tried to use a robot simulator for offline programming. What’s worse, it could lead to you wasting many hours trying to get the wrong software to perform a task it wasn’t designed to do.
It’s time to set things straight.
Offline Programming vs Simulation: Are They The Same Thing?
The basic answer is: No, offline programming and simulation are not the same things.
But, in robotics, they are very closely related… in most cases.
Here’s a Venn diagram to show how the two terms are related:
As you can see, offline programming always involves simulation — with a small exception which I’ll explain in a moment. However, there are a vast number of simulators which have nothing to do with offline programming (or with robotics, for that matter).
A good rule of thumb is to say:
(Almost) All Offline Programming is Simulation
Not All Simulation is Offline Programming.
What is Robot Simulation?
A simulator is a piece of mechanical equipment or a software program which is designed to represent the conditions in a physical environment. Said another way, simulation involves imitating the real world.
The classic example of a simulator (from outside of robotics) is a flight simulator for training pilots. This machine includes both hardware and software elements to look and behave realistically like a real airplane.
In robotics, simulation is used for various purposes, including:
- To test the functionality of robot programs in a safe environment where the robot cannot harm itself or the environment.
- To test hundreds of different program permutations in a short amount of time to optimize the program.
- To run the program when no physical robot exists or one is not available.
- To create a proof of concept before you purchase a physical robot.
Many robot simulators involve a graphical representation of the robot (as is the case in RoboDK). This is useful because it allows you to see what the simulation algorithms are actually doing underneath. Some of these simulators only have basic graphics (e.g. lines to represent the robot’s links), whilst others allow you to model the entire workspace and use a realistic model of the robot.
However, although graphics are very common it is possible to have a simulation with no graphics at all. Some simulators only contain algorithms and a basic command-line interface. As long as the underlying algorithms are the same, these can be as “realistic” as those simulators which include graphics. For example, RoboDK can be used via the command line and API.
What is Offline Programming (OLP)?
Offline programming refers to the practice of programming a machine (usually a robot or a CNC machine) without having the physical machine present. In other words, you first create the program on a computer and then later download it to the physical machine later.
In robotics, offline programming is used for a range of reasons, including:
- To save you time compared to conventional (online) robot programming. There are many ways that OLP saves time and helps you to improve your process’s productivity.
- To access more advanced robot functionality by using specially designed software wizards and libraries. OLP is suited to a variety of different tasks, which it can often achieve more effectively than with conventional programming.
- To create a proof of concept before purchasing a robot, but in a way that allows you to use the same program when you do choose your robot.
- To streamline your software workflow.
Most offline programming packages include a simulator for your chosen robot. First, you program the robot in the virtual environment. Then, when you have debugged your program and it is running smoothly, you transfer it to the physical robot. The offline programming software achieves this using a “post processor” which turns the simulated program into code that the physical robot will understand.
This method allows you to iron out any problems in the programming quickly and easily using the simulator, without affecting the uptime of the physical robot.
When OLP Doesn’t Include Simulation
There is one situation where you would program a robot offline without using a simulator. This would be if you just programmed the robot in its native programming language using a text editor in your computer and then downloaded it directly to the physical robot once the entire program had been written.
Although this situation could technically be called “offline programming” — after all, you are still doing all the programming offline — it is not what we are usually referring to when we talk about OLP. Usually, we mean programming a simulated robot.
Also, it is a terrible idea. If you have done any programming before, you’ll know that creating an entire program before doing any testing is a recipe for disaster. It’s much more effective to build up your program step-by-step and use a good simulator to see the effect of your instructions on a virtual robot.
How OLP and Simulation Work Together
As you can see, offline programming and robot simulation are very closely related. In all practical situations, offline programming software also includes a simulator.
This is certainly the case with RoboDK. Most of our users use it for OLP but some use it as a pure simulator, depending on their needs.
The major difference between the OLP and simulation is that final extra step. OLP always needs to convert the simulation into a program that can actually be used to control the physical robot.
Many robot simulators do not contain that extra step. They can realistically simulate the robot and environment, but they cannot convert the simulation into usable robot code.
A good OLP software, on the other hand, will make the transition from simulation to real robot as seamless as possible.