Offline Programming and Simulation

Offline proramming has always been an aspiration for the IT community. This does not necessarily make it a desirable thing.

Early robot control saw an offline controller developing parallel to the VAL controller. This required the development of 2 controllers rather than one. The product was called simulator and it was capable of executing a complete program without satisfying the location criteria monitored during movement of the arm.

This proved an expensive approach to a simple problem. Language continued to develop and enabled the standard robot controller to execute a dry run without location data. This has always been about code and syntax. To prove that the logic will run without inputs and outputs is easily achieved using a manual signal simulator.

It is impractical and unsafe to consider writing a robot program offline, defining arm co-ordinates and running the program without a visual, low speed dry run. It has only ever been possible to prove the logic offline. Locations must be defined by operators working within the robot enevelope to teach points. In truly hostile environments where it is not possible to work in this way, the preference is for teleoperation and visual aids.

Simulation was big in the 1980's. All the computer boys were selling the benefits of simulating new production systems prior to building and running them. They proposed that the risk could be removed from the process by laying out notional equipment and plotting proposed trajectories. The main problem they faced related to intellectual property. The robot manufacturers were unwilling to release details of drive characteristics. Without this the simulations could never be accurate.

Although application simulations failed to deliver, there is great value in workflow analysis looking at product mix and quantity in more detail. The latest systems can be used to check for bottlenecks, material shortages and workforce combinations to optimise the process.