VisionAutomaticModeStateMachineType is an ObjectType subtype of FiniteStateMachineType and represents the behavior of a vision system in automatic operation.

The conceptual idea is that of a vision system installed on a production line for inline inspection or process control. This is taken in a very broad sense to cover other situations easily, like sample test stations where a human operator starts the inspection jobs or robot-mounted systems for position guidance. Thus, the state machine reflects the goal of specifying a system to be easily integrated into automated production and inspection systems.

The Operational state of the VisionStateMachineType has a mandatory SubStateMachine of the VisionAutomaticModeStateMachineType, indicating that this mode of operation shall always be present in a vision system conforming to this specification.

This SubStateMachine is typically entered by a transition from state Preoperational to its internal state Initialized, either an automatic transition or caused by the SelectModeAutomatic method

It can also be entered by automatic transitions from state Error to any of its internal states. These transitions exist to allow the vision system to try after resolving an error to resume operation with the “highest possible state”. That means, when the error occurs in SingleExecution state, the vision system will try to resume and finish this operation. Failing that, it will try to return to Ready state for the next Start method; failing that, it will return to state Initialized to be made Ready again. Note however, that the method of resolving an error and resuming operation after the Error state is defined by the vision system, not this specification.

In the following state diagram, method-triggered transitions are again black with the method written as UML trigger; automatic transitions are orange with a possible event as UML effect introduced with a “/”.

To clarify the entire context, the other main states are also shown in Figure 24. For clarity, transitions from the top-level VisionStateMachine into states of the VisionAutomaticModeStateMachine are not shown in the diagram.

image031.png

Figure 24 – States and transitions of the VisionAutomaticModeStateMachineType

Interactions between external systems and the global “AutomaticMode” state machine are limited to few transitions in the model which we will see in detail in the description of methods and transitions. The most prominent points are obviously the Start-methods, typically used by a client to start operation of a vision system.

However, there is frequently a need to synchronize operations between the vision systems and external systems where the vision system remains conceptually in one of the states of the “AutomaticMode” state machine. The most obvious example is that of taking images of a part from various positions, either by moving the part relative to a camera system, handling it with a robot arm, or by moving the camera relative to the part, again possibly by a robot manipulator. This entire interaction would conceptually take place within SingleExecution state or ContinuousExecution state.

To enable all states in the “AutomaticMode” state machine to carry out such interactions, each is marked as a complex state by the image032.png symbol, and has an optional SubStateMachine of the VisionStepModelStateMachineType.

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 8.1.2.1 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.

image033.png

Figure 25 – Entering the VisionAutomaticModeStateMachine SubStateMachine

image034.png

Figure 26 – Overview VisionAutomaticModeStateMachineType

VisionAutomaticModeStateMachineType is formally defined in Table 96.

Table 96 – VisionAutomaticModeStateMachineType definition

Attribute

Value

Includes all attributes specified for the FiniteStateMachineType

BrowseName

VisionAutomaticModeStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the FiniteStateMachineType defined in OPC 10000-5 Annex B.4.5

HasComponent

Object

Initialized

--

StateType

HasComponent

Object

Ready

--

StateType

HasComponent

Object

SingleExecution

--

StateType

HasComponent

Object

ContinuousExecution

--

StateType

HasComponent

Object

InitializedToReadyRecipe

--

TransitionType

HasComponent

Object

InitializedToReadyProduct

--

TransitionType

HasComponent

Object

InitializedToReadyAuto

--

TransitionType

HasComponent

Object

ReadyToInitializedRecipe

--

TransitionType

HasComponent

Object

ReadyToInitializedProduct

--

TransitionType

HasComponent

Object

ReadyToInitializedAuto

--

TransitionType

HasComponent

Object

ReadyToSingleExecution

--

TransitionType

HasComponent

Object

ReadyToSingleExecutionAuto

--

TransitionType

HasComponent

Object

ReadyToContinuousExecution

--

TransitionType

HasComponent

Object

ReadyToContinuousExecutionAuto

--

TransitionType

HasComponent

Object

SingleExecutionToReadyStop

--

TransitionType

HasComponent

Object

SingleExecutionToReadyAbort

--

TransitionType

HasComponent

Object

SingleExecutionToReadyAuto

--

TransitionType

HasComponent

Object

ContinuousExecutionToReadyStop

--

TransitionType

HasComponent

Object

ContinuousExecutionToReadyAbort

--

TransitionType

HasComponent

Object

ContinuousExecutionToReadyAuto

--

TransitionType

HasComponent

Method

Stop

--

Mandatory

HasComponent

Method

Abort

--

Mandatory

HasComponent

Method

StartSingleJob

--

Mandatory

HasComponent

Method

StartContinuous

--

Mandatory

HasComponent

Method

SimulationMode

--

Optional

HasComponent

Object

InitializedStepModel

--

VisionStepModelStateMachineType

Optional

HasComponent

Object

ReadyStepModel

--

VisionStepModelStateMachineType

Optional

HasComponent

Object

SingleExecutionStepModel

--

VisionStepModelStateMachineType

Optional

HasComponent

Object

ContinuousExecutionStepModel

--

VisionStepModelStateMachineType

Optional

Table 97 specifies the VisionAutomaticStateMachine’s state Objects. These state Objects are instances of the StateType defined in OPC 10000-5 – Annex B. Each state is assigned a unique StateNumber value.

See Table 98 for a brief description of the states. The states will be detailed in the following subsections.

Table 97 – VisionAutomaticModeStateMachineType States

Browse

Name

References

Target BrowseName

Value

Target Type

Definition

Notes

Initialized

HasProperty

StateNumber

5

PropertyType

--

FromTransition

ReadyToInitializedRecipe

TransitionType

--

FromTransition

ReadyToInitializedProduct

TransitionType

--

FromTransition

ReadyToInitialzedAuto

TransitionType

--

ToTransition

InitializedToReadyRecipe

TransitionType

--

ToTransition

InitializedToReadyProduct

TransitionType

--

ToTransition

InitializedToReadyAuto

TransitionType

--

HasSubstateMachine

InitializedStepModel

VisionStepModelStateMachineType

--

Ready

HasProperty

StateNumber

6

PropertyType

--

FromTransition

InitializedToReadyRecipe

TransitionType

--

FromTransition

InitializedToReadyProduct

TransitionType

--

FromTransition

InitlializedToReadyAuto

TransitionType

--

FromTransition

SingleExecutionToReadyStop

TransitionType

--

FromTransition

SingleExecutionToReadyAbort

TransitionType

--

FromTransition

SingleExecutionToReadyAuto

TransitionType

--

FromTransition

ContinuousExecutionToReadyStop

TransitionType

--

FromTransition

ContinousExecutionToReadyAbort

TransitionType

--

FromTransition

ContinousExecutionToReadyAuto

TransitionType

--

ToTransition

ReadyToInitializedRecipe

TransitionType

--

ToTransition

ReadyToInitializedProduct

TransitionType

--

ToTransition

ReadyToInitializedAuto

TransitionType

--

ToTransition

ReadyToSingleExecution

TransitionType

--

ToTransition

ReadyToSingleExecutionAuto

TransitionType

--

ToTransition

ReadyToContinuousExecution

TransitionType

--

ToTransition

ReadyToContinuousExecutionAuto

TransitionType

--

HasSubstateMachine

ReadyStepModel

VisionStepModelStateMachineType

--

SingleExecution

HasProperty

StateNumber

7

PropertyType

--

FromTransition

ReadyToSingleExecution

TransitionType

--

FromTransition

ReadyToSingleExecutionAuto

TransitionType

--

ToTransition

SingleExecutionToReadyStop

TransitionType

--

ToTransition

SingleExecutionToReadyAbort

TransitionType

--

ToTransition

SingleExecutionToReadyAuto

TransitionType

--

HasSubstateMachine

SingleExecutionStepModel

VisionStepModelStateMachineType

--

ContinuousExecution

HasProperty

StateNumber

8

PropertyType

--

FromTransition

ReadyToContinuousExecution

TransitionType

--

FromTransition

ReadyToContinuousExecutionAuto

TransitionType

--

ToTransition

ContinuousExecutionToReadyStop

TransitionType

--

ToTransition

ContinousExecutionToReadyAbort

TransitionType

--

ToTransition

ContinousExecutionToReadyAuto

TransitionType

--

HasSubstateMachine

ContinuousExecutionStepModel

VisionStepModelStateMachineType

--

Table 98 – VisionAutomaticModeStateMachineType State Descriptions

StateName

Description

Initialized

This state indicated that the vision system is sufficiently initialized so that management operations like configuration and recipe management can be carried out through the server, if the optional management objects exist.

Ready

This state indicates that the vision system is capable of being started to carry out jobs, e.g. through Start methods called on the server.

SingleExecution

This state indicates that the vision system will acquire the data required for carrying out a single inspection or measuring job and will finish whatever operations are necessary to return to the Ready state to accept the next job.

ContinuousExecution

This state indicates that the vision system continually acquires and processes data, until it is stopped by internal or external reasons, e.g. calling the Stop or Abort methods on the server.

In this state, the system is characterized by the following properties:

  • The system is able to perform management and operations.
  • Configurations can be managed by methods detailed in Section 7.2.
  • Recipes can be managed by methods detailed in Sections 7.5, 7.6, 7.7.
  • One or more recipes can be prepared by the PrepareRecipe method such that these are ready to be used in processing operations.
  • Results can be pulled from the internal result-store by the methods detailed in Section 7.10.
  • The system can be put into simulation mode (see Section 8.3.7.5).

This state will be the first state entered in the VisionAutomaticModeStateMachine when the superior VisionStateMachine enters the Operational state either by an automatic transition from Preoperational or by a SelectModeAutomatic method call.

If an error is dectected which suspends normal operation, the system will change to the Error state in the VisionStateMachine.

This state can be left in the following ways:

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

In this state, the system is characterized by the following properties:

  • The vision system has prepared one or more recipes such that they can be used for processing immediately upon a StartSingleJob or StartContinuous method call (unless it is a system without any recipe management).
  • The vision system is ready to accept either a StartSingleJob or a StartContinuous method to begin image processing operation.
  • Recipes can be added and retrieved by methods detailed in Sections 7.5, 7.6, 7.7.
  • Which recipes are ready for use can be changed by calling the PrepareRecipe method depending on the recipe handling capabilities of the system.
  • Results can be pulled from the internal result-store by the methods detailed in Section 7.5.
  • The vision system can be put into simulation mode (see Section 8.3.7.5).

Depending on the recipe handling capabilities of the vision system, calling an AddRecipe or PrepareRecipe method in this state may cause the system to fall back into Initialized state, temporarily preventing it from accepting Start methods.

If an error is dectected which suspends normal operation, the system will transition to Error state in the VisionStateMachine.

This state can be left in the following ways:

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

In this state, the system is characterized by the following properties:

  • The vision system has received a command to begin the execution of an individual job (measuring, inspection, identifying, …), e.g. by a call to the StartSingleJob method on the server.
  • The vision system collects sensor data (i.e. acquiring single or multiple images, possibly awaiting triggers, often in hardware).
  • If data acquisition is a “multi-stage-process” (interaction with other devices) this may be modelled with a VisionStepModelType SubStateMachine (all states allow for this, but this is the most typical application, therefore we emphasize it here).
  • The vision system may indicate to the client by an AcquisitionDone event that acquisition has been finished, e.g. as a signal that the part can be removed from the camera’s field of view, either by moving the part or he camera.
  • The vision system carries out the processing of the acquired data at least so far that the internal resources are available to transition into state Ready to accept the next start command.
  • Results can be pulled from the internal result-store by the methods detailed in Section 7.5 (depending on the capabilities of the system).

Note that the above description illustrates a typical behavior. The vision system is, however, in no way obliged to perform any particular operation – like image acquisition or processing – in this state. It can do completely different things or nothing at all before returning to Ready state. The point is rather that the difference between SingleExecution state and Ready state lies in the availability of the required resources for starting a job.

If an error is detected which suspends normal operation, the system will change to state Error in the VisionStateMachine.

This state can be left in the following ways:

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

In this state, the system is characterized by the following properties:

  • The vision system has received a StartContinuous command to begin the execution of a continuous job
  • The vision system collects sensor data (i.e. acquiring single or multiple images, possibly awaiting triggers, often in hardware) and processes this in a continuously ongoing fashion.
  • Results can be pulled from the internal result-store by the methods detailed in Section 7.5 (depending on the capabilities of the system).

Note that the above description illustrates a typical behavior. The vision system is, however, in no way obliged to perform any particular operation – like image acquisition or processing – in this state. It can do completely different things or nothing at all before returning to Ready state. The point is rather that the difference between ContinuousExecution state and Ready state lies in the availability of the required resources for starting a job.

If an error is detected which suspends normal operation, the system will change to the Error state in the VisionStateMachine.

This state can be left in the following ways:

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

Transitions are instances of Objects of the TransitionType defined in OPC 10000-5 – Annex B which also includes the definitions of the ToState, FromState, HasCause, and HasEffect References used. Table 99 specifies the Transitions defined for the VisionStateMachineType. Each Transition is assigned a unique TransitionNumber.

Table 99 – VisionAutomaticModeStateMachineType transitions

BrowseName

References

Target BrowseName

Value

Target TypeDefinition

Notes

InitializedToReadyRecipe

HasProperty

TransitionNumber

561

PropertyType

--

FromState

Initialized

StateType

--

ToState

Ready

StateType

--

HasCause

PrepareRecipe

Method

--

HasEffect

StateChangedEventType

--

HasEffect

RecipePreparedEventType

--

InitializedToReadyProduct

HasProperty

TransitionNumber

562

PropertyType

--

FromState

Initialized

StateType

--

ToState

Ready

StateType

--

HasCause

PrepareProduct

Method

--

HasEffect

StateChangedEventType

--

HasEffect

RecipePreparedEventType

--

InitializedToReadyAuto

HasProperty

TransitionNumber

560

PropertyType

--

FromState

Initialized

StateType

--

ToState

Ready

StateType

--

HasEffect

StateChangedEventType

--

ReadyToInitializedRecipe

HasProperty

TransitionNumber

651

PropertyType

--

FromState

Ready

StateType

--

ToState

Initialized

StateType

--

HasCause

UnprepareRecipe

Method

--

HasEffect

StateChangedEventType

--

ReadyToInitializedProduct

HasProperty

TransitionNumber

652

PropertyType

--

FromState

Ready

StateType

--

ToState

Initialized

StateType

--

HasCause

UnprepareProduct

Method

--

HasEffect

StateChangedEventType

--

ReadyToInitializedAuto

HasProperty

TransitionNumber

650

PropertyType

--

FromState

Ready

StateType

--

ToState

Initialized

StateType

--

HasEffect

StateChangedEventType

--

ReadyToSingleExecution

HasProperty

TransitionNumber

671

PropertyType

--

FromState

Ready

StateType

--

ToState

SingleExecution

StateType

--

HasCause

StartSingleJob

Method

--

HasEffect

StateChangedEventType

--

HasEffect

JobStartedEventType

--

ReadyToSingleExecutionAuto

HasProperty

TransitionNumber

670

PropertyType

--

FromState

Ready

StateType

--

ToState

SingleExecution

StateType

--

HasEffect

StateChangedEventType

--

HasEffect

JobStartedEventType

--

ReadyToContinuousExecution

HasProperty

TransitionNumber

681

PropertyType

--

FromState

Ready

StateType

--

ToState

ContinuousExecution

StateType

--

HasCause

StartContinuous

Method

--

HasEffect

StateChangedEventType

--

HasEffect

JobStartedEventType

--

ReadyToContinuousExecutionAuto

HasProperty

TransitionNumber

680

PropertyType

--

FromState

Ready

StateType

--

ToState

ContinuousExecution

StateType

--

HasEffect

StateChangedEventType

--

HasEffect

JobStartedEventType

--

SingleExecutionToReadyAuto

HasProperty

TransitionNumber

760

PropertyType

--

FromState

SingleExecution

StateType

--

ToState

Ready

StateType

--

HasEffect

StateChangedEventType

--

HasEffect

ReadyEventType

--

SingleExecutionToReadyStop

HasProperty

TransitionNumber

761

PropertyType

FromState

SingleExecution

StateType

--

ToState

Ready

StateType

--

HasCause

Stop

Method

--

HasEffect

StateChangedEventType

--

HasEffect

ReadyEventType

--

SingleExecutionToReadyAbort

HasProperty

TransitionNumber

762

PropertyType

--

FromState

SingleExecution

StateType

--

ToState

Ready

StateType

--

HasCause

Abort

Method

--

HasEffect

StateChangedEventType

--

HasEffect

ReadyEventType

--

ContinuousExecutionToReadyAuto

HasProperty

TransitionNumber

860

PropertyType

--

FromState

ContinuousExecution

StateType

--

ToState

Ready

StateType

--

HasEffect

StateChangedEventType

--

HasEffect

ReadyEventType

--

ContinuousExecutionToReadyStop

HasProperty

TransitionNumber

861

PropertyType

--

FromState

ContinuousExecution

StateType

--

ToState

Ready

StateType

--

HasCause

Stop

Method

--

HasEffect

StateChangedEventType

--

HasEffect

ReadyEventType

--

ContinuousExecutionToReadyAbort

HasProperty

TransitionNumber

862

PropertyType

--

FromState

ContinuousExecution

StateType

--

ToState

Ready

StateType

--

HasCause

Abort

Method

--

HasEffect

StateChangedEventType

--

HasEffect

ReadyEventType

--

Calling this method on the server is used to start a single execution type job in the vision system which will be reflected by transition from the Ready state to the SingleExecution state.

Signature

StartSingleJob ([in]MeasIdDataTypemeasId,[in]PartIdDataTypepartId,[in]RecipeIdExternalDataTyperecipeId[in]ProductIdDataTypeproductId[in]BaseDataType[]parameters[out]JobIdDataTypejobId[out]Int32error);

Table 100 – StartSingleJob Method Arguments

Argument

Description

measId

Identifies the measuring or inspection run from the point of view of the client. May be empty.

partId

Identifies the part to be measured or inspected from the point of view of the client. The partId may be identical on different measIDs, e.g. for repeat measurements in capability tests. May be empty.

recipeId

If not empty, it must be the ExternalId of a prepared recipe which is to be used by this job.

productId

It not empty, it must be the ProductId of a product for which a recipe has been prepared which is to be used by this job.

parameters

List of parameters for this particular execution of the recipe; number and type of the parameters are recipe-specific, so the client may need to re-browse the method signature after a change in recipe preparation.

jobId

A system-wide unique identification of the job. This argument must be returned.

error

0 – OK

Values > 0 are reserved for errors defined by this and future standards.

Values < 0 shall be used for application-specific errors.

Table 101 – StartSingleJob Method AddressSpace Definition

Attribute

Value

BrowseName

StartSingleJob

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

It is expected that clients work either recipe-based or product-based, i.e. that a client gives either the RecipeId argument or the ProductId argument. Recipe and product management being the province of the vision system, it is implementation defined how the vision system reacts to none or both be given

Typical possibilities are that a system without recipe management or with only a single prepared recipe can use this recipe to execute a job and accept both parameters to be empty, whereas a system with multiple prepared recipes would probably consider it an error if both are empty and decide based on internal rules which takes precedence if both are given.

Results are to be marked with as many of the identification values as possible to allow for unique identification and flexible filtering, i.e., it is expected that the server uses all meta data elements provided by the client and supported by the server profile to mark the results, filter the results, and fill the ResultReady event.

The jobId is mandatory to be returned and to be included in results.

Restarting with the same measId can lead to identical or different jobIds, depending on the application. It is therefore not reliably possible to use multiple calls with the same measId to query for jobIds.

The parameters argument is intended for filling free parameters of a recipe with concrete values for the given job. Its structure is therefore dependent on the recipe used. The server will have to instantiate this method with an application-specific parameter structure before entering the Ready state. The server may re-instantiate this method with a different parameter structure after preparing a different recipe. In the case of several recipes being in prepared state at the same time, this structure is expected to be the superset of parameters required by the prepared recipes. The client will have to browse for the actual argument structure of the method at least once before calling a Start method (in the case of a system without recipe management) and application-specific potentially after each call to PrepareRecipe.

Calling this method on the server is used to start a continuous execution type job in the vision system which will be reflected by transition from the Ready state to the ContinuousExecution state. It has the same signature and semantics as method StartSingleJob described in Section 8.3.7.1.

Table 102 – StartContinuous Method AddressSpace Definition

Attribute

Value

BrowseName

StartContinuous

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

In response to an Abort call on the server, the vision system is expected to end running operation and transition to the Ready state as fast as possible, without regard to acquired or computed data.

See the general remarks on Stop and Abort methods in Section 8.3.2.4 for further information on the behavior.

Signature

Abort ([in]Int32cause[in]StringcauseDescription[out]Int32error);

Table 103 – Abort Method Arguments

Argument

Description

cause

Implementation-specific number denoting the reason for the Abort command.

causeDescription

Text for said reason, e.g. for logging purposes. May be empty.

error

0 – OK

Values > 0 are reserved for errors defined by this and future standards.

Values < 0 shall be used for application-specific errors.

Table 104 – Abort Method AddressSpace Definition

Attribute

Value

BrowseName

Abort

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

The cause argument given to the method can only be interpreted by the underlying vision system It can be used, for example, for logging purposes. It is expected that a value of 0 will be considered an “unspecified reason”.

In response to a Stop method call on the server, the vision system is expected to end running operation and transition to state Ready as soon as possible while retaining as much result data as possible.

See the general remarks on Stop and Abort in 8.3.2.4 for further information on the behavior.

Signature

Stop ([in]Int32cause[in]StringcauseDescription[out]Int32error);

Table 105 – Stop Method Arguments

Argument

Description

cause

Implementation-specific number denoting the reason for the Stop command.

causeDescription

Text for said reason, e.g. for logging purposes. May be empty.

error

0 – OK

Values > 0 are reserved for errors defined by this and future standards.

Values < 0 shall be used for application-specific errors.

Table 106 – Stop Method AddressSpace Definition

Attribute

Value

BrowseName

Stop

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

The cause argument given to the method can only be interpreted by the underlying vision system It can be used, for example, for logging purposes. It is expected that a value of 0 will be considered an “unspecified reason”.

This method puts the system into a system-specific special mode of operation. It is expected that this mode does one or all of the following things:

  • Simulate hardware (for tests on notebook)
  • Produce simulated results (for tests within the line)
  • Simulate parts of a recipe

It is mandatory that each result produced by the system when simulation mode is on must be marked with a simulation flag.

Signature

SimulationMode ([in]Booleanactivate[in]Int32cause[in]StringcauseDescription[out]Int32error);

Table 107 – SimulationMode Method Arguments

Argument

Description

activate

Switch simulation on (true) or off (false)

cause

Implementation specific number which the server can use, e.g. to control the simulation in a specific way

causeDescription

String describing the reason for the call, for logging purposes May be empty.

error

0 – OK

Values > 0 are reserved for errors defined by this and future standards.

Values < 0 shall be used for application-specific errors.

Table 108 – SimulationMode Method AddressSpace Definition

Attribute

Value

BrowseName

SimulationMode

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

RecipePreparedEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event shall be triggered by the server when the preparation of a recipe is completed on the vision system. Figure 27 defines the structure. It is formally defined in Table 109.

Typically, if the RecipeManagementType object is carried out by the server in a synchronous manner, this event will be triggered before the method returns, but there is no specified temporal relationship between the call to the PrepareRecipe method and the triggering of the event (except for the obvious that the event cannot occur before the call).

The same holds for the PrepareProduct method of the RecipeManagementType object which, in effect, also prepares a recipe.

An important special case, described in Section B.1.2.3, is local editing of an already prepared recipe. Since after local editing has finished, the recipe is a different one than before, effectively a new recipe has been prepared. Therefore, local editing of a prepared recipe shall generate a RecipePrepared event.

The RecipePrepared event transports the identification of the prepared recipe. If the event was caused by a PrepareProduct method call, it also transports the ProductId, otherwise the ProductId shall be empty.

image035.png

Figure 27 – Overview RecipePreparedEventType

Table 109 – Definition of RecipePreparedEventType

Attribute

Value

BrowseName

RecipePreparedEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasProperty

Variable

ExternalId

RecipeIdExternalDataType

PropertyType

Optional

HasProperty

Variable

InternalId

RecipeIdInternalDataType

PropertyType

Mandatory

HasProperty

Variable

ProductId

ProductIdDataType

PropertyType

Optional

JobStartedEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when the state machine transitions from the Ready state to the SingleExecution or ContinuousExecution state. Figure 28 defines the structure. It is formally defined in Table 110.

It indicates to the client that the vision system has started the execution of a job, regardless whether the transition occurred due to a call to the StartSingleJob or StartContinuous method or automatically due, e.g. for a fieldbus start signal.

The event transports the jobId created upon the transition from state Ready to state SingleExecution or ContinuousExecution. This enables clients to maintain a time-sequential log of jobs, regardless whether this particular client started the job or whether the job was started by an OPC UA method call at all.

In the case of multiple running state machines in the same server, the client can use the Source property inherited from BaseEventType to identify the state machine instance the event originated from.

image036.png

Figure 28 – Overview JobStartedEventType

Table 110 – Definition of JobStartedEventType

Attribute

Value

BrowseName

JobStartedEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasProperty

Variable

JobId

JobIdDataType

PropertyType

Mandatory

ReadyEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when the state machine transitions to the Ready state from one of the “Execution” states, i.e. SingleExecution or ContinuousExecution. Figure 29 defines the structure. It is formally defined in Table 111.

It indicates to the client that the vision system has the necessary resources available for executing the next job. The client still has to make sure that the state machine is actually in the Ready state before calling the StartSingleJob or StartContinuous method as the vision system may fall out of the Ready state due to internal reasons or other method calls

The event transports the jobId created upon the transition from state Ready to state SingleExecution or ContinuousExecution. Together with the JobStarted event this enables clients to maintain a time-sequential log of state changes for each job.

In the case of multiple running state machines in the same server, the client can use the Source property inherited from BaseEventType to identify the state machine instance the event originated from.

image037.png

Figure 29 – Overview ReadyEventType

Table 111 – Definition of ReadyEventType

Attribute

Value

BrowseName

ReadyEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasProperty

Variable

JobId

JobIdDataType

PropertyType

Mandatory

ResultReadyEvent is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when the vision system has a complete or partial result available for the client. Figure 30 defines the structure. It is formally defined in Table 112.

To enable access to a result, several properties of the result, which are generated by the system, are supplied. These properties can be used to query the results in the ResultManagement object. A sufficiently small result can also be provided in the ResultContent component of the event.

The ResultReadyEvent is not shown explicitly in the state machine as it is not connected to a state transition.

image038.png

Figure 30 – Overview ResultReadyEventType

Table 112 – Definition of ResultReadyEventType

Attribute

Value

BrowseName

ResultReadyEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasProperty

Variable

IsPartial

Boolean

PropertyType

Mandatory

HasProperty

Variable

IsSimulated

Boolean

PropertyType

Optional

HasProperty

Variable

ResultState

ResultStateDataType

PropertyType

Mandatory

HasProperty

Variable

MeasId

MeasIdDataType

PropertyType

Optional

HasProperty

Variable

PartId

PartIdDataType

PropertyType

Optional

HasProperty

Variable

ExternalRecipeId

RecipeIdExternalDataType

PropertyType

Optional

HasProperty

Variable

InternalRecipeId

RecipeIdInternalDataType

PropertyType

Mandatory

HasProperty

Variable

ProductId

ProductIdDataType

PropertyType

Optional

HasProperty

Variable

ExternalConfigurationId

ConfigurationIdDataType

PropertyType

Optional

HasProperty

Variable

InternalConfigurationId

ConfigurationIdDataType

PropertyType

Mandatory

HasProperty

Variable

JobId

JobIdDataType

PropertyType

Mandatory

HasProperty

Variable

ResultId

ResultIdDataType

PropertyType

Mandatory

HasProperty

Variable

CreationTime

UtcTime

PropertyType

Mandatory

HasProperty

Variable

ProcessingTimes

ProcessingTimesDataType

PropertyType

Optional

HasProperty

Variable

ResultContent

BaseDataType[]

PropertyType

Optional

IsPartial

Indicates whether the result is the partial result of a total result.

IsSimulated

Indicates whether the system was in simulation mode when the job generating this result was created.

ResultState

Indicates at what processing state this result was generated.

MeasId, PartId, ExternalRecipeId, InternalRecipeId, ProductId, ExternalConfigurationId, InternalConfigurationId, JobId, ResultId

If the information is somehow linked to one of the (vision system) objects referenced by these Ids, these properties can transport this reference. In particular:

MeasId: This identifier is given by the client when starting a single or continuous execution and transmitted to the vision system. It is used to identify the respective result data generated for this job. Although the system-wide unique JobId would be sufficient to identify the job which the result belongs to, this makes for easier filtering on the part of the client without keeping track of JobIds.

PartId: A PartId is given by the client when starting the job; although the system-wide unique JobId would be sufficient to identify the job which the result belongs to, this makes for easier filtering on the part of the client without keeping track of JobIds.

ExternalRecipeId:

External Id of the recipe in use which produced the result. The ExternalId is only managed by the environment. This will typically be derived from the arguments of the Start method call which caused the result to be created.

InternalRecipeId:

Internal Id of the recipe in use which produced the result. This Id is system-wide unique and it is assigned by the vision system. This will typically be derived from the arguments of the Start method call which caused the result to be created.

ProductId: Id of the product selected to produce the result. This will typically be derived from the arguments of the Start method call which caused the result to be created.

ExternalConfigurationId: External Id of the configuration in effect in the system when the result was produced.

InternalConfigurationId: Internal Id of the configuration in effect in the system when the result was produced.

JobId:

The Id of the job, created by the transition from state Ready to state SingleExecution or to state ContinuousExecution which produced the result.

ResultId: vision-system-wide unique Id, which is assigned by the system. This Id can be used for fetching exactly this result using the methods detailed in Section 7.10.2.

CreationTime

CreationTime indicates the time when the result was created.

ProcessingTimes

Collection of different processing times that were needed to create the result.

ResultContent

Abstract data type to be subtyped from to hold result data created by the selected recipe.

AcquisitionDoneEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server. when the vision system finishes a data acquisition process for a job. Figure 31 shows the structure of the event. It is formally defined in Table 113.

It is not shown explicitly in the state machine diagram as it is not directly connected to a transition.

It indicates to the client that data acquisition for the specified job has finished. In many machines, this will be a signal that the work piece or camera can be moved. Triggering this event during a single or continuous execution is application-specific and not mandatory.

The event provides the JobId created upon the transition from the Ready state to the SingleExecution or ContinuousExecution state. This enables the client to maintain a time-sequential log of state changes for each job and also to match the event to the corresponding start signal.

In the case of multiple running state machines in the same server, the client can use the Source property inherited from BaseEventType to identify the state machine instance the event originated from.

image039.png

Figure 31 – Overview AcquisitionDoneEventType

Table 113 – Definition of AcquisitionDoneEventType

Attribute

Value

BrowseName

AcquisitionDoneEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasProperty

Variable

JobId

JobIdDataType

PropertyType

Mandatory

JobId

The Id of the job for which the event was triggered. The JobId is created by the transition from state Ready to state Acquiring.

If a vendor wants to add a mode of operation, the following steps are required:

  1. Define a SubType of FiniteStateMachineType describing the behavior of this operation mode, designated here as VendorModeStateMachineType. This SubType shall not have an InitialState to allow for selective activation of operation modes.
  2. Define a SubType of VisionStateMachineType which
  3. binds an instance of VendorModeStateMachineType as SubStateMachine to the Operational state of this SubType.
  4. defines a SelectModeVendor method to trigger a transition into a desired starting state of this SubStateMachine.
  5. binds the SelectModeVendor method as additional HasCause to the method-triggered transition from the Preoperational state to the Operational state, i.e., T141 in Table 84 (according to OPC 10000-5 B.4.18, adding causes to a transition is allowed, not however to introduce a new transition, so the existing transition ).
  6. contains direct transitions from the Preoperational state into the desired starting state of the VendorModeStateMachine, typically an automatic one and one triggered by SelectModeVendor (again this is allowed by OPC 10000-5, B.4.18).
  7. Take care that automatic transitions into the Operational state lead into states of the VendorModeStateMachine in a suitable way, especially for transitions from the Error state to facilitate the error handling described in Section 8.2.2.4.

The designation elements ModeStateMachineType and SelectMode shall be used as shown above. The Vendor part of the designations can be freely chosen.