The existing phase implementation is inadequate due to the separation of the EM and Phase objects. This separation allows for too many possibilities that is confusing and overwhelming to the end user. It also requires a lot of configuration and maintenance by the developer.
This new proposed solution combines the EM and Phase into a single object where the EM just implements a phase view. This structure is supported by the S88 Standard:
“Equipment modules contain two views; one is visible to recipe development and execution and another is for automated or manual control. The recipe view is a structure made up of equipment tags, control parameters and report parameters. In this view the way in which the equipment performs task is not visible.”
When an EM is associated with a Unit then its phase(s) becomes one of the Unit phases.
Phase Types (Phase:EM, 8=many)
0:1 Just don’t configure the phase view and the phase tab will be hidden (or disabled)
1:0 These phases are known classes and can be part of the firmware and marked to implement through the unit. (Ex: Message, Initialize, Transfer Out (or In), Sync)
1:1 The phase could be configured as another column in the EM (or EM Class) as the phase view
1:8 A phase may have access to many EMs such as a Xfer-In which may transfer from multiple sources with each its own EM.
The phase should be configured in the EM Class/Type. In each instance mark the phase with the same ID number.
The phase view will then show the phase parameters along with the alternate EMs with options to select or choose a specific EM.
All EMs will share the same phase view but when the phase is running then only the active EM can edit the parameters; the rest will be grayed out.
Or 1 phase may have many destinations each with its own EM such as a Material add with a single flow meter. In batch this is a shared phase. This is different from the transfer which could solve the minor function in many ways; here only 1 EM will meet the needs of the phase per the unit selected. So there is no need to show the other destination vessels from that EM’s view of the phase. So in this way it acts like a 1:1 but its base is shared.
8:1 An EM may have many tasks which each may be represented by a phase. So the phase configuration will allow for multiple views
Each view will be represented by another tab on the EM. Each phase will appear to be running when the EM is doing its task.
Apply/Cancel Phase buttons will appear in the phase view panel to apply that phases task and parameters to the EM. If the EM isn’t running it will start it.
The phase will be configured in a column through the EM Class, Type or Instance table
Phase Parameters will be configured as they are marked to be displayed in the phase view
Some parameters may be marked as hidden (or disable) so as to be permanently set (such as the task selection parameter)
Phases will be given a Unique ID (preferably the same as FT Batch) if two phases share the same ID then those phases will be considered the same phase with a 1:8 relation to the EMs
Phase’s that are associated to multiple units (via their EM association to the unit) will be marked as a shared phase. (this could also be an attribute of the phase and used to confirm configuration)
Appear as a tab of the associated EM
The phase related parameters will appear there, just like the EM parameters
The phase controls will be the same as the EM controls so if the EM is running then the Phase is running and visa-versa
The phase state can be hidden from batch so batch sees an Idle phase which it requires to run the recipe
When batch attempts to start a phase that is running then, if the phase is marked as assume control, it will report back to batch that it is running.
But if not, then it will report back to batch that the phase is owned by the user, which will fail the recipe and put it on hold.
Assume control phases automatically hide their running state from batch.
All phase views will have an Apply button to apply the parameters in the view. These are the auto mode parameters which will apply continuously while the EM is idle in auto mode.
If new parameters are entered while running they must be applied before taking affect. They will not apply if the EM is in manual.
Parameters changed while the EM is running in manual will remain once the EM is returned to Auto and will not affect the Phase Parameters. To return to the phase parameters you must apply them.
This allows a user to modify the EM’s behavior for that running session without permanently affecting the phase parameters. However, the phase parameters will be applied on the next phase transition
Phase parameters can only be modified by the user while on the phase tab or from a higher process system.
Option: Have phase parameters override the EM parameters while Idle and in Auto. This way an AutoStart will use the phase parameters. Modifying them in manual while idle and returning to Auto will cause the parameters to revert back to the phase parameters, in this way manual parameters are only used for manual mode. Auto parameters must come from a higher process system (such as the phase)
MENTAL NOTE: Perhaps CMs that have an analog output should work like the EMs. If the CM is placed into operator mode and the output modified it should remain with that output when returned to
Program mode until the EM changes the modules setting or toggles its state.
Ex: The EM may set the VFD to run at 100%; the user wants to slow it down so they click on it and reduce it to 75% and return to Auto.
Since the EM isn’t changing the setting it doesn’t override but if the EM suddenly changes to 80% then that would override the 75%
Or if the EM turns off the CM and then later back on then it will return to the 100%
This will allow users the ability to change the CM’s behavior for that running cycle without permanently affecting the EM’s parameters.