11.4 EventTypes for Informational Elements

11.4.1 VisionEventType

11.4.1.1 Overview

VisionEvents are generated to signal noteworthy events during the operation of the vision system which do not require interaction.

All non-inherited properties are optional and stay optional on the concrete sub-types because these EventTypes will be used under very different operational circumstances in the vision system; it is therefore not possible to specify that, e.g. a jobId shall be mandatory, since an event may be triggered during the preparation of a recipe, when no job is running.

However, the intention is for the server to provide as much information to the client as possible, i.e. fill as many properties as possible.

The EventType for VisionEvents is formally defined in Table 129.

11.4.1.2 Usage of inherited properties

The following properties are inherited from BaseEventType and shall be used in VisionEventType in the manner described here.

SourceNode

Reference to the source of the Message. This could be a failing method or, in case of an internally triggered message, the state machine object itself.

SourceName

Name of the Message source.

Severity

Severity of the Information within the boundaries defined by Table 128.

Message

A textual description of the error as a string.

11.4.1.3 Usage of additional properties

The following describes the usage of the properties added by VisionEventType with respect to BaseEventType.

CausePath

Path information string based on the E10 scheme described in 11.6 or an application specific expanded derivation of that.

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.

11.4.2 VisionDiagnosticInfoEventType

VisionDiagnosticInfoEvents are generated to signal events of the lowest severity class as described in Section 11.3.2.

The EventType for VisionDiagnosticInfoEvents is formally defined in Table 130.

11.4.3 VisionInformationEventType

VisionInformationEvents are generated to signal events of low severity class as described in Section 11.3.3.

The EventType for VisionInformationEvents is formally defined in Table 131.

11.4.4 VisionConditionType

11.4.4.1 Overview

VisionConditions are generated to signal important events during the operation of the vision system which require interaction, i.e. conditions.

All non-inherited properties are optional and stay optional on the concrete sub-types because these ConditionTypes will be used under very different operational circumstances in the vision system; it is therefore not possible to specify that, e.g. a jobId shall be mandatory, since an error condition may be triggered during the preparation of a recipe, when no job is running.

However, the intention is for the server to provide as much information to the client as possible, i.e. fill as many properties as possible.

The EventType for VisionConditions is formally defined in Table 132.

11.4.4.2 Usage of properties in common with VisionEventType

The properties which VisionConditionType has in common with VisionEventType have the same semantics and usage as described in Sections 11.4.1.2 and 11.4.1.3..

11.4.4.3 Usage of additional properties

The following describes the usage of the properties added by VisionConditionType with respect to AcknowledgeableConditionType.

ErrorString

A system specific string classifying the error / warning.

ErrorCode

A system specific numeric code classifying the error / warning.

StopReaction

If the system did stop normal operation because of this error (state machine did transit to error state) this property shall be set to true.

BlockReaction

If the system did stop normal operation and user interaction is needed because of this error this property shall be set to true.

11.4.5 VisionWarningConditionType

The VisionWarningConditionType is used to represent conditions in the vision system which the client should be warned about as described in Section 11.3.4.

The server can use the AckedState and ConfirmedState variables of the AcknowledgeableConditionType to control whether the vision system requires acknowledgement and confirmation of the condition as described in OPC 10000-9.

The VisionWarningConditionType is formally defined in Table 133.

11.4.6 VisionErrorConditionType

The VisionErrorConditionType is used to represent error conditions in the vision system as described in Section 11.3.5.

The server can use the AckedState and ConfirmedState variables of the AcknowledgeableConditionType to control whether the vision system requires acknowledgement and confirmation of the condition as described in OPC 10000-9.

The VisionErrorConditionType is formally defined in Table 134.

11.4.7 VisionPersistentErrorConditionType

The VisionPersistentErrorConditionType is used to represent error conditions in the vision system requiring outside interaction as described in Section 11.3.6.

The server can use the AckedState and ConfirmedState variables of the AcknowledgeableConditionType to control whether the vision system requires acknowledgement and confirmation of the condition as described in OPC 10000-9.

The VisionPersistentErrorConditionType is formally defined in Table 135.

11.4.8 VisionSafetyEventType

VisionSafetyEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when a safety-related incident occurs in the vision system. The structure is defined in Figure 45. It is formally defined in Table 136.

Event properties

VisionSafetyTrigger: flag indicating the current internal safety state

VisionSafetyInformation: information about the internal safety state provided by the vision system