The events in a robot cell are often in parallel, so why are the programs not in parallel?

Multitasking RAPID is a way to execute programs in (pseudo) parallel with the nor-mal execution. The execution is started at power on and will continue for ever, unless an error occurs in that program. One parallel program can be placed in the background or foreground of another program. It can also be on the same level as another program.To use this function the robot must be configured with one extra TASK for each back-ground program.

Up to 10 different tasks can be run in pseudo parallel. Each task consists of a set of modules, in the same way as the normal program. All the modules are local in each task.Variables and constants are local in each task, but persistents are not. A persistent with the same name and type is reachable in all tasks. If two persistents have the same name, but their type or size (array dimension) differ, a runtime error will occur. A task has its own trap handling and the event routines are triggered only on its own task system states (e.g. Start/Stop/Restart....).

There are a few restrictions on the use of Multitasking RAPID.

•  Do not mix up parallel programs with a PLC. The response time is the same as the interrupt response time for one task. This is true, of course, when the task is not in the background of another busy program
•  There is only one physical Teach Pendent, so be careful that a TPWrite request is not mixed in the Operator Window for all tasks.
•  When running a Wait instruction in manual mode, a simulation box will come up after 3 seconds. This will only occur in the main task.
•  Move instructions can only be executed in the main task (the task bind to pro-gram instance 0
•  The execution of a task will halt during the time that some other tasks are accessing the file system, that is if the operator chooses to save or open a pro-gram, or if the program in a task uses the load/erase/read/write instructions.
•  The Teach Pendent cannot access other tasks than the main task. So, the devel-opment of RAPID programs for other tasks can only be done if the code is loaded into the main task, or off-line.

In many applications a parallel task only supervises some cell unit, quite independently of the other tasks being executed. In such cases, no synchronisation mechanism is nec-essary.But there are other applications which need to know what the main task is doing, for example.

This is the easiest way to do it, but the performance will be the slowest.

Persistents are then used together with the instructions WaitUntil, IF, WHILE or GOTO.

If the instruction WaitUntil is used, it will poll internally every 100 ms. Do not poll more frequently in other implementations.

The instruction SetDO and ISignalDO are used.

All types of data can be sent between two (or more) tasks with persistent variables. A persistent variable is global in all tasks. The persistent variable must be of the same type and size (array dimension) in all tasks that declared it. Otherwise a runtime error will occur.

All declarations must specify an init value to the persistent variable, but only the first module loaded with the declaration will use it.

Each extra task (not 0) is started in the system start sequence. If the task is of typeSTATIC, it will be restarted at the current position (where PP was when the system was powered off), but if the type is set to SEMISTATIC, it will be restarted from the begin-ning each time the power is turned on. A SEMISTATIC task will also int the restart sequence reload modules specified in the system parameters if the module file is newer that the loaded module.It is also possible to set the task to type NORMAL, then it will behave in the same was as task 0 (the main task, controlling the robot movement). The teach pendent can only be used to start task 0, so the only way to start other NORMAL tasks is to use Com-municationWare.

The way to run the tasks as default is to run all tasks at the same level in a round rob-bin way (one basic step on each instance). But it is possible to change the priority of one task by putting the task in the background of another. Then the background will only execute when the foreground is waiting for some events, or has stopped the exe-cution (idle). A robot program with move instructions will be in an idle state most of the time.

The example below describes some situations where the system has 10 tasks 

 The tasks can have different priorities.

TrustLevel handel the system behavior when a SEMISTATIC or STATIC task is stopped for some reason or not executable.

SysFail - This is the default behaivour, all other NORMAL tasks (eg the MAIN task) will also stop, and the system is set to state SYS_FAIL. All jogg and program start orders will be rejected. Only a new warm start reset the system. This should be used when the task has some security supervisions. 

SysHalt - All NORMAL tasks will be stopped (normaly only the main task). The sys-tem is forced to "motors off". When taking up the system to "motors on" it is possible to jogg the robot, but a new attempt to start the program will be rejected. A new warm start will reset the system.

SysStop - All NORMAL tasks will be stopped (eg the main task), but it is restartable.

Jogging is also possible.

NoSafety - Only the actual task itself will stop.

The system will supply a memory area with an installation depending on size. That area is shared by all tasks.

The value of a persistent variable will be stored in a separate part of the system, and no affect the memory area above. 

Something to think about

When you specify task priorities, you must think about the following:

- Always use the interrupt mechanism or loops with delays in supervision tasks. Otherwise the teach pendent will never get any time to interact with the user. 

-And if the supervision task is in foreground, it will never allow another task in background to execute.

1. Define the new task under system parameters (controller/task)

Set the type to NORMAL and the TrustLevel to NoSafety.

2. Specify all modules that should be preloaded to this new task, also under system parameters (controller/task-modules).

3. Create the modules that should be in the task from the TeachPendant (in the MAIN task) or off-line.

4. Test and debug the modules in the MAIN task, until the functionallity is satified. Note: this could only be done in motors on state.

5. Change the task type to SEMISTATIC (or STATIC).

6. Restart the system.

In many cases an iteration with point 3 and 5 is enough. It’s only when the program has to be tested in the MAIN task and execution of the RAPID code in two task at the same time could confuse the user, all point should be used. Note: if a STATIC task is used it has to be forced to reload the new changed module and restarted from the beginning. If all point below is used it will take care of that for you.

1. Change the task type to NORMAL to inhibit the task. A NORMAL task will not start when the system restart and if it’s not the MAIN task not it will be affected by the start button at the teach pendant.

2. Restart the system.

3. Load the moulde(s) to the MAIN task, test, change and save the module(s).

Note: Don’t save the task, save each module according to the system parameters.

4. Change back the task type to SEMISTATIC (or STATIC).

5. Restart the system.

1. Set the TrustLevel to desired level eg SysFail

2. Restart the system