11 System States and Conditions for the Vision System ToC Previous Next

11.5 Interaction between Messages, State Machine, and Vision System ToC Previous Next

There is only a loose connection between the generation of messages and the exposed behavior of the vision system on the state machine level. The following mandatory behavior is defined:

As the OPC UA interface only offers a view to the underlying vision system each call of the defined methods may fail. The method may deliver some information on the cause of the fail, but this information is only visible for the client calling the method. If any other clients are interested in this kind of information there is no way for them to get it. Therefore we define that if a method call fails the vision system has to generate a message at least of the warning without acknowledgement type naming the failed method including the calling parameters.

As the definition of the vision system is out of the scope of this document this is also true for the detection of error states within the vision system. As a consequence of this the generation of messages signaling such conditions is not associated to a specific state of the state machine.

As a general rule the transition to the error state of the state machine should only be performed if this is inevitable for the operation. The creation of an error message does not require that the state machine transitions to the Error state. A problem may be detected in a part of the vision system that is not needed for the current task at hand. Only if in this situation a method is called that can’t be performed because of this problem a transition to the Error state should occur.

On the other hand if the state machine does a transition to the Error state it is mandatory that a message of the error type or higher severity describing the cause is generated or already active.

It is up to the vision system to define if an internal error condition can be resolved immediately or if it has to wait for external acknowledgement / confirmation before trying to do so. Even if the system is successful in clearing the condition internally it has to wait for the reception of the acknowledgement of the corresponding message object if this is of an acknowledgeable type, before the message is cleared.

Application Note:

As the reception of an acknowledgement / confirmation can only take place once for each message object on the interface the vision system after reception has to check if the error condition is / can be resolved. If it is unable to resolve the error and interaction of the client / user side is required for resolving, it has to clear the message and create a new one to start a new resolving cycle.

Example:

During normal operation a vision system detects that it cannot accept a new job because the camera lens is dirty. It generates an error message informing the client on this with Ack and Conf required.

The client acknowledges the message and shows a message box on its console asking the operator to clean the lens.

The Operator presses the confirmation button without reading the message.

The client sends the confirmation for the message.

After reception of confirmation the vision System takes a test image and detects that the lens is still dirty. As there is still the need for user interaction the vision system has to decide what to do.

If it does nothing the client still sees the confirmed error message and therefore knows that it was not resolved. But as there are no additional confirmation options for the client the vision system will never get informed that if it may continue.

Therefore the vision system clears the confirmed message and creates a new one to start a new cleaning request with a hopefully better result.

The generation of large amounts of diagnostic messages may have impact on the performance of the vision system. As an OPC UA client can decide on its own if he reads such messages this is only a problem on the server side. It is common practice that the generation of such debugging / diagnostic messages can be suppressed within the vision System software. The server shall expose the information on suppressing of such messages in the following way. An integer variable DiagnosticLevel with a valid range between 1 … 200 is published showing that all diagnostic messages with a severity level lower or equal to this value are suppressed. Optionally this variable may be defined to be client writable to set a desired diagnostic level externally. For values lower than 150 it is not mandatory that the vision System is capable of upholding the performance expected for the application. The initial value of this variable on system start should be 200.

Application Note:

Example of a failing method call

Let’s assume the vision system is in the Ready state with an activated recipe in its memory. A client can call the PrepareRecipe method to load a second recipe but with a wrong recipe name that is not present in the vision system.

The method call will fail with an error message informing the calling client that this is a unknown recipe.

The vision system issues a warning message with a severity of e.g. 503 containing the information that a call of the PrepareRecipe method for that Recipe name failed.

The vision system does not transit to the Error state as there is no need to do so, since normal operation is not compromised at the moment. The vision system is able to accept jobs using the already activated recipe.

If the client now calls the StartSingleJob method with the unknown recipe the vision system could consider this an error and transition to the Error state while issuing a message of the error class. This decision is application specific. It is also valid that it only lets the method call fail and issues a warning message without transition to the Error state.

An external recipe management system could receive such a warning message and push the missing recipe to the vision system using the AddRecipe method.

Previous Next