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