Best Practice for Top Level of robot program

Jaycephus

In my past robot projects on other platforms, especially if working with PLC control, I create a main loop, and a command processor within that loop. A handshaking protocol is created for each application, but often looks nearly identical. A command is given by the PLC in the form of a number on the robot side, and an 'execute' bit triggers the initiation of the command.

At that point, the robot is often starting a process of many steps, but to simplify control and recovery, the PLC is usually commanding discrete steps individually. This is more efficient when both 'picks' and 'places' can be from different sources and to different destinations.

Other processes may require the robot to complete the entire cycle from one given command, and this can be more complicated for the robot program to recover and continue after an interruption. 

With RAPID, I find that I have more options in how I can approach this.

What are the best ways to handle this kind of control in RAPID?

My experience is leading me toward this solution:

* A main loop command processor that waits for a PLC command.
(The PLC has the knowledge of what is currently in the robot cell. The command contains this information, in my case.)

* Once the command is given, the robot has the task of fully completing it, or recovering from an interruption, and completing it, unless and until a cancel is given.

* So, in a multi-step process, the process State must be tracked, and if an interruption occurs, the robot must resume from the last known state and successfully complete the original task before finally handshaking with the PLC to indicate that it is complete. 

Q: What is or are some best practices for cleanly handling this state tracking, and then resuming at the correct state after an interruption, in RAPID?

(I have experience with a simpler robot system that is a good deal more primitive than RAPID, and with Structured Text in a PLC that is closer to full-on real-time, multi-tasking Object Oriented Programming. Since RAPID falls into the middle between these two, I'd like to make sure I am making the best use of RAPID's capabilities.

I DO have the Multi-tasking option on my robot, but I know it isn't nearly as powerful as having a PLC.)


My current approach would be to always restart at the top of Main, and start at a 'command' processor, waiting for a PLC command. Then, if a command task was already in progress, skip that and go to a State processor, which would redirect the pointer to the next sub-task that had not yet been completed. For example, it might start up and go back to pick or 're-pick' the third thing in a process, and finish the final step, before signalling to the PLC that it's current command is complete.

My current state tracking is to create constants for each state, and then update the state at each point that I need to. If resuming from the top, the 'state processor' looks at the state variable to know what was last fully completed, and then jumps to the thing that it needs to do next. 

Thanks,