PackML Modes and States
Modes β What are they and how to use them.
The PackML standard allows for 32 possible modes. Within the Tc3_PackML_V2
library there is a Global Constant named MaxUnitMode
and declared as an integer with an Initial value of 31. There is also a structure named stPMLUnitModeConfiguration
declared as an Array [0..MaxUnitMode] of ST_PMLUnitModeConfiguration
. This means that we are limited to 32 total possible modes across the entire machine. stPMLUnitModeConfiguration
is initialized with values for the first four indexes of the array as defined by the PackML standard.
The ENUM E_PMLProtectedUnitMode
is defined within the Tc3_PackML_V2
library with 4 values:
1 2 3 4 |
|
stPMLUnitModeConfiguration
. Therefore, we have 28 possible custom modes that can be defined for a machine.
Each mode can be customized for which states are available, and from which states transitions are allowed between modes. The Protected Unit Modes are listed within the ENUM E_PMLProtectedUnitMode
and are defined by their initialization within stPMLUnitModeConfiguration
. These are just the initial values given and therefore they can be modified by the code. It is also important to understand that these modes are not required, they are simply a means by which to separate functionality within a subset of states that work together.
Creating Custom Modes
The remaining 28 indexes in the array (4 through 31) can be assigned to modes that are created by the programmer. The function block PML_UnitModeConfig
is provided by the Tc3_PackML_V2
library. The function block requires the enumeration value to be assigned (eMode), a string value for the name (sName), a True/False value for each state that will set the Disable of that state, and a True/False value for each state that will set the Enable for Mode change to or from that state. Only one instance of the PML_UnitModeConfig
function block is required as it can be called repeatedly with new information about each unique eMode value. Later we will cover how this function block is implemented within the FB_Machine.Initialize()
method of the SPT Framework.
Some other common modes are Clean in Place, Run Out, Semi-Auto, Dry Cycle, Homing, Post-Production, Pre-Heat, and Test. These modes are distinguishable by the differences in commands given within a subset of states. In other words, each mode provides a way to separate commands within the Execute state between Manual, Automatic, or any other mode.
Mode Transition States
By having a consistent state machine across all modes, we can transition between modes with some commonality. By default, the wait states are defined as the Mode transition states. For example, Idle or Stopped. It is these states where the machine is waiting on some external factor, such as operator input, before continuing to the next state.
At any time, it is possible to call the PML_UnitModeConfig
and modify the states which allow for mode change. When changing modes, both modes (from and to) must have the state enabled.
The available states are designed in a pattern that allows for a normal startup process to be followed by the desired machine execution and then a way to stop the machine. Additionally, it is also possible to manage unexpected conditions such as Estops and material end.
Generally, there are two types of states: Wait and Acting.
Waiting | Acting |
---|---|
Stopped | Clearing |
Idle | Starting |
Suspended | Execute |
Aborted | Stopping |
Held | Aborting |
Completed | Holding |
Unholding | |
Suspending | |
Unsuspending | |
Resetting | |
Completing |
Transitioning from a wait state requires a command to do so, this command can be from either an operator input, or from the logic of the machine. The acting states will complete their logic and then internally issue a StateComplete()
which will transition the state machine to the next state.
While the state machine has a normal/expected flow there are also 2 commands that can be issued at any time. The first one is the Abort command. When the Abort command is given the state machine will move from its current state to the Abort state. This is typically used for an E-Stop or other abnormal conditions. The Stop command can be issued at any time (excluding while in Abort) and the state machine will switch to the Stopping state. This is typically used for stopping the machine at the request of the operator but could also be used for specific machine conditions.
The operator commands to leave a Wait state can be issued directly or code can be written to simply go to the next state in the normal flow. For example, when in the Idle state the Start command must be given to the PML_StateMachine
function block. This command can come from the operator issuing the specific command, or itβs also possible to have code that accepts a generic command to go to the next state and then have some code to analyze the current state and determine what proper next state will be.
The State Complete command is issued by logic based on the programmed conditions. For example, in the Starting state once the conditions are met the StateComplete command will be issued, and the state machine will transition to the Execute state.
When configuring modes with the PML_UnitModeConfig
function block it is possible to disable certain states. When a state is disabled, it will still use it normal command to leave that state, and if the following normal state is disabled then the PML_StateMachine
function block will manage which state to transition to. It is also possible to have the code pass through a state by simply setting the StateComplete command upon entering or automatically calling the command required to leave a wait state.
According to the documentation the Execute state is defined as an Acting state. However, it does not use State Complete as the other acting states do. Instead, the Complete command must be issued in order to transition to the Completing state. This can be done based on some logic such as the number of parts produced, or it could be issued when the operator gives the command at the end of a batch.
The Execute state also has the possibility of moving to either the Hold or Suspend state. The Suspend state is used when the machine stops itself based on the defined conditions. Typically, this will be a material-end situation or other possible machine conditions that cause the machine to pause itself. The machine can then return to the Execute state either by operator command or machine logic. The Held state is used by the operator when a condition arises that the operator wishes to pause the machine for. This could simply be for the operator to step away from the machine or to fix an issue before it becomes a larger problem. The operator will then issue the Unhold command to return to the Execute state.