Note that the capabilities of systems with respect to recipe management may be very different. In the following typical system setups are described without any claim to completeness. Note also that the behavior described is only one of several possibilities.

  • Preconfigured system: a system that is configured outside the scope of this specification, starts automatically through states Preoperational and Initialized into Ready. It will immediately react to Start method, ignoring a possible recipe or product argument.
  • Single recipe system: a system that can hold a single recipe; it may start through Preoperational into Initialized, then wait for a call to the AddRecipe method and immediately prepare this recipe and transition into Ready. It can immediately react to a Start method call, ignoring a possible recipe or product argument (or it will throw an error if this is not the current recipe/product).
  • Single program system: a system that can hold several recipes but can have only a single prepared or active recipe; it starts through Preoperational into Initialized, then waits for one or more AddRecipe method calls, staying in Initialized. Upon a call to the PrepareRecipe method it will transition into Ready. It will immediately react to a Start method call with the appropriate recipe or product argument, but throw an error if this is not the prepared recipe/product.
  • Multi program system: a system that can hold several recipes active; it behaves like a single program system until Ready. It will then allow for several additional recipes to be prepared (state handling is discussed later). For each of the prepared recipes, it will react to a Start method call immediately if the recipe or product is prepared and throw an error for a not-prepared recipe or product.

Note that all transitions are under the provision that no error occurs.

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?

There are two possibilities to handle the situation of a preconfigured system not having any recipe management capabilities:

  • Set the Executable flags of the methods permanently to false.
  • Omit the methods completely.

It is recommended to use the second method as this makes the capabilities of the system much clearer to a (generic) client. Therefore, recipe management methods are optional in this specification.

A client should nevertheless always check the executability of a recipe management method before calling it since, depending on the state of the vision system, any of these methods may not be executable under certain circumstances.