Vision systems frequently require interaction with external systems during image acquisition. For example, it may be required to capture images in several different positions, i.e., moving the part between image capturing operations. In that case, the vision system will signal to the PLC when it has captured an image, so that the part may be safely moved, and the PLC will in turn signal to the vision system when the part is in the next position to capture the next image.
To enable the states of the VisionAutomaticModeStateMachineType to do such interaction, each is a complex state with an optional SubStateMachine of the VisionStepModelStateMachineType.
Figure 32 shows the entire SubStateMachine diagram.
Figure 32 – States and transitions of the VisionStepModelStateMachineType
It is supposed that a SubStateMachine is entered automatically if it is present in the superior state. Since the Entry state is of InitialStateType it will be entered automatically.
Upon entering the SubStateMachine there is a check in the Entry state whether there is a step-sequence to execute. This is application-dependent and may depend on the situation (e.g. on the currently active recipe) and the way of determining this is application-specific.
If in the Entry state the system decides that there is a step sequence to be executed, the SubStateMachine informs the client about this by firing an EnterStepSequence event. It then enters the Wait state to wait for a synchronization event.
The synchronization can occur by a Sync method call from an OPC UA client, typically the control system. The synchronization can also occur internally, typically due to communication events on other interfaces, e.g. a digital trigger.
The system then enters the Step state, where it does the actual work required in this state of the step model and decides whether there are any steps left in the step sequence. This is application-specific, as is the original decision to execute a step sequence at all.
The system indicates the need for another step-sequence cycle by firing a NextStep event and re-enters the Wait state. In this manner, an arbitrary and dynamic number of steps can be executed. It is not necessary to predefine the number of steps.
To use the common example of image acquisition: There may be one image acquisition in each Step state, but it is also possible that the step sequence is used only for mechanical synchronization and all acquisition is done in the Exit state.
If no step-sequence is to be executed at all, the system will transition into the Exit state directly from the Entry state and perform the actual task of the superior state. After the task is finished, the superior state will transition to whatever is its target state, thus de-activating the SubStateMachine.
When a step sequence is being executed and the system decides in the Step state that there are no more steps to execute in the step sequence, it fires a LeaveStepSequence event, transitions to the Exit state and proceeds as in the case without a step sequence.
How the work of the superior state and of the steps of the sequence is distributed between the states of the step model is application-specific.
The superior state of a currently active VisionStepModelStateMachine is some state in the VisionStateMachineType or the VisionAutomaticModeStateMachineType.
Each of these states can be left due to internal causes (like error conditions) or external causes (like the Stop, Abort, Halt, Reset method calls). In that case, the SubStateMachine becomes inactive and will be in state Bad_StateNotActive, as explained in Section 8.1.2.
How and when these transitions take place is at the discretion of the vision system underlying the OPC UA server. In particular, the vision system can disable the Executable flag on each of these methods when the current operation does not allow for, e.g. an Abort command to be carried out.