8 ObjectTypes for Vision System State Handling ToC Previous Next

8.3 VisionAutomaticModeStateMachineType ToC Previous Next

8.3.7 VisionAutomaticModeStateMachineType Methods ToC Previous Next

8.3.7.1 StartSingleJob method ToC

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]	MeasIdDataType	measId,[in]	PartIdDataType	partId,[in]	RecipeIdExternalDataType	recipeId[in]	ProductIdDataType	productId[in]	BaseDataType[]	parameters[out]	JobIdDataType	jobId[out]	Int32	error);

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.

8.3.7.2 StartContinuous method ToC

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

8.3.7.3 Abort method ToC

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]	Int32	cause[in]	String	causeDescription[out]	Int32	error);

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

8.3.7.4 Stop method ToC

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]	Int32	cause[in]	String	causeDescription[out]	Int32	error);

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

8.3.7.5 SimulationMode method ToC

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]	Boolean	activate[in]	Int32	cause[in]	String	causeDescription[out]	Int32	error);

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

Previous Next