How to Write a Robot Program

Ok so you just got your new robot, now what? Besides EOA tooling, workcell equipment and control circuits, you need to design a robot program. But how do you start this process? Well, here a simple approach with a few guidelines.

Clearly define the work steps (ie, sequence) that your robot will need to execute for success. Try to keep it simple, and identify needed tasks with a top-down list. If the robot tasks are complicated use a flowchart to insure accuracy. Your program can be divided into several separate sections. The first is ‘initialization’. This is where you define all required constants, variables, robot parameters, servo definitions, robot positions (or axis points), inputs & outputs, and motion parameters (speeds, accelerations etc).

Second, you need to write the robots start (normal status) and re-start subroutines. Be aware, the robot can stop at any task or position, and will need to recover from any warning or error from that task/position. So you need to identify most conditions where something can go wrong to have the robot recover properly. For example, if the robot stops while it’s EOA tool is full, then it will need to continue to process those parts before going home or to it’s auto-start position.

In the third part, you can set-up a safety monitor. This subroutines watches for 'mistakes' and sets warnings, alarms & error flags when an unwanted situation occurs.

The fourth section, should be to ‘home’ to robot to the position you want for any manual mode activities, or the start of automatic mode. Of course all parts should be dropped, and any pneumatic axis (tool flip & rotate homed, grips open & vacuum off). Note that the home position should be a clear & safe position where you can turn off all tool functions. It may be that same as your automatic starting position.

Your program will need to provide mode switching between manual & automatic. Note that homing, jogging, setting outputs and changing positions should only occur in manual mode (except for point inching.) Likewise, auto mode should have sole control of all positioning and output circuits. You never want to have a conflict between operator actions and automatic control. Take note, an operator requests switching modes, and your program allows the switch if all needed requirements are met.

To ‘begin automatic’ mode you need to insure that all safety circuits are ok, that any auxiliary equipment is ready, that the molding press is in auto mode, the EOA tool is home, and all areas of the robot workcell are clear. For an insert-molding application, the following subroutines can be defined: 1) pick insert parts, 2) insert parts to mold and return home, 3) remove molded parts from press, and 4) drop parts off.

If possible, keep the auto mode sequence as simple as possible. When you consider how many things can go wrong it will get complicated enough. Remember, you have to deal with part feeder errors, parts not getting picked-up (do you retry of set an alarm?), insert parts getting dropped accidentally, parts not fitting into the mold, inability of the robot to properly remove molded parts, dropping of molded parts, and a drop-off conveyor or pallet being full. Especially interesting will be: control or motion errors, equipment alarms, immediate safety stops, emergency stops, or someone just pressing a stop button accidentally. Will your robot program see the incident and respond accordingly? If yes, then you’ve written a good program.

When an auto-cycle is complete, you can ‘goto’ the beginning of your auto subroutine. Just don’t use goto statements too often. The goto is the fastest way to write overly complicated “spaghetti code”. You can use the ‘gosub’ statement as much as you need to. Just make sure that nested gosubs are simple, so that exiting multiple subroutines can be done properly. When automatic cycling is complete, your robot may need to perform a shutdown routine, eg, drop off it’s EOA tool to the tool stand.

Now you have a simple outline for programming a robot. Note that testing your program under all possible conditions and events is very important. And remember, the village idiot is smarter than you. And given a chance to do something unexpectedly at the worst possible time, he will. Then crash goes your robot. Good luck with your coding. If you have any questions or need help, contact Bill Egert at Logic One. logicone@att.net