This ObjectType is a subtype of FiniteStateMachineType and represents the top-level behavior of the vision system. It is formally defined in Table 81.
The Operational state has a mandatory SubStateMachine for the “Automatic” mode of operation and may have additional SubStateMachines for other modes of operation.
The other state may have optional SubStateMachines of the VisionStepModelStateMachineType.
For clarity, transitions into states of SubStateMachines are not shown in the diagram.
Figure 22 – States and transitions of the VisionStateMachineType
After power-up the system goes into a Preoperational state. It is assumed that the vision system loads a configuration which is present on the system and marked as active. From there, it can be put into Operational state either automatically, due to internal initialization processes or by a SelectMode method call. The VisionStateMachineType provides one mandatory method, SelectModeAutomatic for transition into the “Automatic” mode SubStateMachine described in Section 8.3. Subtypes of VisionStateMachineType may offer additional SubStateMachines and thus additional SelectMode method calls.
The system stays in Operational mode, doing its job, until it is either resetted, halted or an error occurs which suspends normal operation until resolved.
At any time, it may be necessary or desired to revert the vision system into its initial state after power-up, i.e., state Preoperational.
The vision system may decide this due to internal conditions, or by calling the Reset method on the VisionStateMachine in the OPC UA server.
The Reset method shall always be executable. If for some reason the vision system is not capable of carrying out this transition, the behavior is undefined. The underlying assumption is that, if the vision system cannot perform a reset, it cannot be assumed that it is capable of carrying out any other controlled transition, including a transition into the Error state.
Application Note:
There are basically two reasons for a reset in the state model of this specification.
Either the vision system is idle – reflected by, e.g. the Ready or Initialized state – and the intent of calling the Reset method is to return to Preoperational state in order to call a different SelectMode method to change the mode of operation. In that case, carrying out the transition should not be a problem.
The other situation is as an emergency measure because the vision system does no longer operate correctly. In that case, the method may fail with an internal error code like Bad_UnexpectedError or Bad_InvalidState, but since the vision system is in an incorrect internal state, it is uncertain that it can reach any other state, like Error.
The client can assume that Preoperational or Error states should be reached within a reasonable – application-specific – time-frame. If that is not the case, the client can conclude that intervention is necessary and issue an appropriate message and operator call.
A vision system will frequently make use of a number of resources, like camera drivers, files, databases etc. which will need to be properly closed before shutting down that system.
In Halted state, the system shall have put all resources into a state where it is safe to power down the system. However, not all operation is stopped, because the system can be brought out of Halted state by a call to the Reset method, transitioning to the Preoperational state.
The vision system may decide to enter Halted state due to internal conditions or by calling the Halt method on the OPC UA server.
The Halt method shall always be executable. If for some reason the system is not capable of carrying out the transition, the VisionStateMachine shall transition into the Error state.
In every state of the VisionStateMachine or any of its SubStateMachines, an error may occur.
The system may also decide to enter state Error by means of an automatic operation if it cannot – or should not – continue its normal operation in the presence of an error. Note that the presence of an error condition does not necessarily cause the system to enter the Error state, it may be capable to continue normal operation in the presence of a signaled error condition. However, it the system does enter the Error state, it is mandatory that it indicates this by activating an error condition.
An error shall be signaled by an appropriate error condition. An arbitrary number of error conditions can be active at any time.
Error conditions are exposed as subtypes of the ConditionType defined in OPC 10000-9 and may have Acknowledge and Confirm methods and the appropriate state handling. It is expected that the calling of these methods has an effect upon the underlying system and/or that the underlying vision system monitors the state of the conditions and uses these in its internal decision making process whether to stay in the Error state or in which state to transition next.
It is assumed that the Acknowledge method will typically be called by a client automatically, indicated that the message has at least been received. The Confirm method will typically be caused by a human interaction, confirming that the cause of the error is remedied.
For convenience, the VisionStateMachine may offer the ConfirmAll method which shall confirm all conditions currently active. The effect on the internal decision making shall be the same as when the methods would have been called individually from the outside.
Thus, in Error state, the system decides either on its own or based on external input, like an acknowledgement or confirmation of the error, and other (non OPC UA) input signals, which state to transition to next.
Upon entering the Error state, an event of type ErrorEventType is triggered, upon leaving to some other state, an ErrorResolved event is triggered, if the error is actually resolved, in addition to the mandatory StateChanged events. Thus, a control system may listen only to the Error and ErrorResolved events monitoring the vision system.
The Error state can be left in the following ways:
- By a call to the Halt or Reset method, transitioning to states Halted and Preoperational respectively. The condition(s) causing the Error state do not necessarily have to be resolved for this transition. Only if they are resolved, an ErrorResolvedEvent shall be triggered.
- By an internal decision of the system to transition into the Halted or Preoperational states. As these states do not constitute normal productive operation of the system, the condition(s) causing the Error state do not necessarily have to be resolved for this transition. Only if they are resolved, an ErrorResolved event shall be triggered. Subsequent action, e.g. a call to ActivateConfiguration in these states may lead to the error being resolved and the system being capable of resuming normal productive operation.
- By an internal decision of the system to transition into the Operational state. As this state constitutes normal productive operation, this transition is only allowed if the condition(s) leading to the Error state are actually resolved. Therefore, an ErrorResolved event shall be triggered in this case.
In the last case, the automatic transition into the Operational state due to the resolving of the error condition(s), the system will actually go into one of the states of the SubStateMachines of the Operational state, using the 3rd method for entering a SubStateMachine described in Section 8.1.2.1 by a server-specific decision about the state.
Thus, the vision system can decide, based on its internal conditions, in which actual state it will continue operation. It may decide that it can immediately continue a job interrupted by the error and return to the SingleExecution or ContinuousExecution states; it may decide that it can immediately take on the next job and return to the Ready state; it may decide that it needs a re-initialization of a recipe and return to the Initialized state. It may even decide that it can resume a synchronization with an external system and return to any state within a VisionStepModelStateMachine inside one of these states.
Figure 23 – Overview VisionStateMachineType
One underlying idea of this specification is that a vision system may have different modes of operation with very different sets of states, methods and transitions.
Due to the high degree of individuality of vision system requirements and solutions, it does not appear possible to standardize each and every mode of operation of such systems. Therefore, vision systems according to this specification are free to implement additional state machines for such use cases.
However, this specification considers some states as universal for machine vision systems according to this specification and thus outside of these modes of operation, namely states related to powering up and shutting down the system and to error handling.
The system will in any case need to power up and enter some state automatically without outside intervention. From this state, a selection – either by method call or automatically based on internal and external circumstances – of the actual mode of operation can be made.
Conversely, the same holds for shutting down the system. Independent from the mode of operation, the system will need a way to enter a state from which it can safely be powered down.
And finally it will be of great advantage to all clients if the handling of errors is identical in all modes of operation.
Therefore, these states are mandatory in this specification as well as one state encompassing the actual operation of the system. Modes of operation shall be specified as SubStateMachines to this operational state.
VisionStateMachineType is formally defined in Table 81.
Table 81 – VisionStateMachineType Address Space Definition
|
Attribute |
Value |
||||
|
|
Includes all attributes specified for the FiniteStateMachineType |
||||
|
BrowseName |
VisionStateMachineType |
||||
|
IsAbstract |
False |
||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
Subtype of the FiniteStateMachineType defined in OPC 10000-5 Annex B.4.5 |
|||||
|
HasComponent |
Object |
Preoperational |
-- |
StateType |
|
|
HasComponent |
Object |
Halted |
-- |
StateType |
|
|
HasComponent |
Object |
Error |
-- |
StateType |
|
|
HasComponent |
Object |
Operational |
-- |
StateType |
|
|
HasComponent |
Object |
PreoperationalToHalted |
-- |
TransitionType |
|
|
HasComponent |
Object |
PreoperationalToHaltedAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
PreoperationalToErrorAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
PreoperationalToOperational |
-- |
TransitionType |
|
|
HasComponent |
Object |
PreoperationalToOperationalAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
PreoperationalToInitialized |
-- |
TransitionType |
|
|
HasComponent |
Object |
PreoperationalToInitializedAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
HaltedToPreoperational |
-- |
TransitionType |
|
|
HasComponent |
Object |
HaltedToPreoperationalAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
ErrorToPreoperational |
-- |
TransitionType |
|
|
HasComponent |
Object |
ErrorToPreoperationalAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
ErrorToHalted |
-- |
TransitionType |
|
|
HasComponent |
Object |
ErrorToHaltedAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
ErrorToOperationalAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
OperationalToPreoperational |
-- |
TransitionType |
|
|
HasComponent |
Object |
OperationalToPreoperationalAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
OperationalToHalted |
-- |
TransitionType |
|
|
HasComponent |
Object |
OperationalToHaltedAuto |
-- |
TransitionType |
|
|
HasComponent |
Object |
OperationalToErrorAuto |
-- |
TransitionType |
|
|
HasComponent |
Method |
Reset |
-- |
-- |
Mandatory |
|
HasComponent |
Method |
Halt |
-- |
-- |
Mandatory |
|
HasComponent |
Method |
SelectModeAutomatic |
-- |
-- |
Optional |
|
HasComponent |
Method |
ConfirmAll |
-- |
-- |
Optional |
|
HasComponent |
Object |
PreoperationalStepModel |
-- |
VisionStepModelStateMachineType |
Optional |
|
HasComponent |
Object |
HaltedStepModel |
-- |
VisionStepModelStateMachineType |
Optional |
|
HasComponent |
Object |
ErrorStepModel |
-- |
VisionStepModelStateMachineType |
Optional |
|
HasComponent |
Object |
AutomaticModeStateMachine |
-- |
VisionAutomaticModeStateMachineType |
Optional |
Table 82 specifies the VisionStateMachine’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. Subtypes of the VisionStateMachineType can add References from any state to a subordinate or nested StateMachine Object to extend the FiniteStateMachine. See Table 83 for a brief description of the states.
Table 82 – VisionStateMachineType States
|
BrowseName |
References |
Target BrowseName |
Value |
Target TypeDefinition |
Notes |
|
Preoperational |
HasProperty |
StateNumber |
1 |
PropertyType |
-- |
|
|
FromTransition |
HaltedToPreoperational |
|
TransitionType |
-- |
|
|
FromTransition |
HaltedToPreoperationalAuto |
|
TransitionType |
-- |
|
|
FromTransition |
ErrorToPreoperationalAuto |
|
TransitionType |
-- |
|
|
FromTransition |
ErrorToPreoperational |
|
TransitionType |
-- |
|
|
FromTransition |
OperationalToPreoperational |
|
TransitionType |
-- |
|
|
FromTransition |
OperationalToPreoperationalAuto |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToHalted |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToHaltedAuto |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToErrorAuto |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToOperational |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToOperationalAuto |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToInitialized |
|
TransitionType |
-- |
|
|
ToTransition |
PreoperationalToInitializedAuto |
|
TransitionType |
-- |
|
|
HasSubStateMachine |
PreoperationalStepModel |
|
VisionStepModelStateMachineType |
-- |
|
Halted |
HasProperty |
StateNumber |
2 |
PropertyType |
-- |
|
|
FromTransition |
PreoperationalToHalted |
|
TransitionType |
-- |
|
|
FromTransition |
PreoperationalToHaltedAuto |
|
TransitionType |
-- |
|
|
FromTransition |
ErrorToHalted |
|
TransitionType |
-- |
|
|
FromTransition |
ErrorToHaltedAuto |
|
TransitionType |
-- |
|
|
FromTransition |
OperationalToHalted |
|
TransitionType |
-- |
|
|
FromTransition |
OperationalToHaltedAuto |
|
TransitionType |
-- |
|
|
ToTransition |
HaltedToPreoperational |
|
TransitionType |
-- |
|
|
ToTransition |
HaltedToPreoperationalAuto |
|
TransitionType |
-- |
|
|
HasSubStateMachine |
HaltedStepModel |
|
VisionStepModelStateMachineType |
-- |
|
Error |
HasProperty |
StateNumber |
3 |
PropertyType |
-- |
|
|
FromTransition |
PreoperationalToErrorAuto |
|
TransitionType |
-- |
|
|
FromTransition |
OperationalToErrorAuto |
|
TransitionType |
-- |
|
|
ToTransition |
ErrorToPreoperational |
|
TransitionType |
-- |
|
|
ToTransition |
ErrorToPreoperationalAuto |
|
TransitionType |
-- |
|
|
ToTransition |
ErrorToHalted |
|
TransitionType |
-- |
|
|
ToTransition |
ErrorToHaltedAuto |
|
TransitionType |
-- |
|
|
ToTransition |
ErrorToOperationalAuto |
|
TransitionType |
-- |
|
|
HasSubStateMachine |
ErrorStepModel |
|
VisionStepModelStateMachineType |
-- |
|
Operational |
HasProperty |
StateNumber |
4 |
PropertyType |
-- |
|
|
FromTransition |
PreoperationalToOperational |
|
TransitionType |
-- |
|
|
FromTransition |
PreoperationalToOperationalAuto |
|
TransitionType |
-- |
|
|
FromTransition |
ErrorToOperationalAuto |
|
TransitionType |
-- |
|
|
ToTransition |
OperationalToPreoperational |
|
TransitionType |
-- |
|
|
ToTransition |
OperationalToPreoperationalAuto |
|
TransitionType |
-- |
|
|
ToTransition |
OperationalToHalted |
|
TransitionType |
-- |
|
|
ToTransition |
OperationalToHaltedAuto |
|
TransitionType |
-- |
|
|
ToTransition |
OperationalToErrorAuto |
|
TransitionType |
-- |
|
|
HasSubStateMachine |
AutomaticModeStateMachine |
|
VisionAutomaticModeStateMachineType |
-- |
The brief state descriptions in Table 83 will be detailed in the following subsections.
Table 83 – VisionStateMachineType State Descriptions
|
StateName |
Description |
|
Preoperational |
This is the initial state of the system after power-up and the state after a Reset method call. From here the system has to be brought into Operational state by selecting a mode of operation. Alternatively it can be halted. |
|
Halted |
This state is intended as the final state in the operation of the system. All resources shall be in a state allowing for safe power-down. However, the system can be put back into operation by a Reset method call, going through the Preoperational state. |
|
Error |
This state intended for the indication and resolution of errors preventing normal operation of the system. |
|
Operational |
This is the state for normal operation of the system. It is always a composite state with the SubStateMachine modelling the current mode of operation. This specification describes only a single mode of operation, the “Automatic” mode, described in 8.3. Vendors can add other modes of operation by sub-typing VisionStateMachineType and adding other SubStateMachines for these modes of operation. See Section 8.3.9 for implementation remarks. |
In this state, the system is characterized by the following properties:
- System is powered on, this is the initial state after power on
- No recipes are loaded
- No mode of operation is selected
- No error is detected
This state shall be entered automatically upon startup.
If an error is detected, the system shall transit to the Error state.
This state can be entered from any state, either by an automatic transition or caused by calling the Reset method.
From this state, all other states on this level can be reached, either by an automatic transition or by calling the Halt method for the Halted state or the SelectModeAutomatic method for sub-state Initialized of the Automatic mode SubStateMachine of state Operational. (see 8.3 for the description of the Automatic mode SubStateMachine and see 8.3.9 for implementation remarks on state machines derived from VisionStateMachineType for other modes of operation) or other SelectMode methods for other, vendor-specific, sub state machines of the Operational state.
This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.
In this state, the system is characterized by the following properties:
- The system has stopped all operations
- The system can safely be powered down (e.g. all files are closed; all resources are released, …)
- The OPC UA server shall still be running to allow for a transition to state Preoperational.
This state can be reached from any other state either by an automatic transition or by calling the Halt method. Calling the Halt method in this state will not have an effect.
From this state, only Preoperational state can be reached, either by an automatic transition or by calling the Reset method.
This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.
In this state, the system is characterized by the following properties:
- An error has occurred which disrupts normal operation.
- The system issues messages (in the form of Conditions) informing clients about the error; it awaits acknowledgement of these messages, i.e., the information that some client has received the message, and optionally confirmation, i.e., the information that some corrective action has been taken, typically by human intervention.
- The system tries to resolve the error by internal means taking into account the (mandatory) acknowledgement and (optional) confirmation of the messages issued.
This state can be entered from any other state by an automatic transition due to an error detected by the system.
This state can be left by an automatic transition based on the result of the error resolution into any other state, or into Preoperational state by a Reset method call or into Halted state by a Halt method call, provided the requirements on Acknowledgement and Confirmation have been fulfilled. For details on signaling error conditions and on error resolution behavior see Section 11.4.6.
This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.
State Operational is a composite state with a mandatory VisionAutomaticModeStateMachineType SubStateMachine.
In this state, the system is characterized by the following properties:
- The system has been initialized so far that the normal operation intended for the given mode of operation can be carried out as well as various system management functions.
- The system has not detected an error preventing it from carrying out this operation (by transitioning into state Error).
- The system is in any of the states of the VisionAutomaticModeStateMachineType, carrying out its normal operation, or in a state of another state machine added by the vendor as an additional SubStateMachine of state Operational.
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 84 specifies the Transitions defined for the VisionStateMachineType. Each Transition is assigned a unique TransitionNumber.
Table 84 – VisionStateMachineType Transitions
|
BrowseName |
References |
Target BrowseName |
Value |
Target TypeDefinition |
Notes |
|
PreoperationalToHalted |
HasProperty |
TransitionNumber |
121 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
Halted |
|
StateType |
-- |
|
|
HasCause |
Halt |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
PreoperationalToHaltedAuto |
HasProperty |
TransitionNumber |
120 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
Halted |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
PreoperationalToErrorAuto |
HasProperty |
TransitionNumber |
130 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
Error |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
|
HasEffect |
ErrorEventType |
|
|
-- |
|
PreoperationalToOperational |
HasProperty |
TransitionNumber |
141 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
Operational |
|
StateType |
-- |
|
|
HasCause |
SelectModeAutomatic |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
PreoperationalToOperationalAuto |
HasProperty |
TransitionNumber |
140 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
Operational |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
PreoperationalToInitialized |
HasProperty |
TransitionNumber |
151 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
AutomaticModeStateMachine.Initialized |
|
StateType |
-- |
|
|
HasCause |
SelectModeAutomatic |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
PreoperationalToInitializedAuto |
HasProperty |
TransitionNumber |
150 |
PropertyType |
-- |
|
|
FromState |
Preoperational |
|
StateType |
-- |
|
|
ToState |
AutomaticModeStateMachine.Initialized |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
HaltedToPreoperational |
HasProperty |
TransitionNumber |
211 |
PropertyType |
-- |
|
|
FromState |
Halted |
|
StateType |
-- |
|
|
ToState |
Preoperational |
|
StateType |
-- |
|
|
HasCause |
Reset |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
HaltedToPreoperationalAuto |
HasProperty |
TransitionNumber |
210 |
PropertyType |
-- |
|
|
FromState |
Halted |
|
StateType |
-- |
|
|
ToState |
Preoperational |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
ErrorToPreoperational |
HasProperty |
TransitionNumber |
311 |
PropertyType |
-- |
|
|
FromState |
Error |
|
StateType |
-- |
|
|
ToState |
Preoperational |
|
StateType |
-- |
|
|
HasCause |
Reset |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
ErrorToPreoperationalAuto |
HasProperty |
TransitionNumber |
310 |
PropertyType |
-- |
|
|
FromState |
Error |
|
StateType |
-- |
|
|
ToState |
Preoperational |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
|
|
ErrorToHalted |
HasProperty |
TransitionNumber |
321 |
PropertyType |
-- |
|
|
FromState |
Error |
|
StateType |
-- |
|
|
ToState |
Halted |
|
StateType |
-- |
|
|
HasCause |
Halt |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
ErrorToHaltedAuto |
HasProperty |
TransitionNumber |
320 |
PropertyType |
-- |
|
|
FromState |
Error |
|
StateType |
-- |
|
|
ToState |
Halted |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
ErrorToOperationalAuto |
HasProperty |
TransitionNumber |
340 |
PropertyType |
-- |
|
|
FromState |
Error |
|
StateType |
-- |
|
|
ToState |
Operational |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
|
HasEffect |
ErrorResolvedEventType |
|
|
-- |
|
OperationalToPreoperational |
HasProperty |
TransitionNumber |
411 |
PropertyType |
-- |
|
|
FromState |
Operational |
|
StateType |
-- |
|
|
ToState |
Preoperational |
|
StateType |
-- |
|
|
HasCause |
Reset |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
OperationalToPreoperationalAuto |
HasProperty |
TransitionNumber |
410 |
PropertyType |
-- |
|
|
FromState |
Operational |
|
StateType |
-- |
|
|
ToState |
Preoperational |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
OperationalToHalted |
HasProperty |
TransitionNumber |
421 |
PropertyType |
-- |
|
|
FromState |
Operational |
|
StateType |
-- |
|
|
ToState |
Halted |
|
StateType |
-- |
|
|
HasCause |
Halt |
|
Method |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
OperationalToHaltedAuto |
HasProperty |
TransitionNumber |
420 |
PropertyType |
-- |
|
|
FromState |
Operational |
|
StateType |
-- |
|
|
ToState |
Halted |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
|
OperationalToErrorAuto |
HasProperty |
TransitionNumber |
430 |
PropertyType |
-- |
|
|
FromState |
Operational |
|
StateType |
-- |
|
|
ToState |
Error |
|
StateType |
-- |
|
|
HasEffect |
StateChangedEventType |
|
|
-- |
This method commands the system to go into the Halted state from where it is safe to power down the system without damage to system resources (like files, data bases, etc.); what the system does during this transition and how long it takes, is application-defined and may depend on the parameter given to the Halt method (e.g. to distinguish between a fast shutdown due to power-loss or a more gentle shutdown completing ongoing evaluations).
Signature
Halt ([in]Int32cause[in]StringcauseDescription[out]Int32error);
Table 85 – Halt Method Arguments
|
Argument |
Description |
|
cause |
Implementation-specific number denoting the reason for the Halt method call. |
|
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 86 – Halt Method AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
Halt |
||||
|
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 commands the system to return to the Preoperational state where it has not parameterization for carrying out jobs (single or continuous), e.g. to reset the state of recipes; what the system does during this transition and how long it takes, is application-defined and may depend on the parameter given to the Reset method (e.g. to distinguish between a fast emergency reset due to an error or safety condition or a more gentle reset completing ongoing evaluations).
Signature
Reset ([in]Int32cause[in]StringcauseDescription[out]Int32error);
Table 87 – Reset Method Arguments
|
Argument |
Description |
|
cause |
Implementation-specific number denoting the reason for the Reset method call. |
|
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 88 – Reset Method AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
Reset |
||||
|
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 commands the system to enter the mandatory AutomaticModeStateMachine attached to Operational state, or, more precisely, the Initialized state of that SubStateMachine.
Signature
SelectModeAutomatic ([out]Int32error);
Table 89 – SelectModeAutomatic Method Arguments
|
Argument |
Description |
|
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 90 – SelectModeAutomatic Method AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
SelectModeAutomatic |
||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
HasProperty |
Variable |
OutputArguments |
Argument[] |
PropertyType |
Mandatory |
With this method, a client can confirm all currently active conditions of the server derived from VisionConditionType. In analogy to the Confirm method of the AcknowledgeableConditionType it expects a LocalizedText as a comment, not, however an EventId as this would not make sense for multiple events.
Signature
ConfirmAll ([in]LocalizedTextcomment);
Table 91 – ConfirmAll Method Arguments
|
Argument |
Description |
|
Comment |
A localized text to be applied to the conditions. |
Table 92 – ConfirmAll Method AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
ConfirmAll |
||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
HasProperty |
Variable |
InputArguments |
Argument[] |
PropertyType |
Mandatory |
StateChangedEventType is an EventType subtype of TransitionEventType, defined in OPC 10000-5. This event shall be triggered by the server whenever the system enters a new state.It is formally defined in Table 93. The event transports the NodeId of the state entered as well as the transition which is leading into that state.
Table 93 – StateChangedEventType AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
StateChangedEventType |
||||
|
IsAbstract |
False |
||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
Subtype of the TransitionEventType defined in OPC 10000-5 |
|||||
Refer to the TransitionEventType in OPC 10000-5 for the behavior and the transported information.
ErrorEventType is an EventType subtype of TransitionEventType, defined in OPC 10000-5. This event must be triggered when the vision system decides that the current conditions require it to suspend normal operation and enter state Error. Additional detail about the circumstances leading to the Error state shall be indicated by active ConditionType events. For more detail see Section 11.
It is formally defined in Table 94.
Table 94 – ErrorEventType AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
ErrorEventType |
||||
|
IsAbstract |
False |
||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
Subtype of the TransitionEventType defined in OPC 10000-5 |
|||||
ErrorResolvedEventType is an EventType subtype of TransitionEventType, defined in OPC 10000-5. This event must be triggered when the vision system decides that the current conditions do not require state Error to be maintained and initiates the transition into whatever state it deemed appropriate under the circumstances.
It is formally defined in Table 95.
Table 95 – ErrorResolvedEventType AddressSpace Definition
|
Attribute |
Value |
||||
|
BrowseName |
ErrorResolvedEventType |
||||
|
IsAbstract |
False |
||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
Subtype of the TransitionEventType defined in OPC 10000-5 |
|||||