The following explanation relates to the VisionAutomaticModeStateMachine described in Section 8.3. Vendor-specific mode state machines may behave differently.

Note that preparing a recipe may be an operation of considerable complexity taking a significant amount of time. During that time the system may or may not be capable of reacting to a start method. Some recipes may exclude each other from being prepared at the same time, for example, when there are mechanical movements involved. Having two such recipes prepared at the same time would mean that an instantaneous reaction to a Start method call for a prepared recipe would not be possible. However, this is at the discretion of the vision system. The client may merely notice an unusually long reaction time between calling the Start method and the actual state change, or the vision system may prevent the simultaneous preparation by returning an error.

Independent from the system types mentioned in the previous section, (with the exception of the Preconfigured System, for obvious reasons) is the capability of preparing a recipe in the background. This refers to the situation where PrepareRecipe has been called, the method has returned, but the preparation of the recipe is not yet finished. A system may stay in state Ready and react correctly to the previously prepared recipe or a different prepared recipe.

The server is free to handle PrepareRecipe as a synchronous method, i.e., when it returns it is assumed that the recipe in question is completely prepared and the IsCompleted output variable must be set to TRUE unless an error occurred.

Since recipe management is outside the scope of this specification and solely the province of the vision system itself, the server is entitled to any reaction that fits the internal recipe handling of the vision system. That means that calling the AddRecipe or PrepareRecipe methods in Ready state may result in

• the system falling back into state Initialized, then returning automatically to state Ready, or (in the case of AddRecipe) waiting for PrepareRecipe. What recipe is then prepared is system-dependent; the client can use the GetRecipeListFiltered method with an appropriate filter to determine that.
• the system staying in Ready state but returning an error when the client tries to call a Start method on the recipe

Thus, vision systems may behave in different ways, depending on their recipe management capabilities, and therefore exhibit different transitions for calls to the AddRecipe and PrepareRecipe methods. These variations are difficult to depict graphically; therefore, the state machine diagram shows those transition causes assumed to be typical.

It follows that the client cannot assume to be able to trigger a particular transition by calling one of these methods. Without a priori knowledge about the behavior of the vision system/server combination, the only way for the client to actually force a return to the Initialized state is by going through Preoperational state via a reset. It must be prepared however that the vision system may fall back to Initialized state upon any call to AddRecipe or PrepareRecipe methods, even depending on the recipe itself (e.g. when it requires to initialize or check for additional hardware for a particular recipe).

The client therefore should not actually be interested in the transition, but only in two questions:

• Is the system Ready?
• Is the recipe/product to be started already prepared?