8 ObjectTypes for Vision System State Handling ToC Previous Next

8.2 VisionStateMachineType ToC Previous Next

8.2.2 Operation of the VisionStateMachineType ToC Previous Next

8.2.2.1 Basic operation ToC

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.

8.2.2.2 Resetting the system ToC

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.

8.2.2.3 Halting the system ToC

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.

8.2.2.4 Error handling ToC

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.

Previous Next