The AutomaticMode state machine is entered from state Preoperational of the VisionStateMachineType either by an automatic operation or by the SelectModeAutomatic method.

A call to SelectModeAutomatic causes transition to state Initialized. Alternatively, the system can automatically transition into Initialized.

It is expected that within the states Initialized and Ready, the system can carry out management operations, with recipes and configurations. In order to carry out automatic evaluations, at least one recipe needs to be prepared in the system.

Recipe management is very system- and application-specific and correspondingly hard to generalize. Therefore, systems may exhibit different state transition behavior caused by recipe management methods, according to their capabilities. This is described in detail in Annex B.1 and the definition of the RecipeManagementType in chapter 7.5.

At some point, the system will be in Ready state. The simplest way will typically be a single call to AddRecipe and to PrepareRecipe to load and prepare a single recipe.

It is expected that in state Ready the system can at any time start an evaluation operation. This operation is denoted as a “job”. The “AutomaticMode” state machine defines two distinct methods of carrying out evaluation, namely “single job” operation and “continuous” operation.

Typical examples for SingleJob operation are the inspection of individual work pieces. Typical examples for Continuous operation are web inspection, package sorting, etc. The main differences between these two types of jobs are:

  • With a SingleJob, the client starting the job can reasonably expect it to end after an application-specific, but finite time; a Continuous job will typically not end on its own, so the notion of a timeout is meaningless.
  • Within a SingleJob, typically an AcquisitionDone event will be triggered at some point, informing the environment that all required data has been acquired so that the inspection part can leave the field of view of the camera, either by moving the part or the camera.

The image processing operation is accordingly started by one of two start methods, StartSingleJob or StartContinuous.

In single job as well as in continuous operation, the system can produce an arbitrary number of results, all of them partial with the exception of the last one. Whenever a partial or final result is available, the system shall trigger a ResultReady event with a result ID.

The result can then be retrieved by one of the GetResult method calls or directly from the ResultContent Component of the ResultReady event if it is included in the event Typically, the result will be available through a GetResult method call even if included with the ResultReady event, however the client cannot make assumptions about the result management of the vision system. This has to be treated in an application-specific way.

A call to the StartSingleJob method will cause a transition into state SingleExecution, where the system will typically acquire data and, once it has finished acquiring data, will fire an AcquisitionDone event. Note that there is no temporal relationship between the system returning to the Ready state and the completion of image acquisition or processing for the job triggered by a Start method. The system can already have left state SingleExecution to Ready, it can even accept another Start method call and carry out the next job, before the AcquisitionDone event for the previous job occurs, if the system is capable of handling several image acquisitions and/or image evaluations simultaneously.

From the point of view of the OPC UA client, the state machine is always carrying out one job only. However, there may be evaluation process of several jobs running in parallel on the system and may trigger AcquisitionDone events as well as ResultReady events.

Whenever the system is ready for the next StartSingleJob method, it will transition into the Ready state again.

A call to the StartContinuous method will cause a transition into state ContinuousExecution, where the system will continuously acquire and process data.

This state models the behavior of systems like textile inspection systeme, package sorting machines, monitoring and surveillance systems, which do not expect start commands for individual work pieces but constantly acquire and process data.

The system may go back to the Ready state, automatically due to internal conditions, or by calling the Abort or Stop methods.

The Stop and Abort methods offer two different means of finishing operation in the “Executing” states, with the intention that the system transitions to the Ready state.

Both can be considered intended interruptions of a running system, in contrast to an error or the complete stopping of operations by Reset and Halt methods.

The difference between the two methods is:

  • In response to an Abort method call, the system is expected to end running operation and transition to the Ready state as fast as possible, without regard to acquired or computed data.
  • In response to a Stop method call, the system is expected to end running operation and transition to the Ready state as soon as possible while retaining as much result data as possible. It is expected that results will become available for all images acquired before the Stop method was called.

These methods shall always be executable. If for some reason the vision system is not capable of carrying out this transition, the method shall fail with an appropriate status code, typically Bad_InternalError, and the state machine shall transition into the Error state.

For example, depending on the camera / sensor used, it may not be possible to interrupt the acquisition process arbitrarily from the outside.

As described in Section the VisionAutomaticMode SubStateMachine of the Operational state can be entered in two different ways:

Figure 25 shows these ways; for clarity, all other transitions have been left out. The transitions from the Preoperational state are shown as solid lines as they are actually modelled in the type definition. The transitions from the Error state are shown in dashed lines as they are not explicitly modelled but only “virtual” transitions decided by the server internally.


Figure 25 – Entering the VisionAutomaticModeStateMachine SubStateMachine