The following examples demonstrate how sequences and their monitors are able to handle various scenarios.
The situation below shows a monitor firing during the runtime of a sequence.
As soon as a monitor checking for a certain condition fires, an exception sequence is called. The exception must always be blocking. However, it would be possible to omit it altogether. After this the control goes back to the original sequence. How does this sequence now continue? Every monitor can be assigned one of the following properties:
The following table shows the behavior for various situations
|Property||behavior of sequence after monitor fires||exception sequence if present|
|resume||sequence continues normally||exception sequence will run for each further step|
|abort||remaining steps aborted||exception sequence will run once|
|restart||remaining steps aborted, sequence restarts with first step||exception sequence will run once, after restarting will run again if monitor fires again|
A sequence can be checked by more than one monitor where each monitor checks for a certain condition to be met. While a first monitor could check for a timeout condition a second could supervise whether a payload of a robot didn't get lost.
Please note, that each monitor can have a different effect on its associated sequence. While one monitor can cause the sequence to abort further steps another can restart the sequence upon firing an exception. Further, one of the monitor can cause an exception sequence to run while another does not do so.
Exception sequences are used to handle situations where regular sequences do not work due to certain conditions. Besides this, an exception sequence is a normal sequences with exactly the same features and has to be defined in the same way. Therefore, an exception sequence has the same built-in conditions and monitors as a regular sequence (timeout and abort conditions).