7 RAPID error recovery
7.3. Asynchronously raised errors
933HAC021272-001 Revision: H
© Copyright 2004-2008 ABB. All rights reserved.
7.3. Asynchronously raised errors
What is an asynchronously raised error
Asynchronously raised errors can be raised by another instruction than the instruction where
the program pointer is. This means that an asynchronous error can be raised while the robot
is in the middle of a path movement. For more information about asynchronously raised
errors, see Technical reference manual - RAPID kernel.
The technique with asynchronously raised errors allows a failing instruction in one task
program to raise an error in all other task programs with synchronized movements.
How to raise an asynchronous error
The instruction
ProcerrRecovery will raise the error ERR_PATH_STOP and stop the
movement for all task programs with synchronized movements.
Asynchronous errors can also be raised by process instructions (e.g.
ArcL). These can raise
one error code (describing the cause of the error) in the task program where the error
occurred, and raise the error
ERR_PATH_STOP in the other task programs with synchronized
movements.
The task programs without errors
If two task programs run synchronized move instructions and one of them raise an
asynchronous error, the movements will stop for both tasks. The task program where nothing
went wrong will then get the error
ERR_PATH_STOP. This error must be handled by an error
handler. The error handler can handle
ERR_PATH_STOP by just waiting for the other task to
solve its problems and then resume the movements.
By using the instruction
StartMoveRetry, the execution will continue when all tasks reach
this instruction.
Independent movements in the error handler
If the error handler in one task program needs to execute a move instruction, the
synchronization must be suspended first.
The synchronization is automatically suspended by the
StorePath instruction. All tasks
with synchronized movements must execute a
StorePath instruction before the
synchronization is turned off and the execution can continue.
The instruction
RestoPath will restore synchronization to the mode it had before
StorePath. All task programs with synchronized movements must execute the RestoPath
instruction in their error handlers before the synchronization is resumed and the execution can
continue.
Between the instructions
StorePath and RestoPath, the failing task program can move
independently to solve its problem. Since
RestoPath works as a synchronization point, the
other task programs will wait at this point until the problem has been resolved.
If the task program is not in synchronized movements mode,
StorePath and RestoPath
act just like they do in a single robot system. This means that the same error handler code can
handle errors that occur both in synchronized movements mode and unsynchronized mode.
StorePath and RestoPath require the option Path Recovery. For more information about
StorePath and RestoPath, see Application manual - Motion functions and events.