Process unit run
The Process unit run concept
Process unit runs are repeating periods in time where the process unit performs a predefined task. Typical examples of process unit runs are production or handling of a batch of material or other cyclic operations. The process unit runs are controlled by the tracker process units.
Run definitions
A process unit can have several types of periodic operations, such as production operation and maintenance operation. The run definition concept is used to distinguish these operations, and the production operation may be instance of the Production run definition while the maintenance operation may be instance of the Maintenance run definition.
Run states
A process unit run has several states. The figure below illustrates the different states and the commands that can change the states. Only the transitions depicted in this figure are allowed. The bold states indicates states where the run is active in the tracker.
The table below contains a description of the states.
| State | StatusCode | NativeBit | Description |
|---|---|---|---|
| Idle | 8388608 | 23 | Idle is defined as the run state when no run is created. It means that the TPU is available for creating/starting a run of the actual run definition |
| Created | 65569 | 16 | When a run is created, the run is registered in the database with a unique process unit run id. The run identifier string and create time is also registered in the database. If there is material inside a TPU when a run is created, the material will be linked to the run in the database. New material that arrives in the TPU when the run is created is also linked to the run. |
| Active | 131171 | 17 | When the run is set to active for the first time, the start time of the run in written to the database. If capturing is configured for the actual run definition, run data capture is performed as long as the run state is active. New material that arrives in the TPU when the run is active is also linked to the run. |
| Paused | 262241 | 18 | When the run is paused, data capturing is stopped until the run is resumed. |
| Ready | 1048616 | 20 | When the run status is set to ready, the end time of the run is written to the database. The capturing is stopped, run is no longer the responsibility of the tracker. The tracker is from no on available for creating a new run of the actual run definition. |
| Finished | 16777264 | 24 | The finished state is used when the run requires post processing. The finished state indicates that the post processing is finished. |
| Canceled for restart | 2097444 | 21 | When the run is set to canceled for restart, any material participating in the run is moved back to their previous tracker process unit. The run is canceled. |
Every state has a unique status code and a native bit. The status code is a bit pattern that are used to describe properties of the actual state. Bits 0-15 are meta information about the actual state according to the table below and bits 16-31 is a bit indicating the actual state according to the NativeBit column in the table above. For example, the Active state status code in Table 1 is 2^17 (Native bit) + 2^0 (Active in tracker) + 2^1 (Running) + 2^5 (Created) + 2^6 (Started)= 131171
| Bit | Meta state |
|---|---|
| 0 | Active in tracker |
| 1 | Running |
| 2 | Canceled |
| 3 | Ready |
| 4 | Finished |
| 5 | Created |
| 6 | Started |
| 7 | Failure |
| 8 | Regret |
Run control
The runs of a tracker process unit may be controlled by port signals on the ModFrame component, or by messages from web pages.
Run identification
Every run instance has a human readable string identifier called MainIdent. The identifier may be set automatically by the TPU, or manually from web pages or port signals on the tracker process unit.