1. Home
  2. Unit
  3. Unit Procedure

Unit Procedure

 

 

A unit procedure is an optional and custom component of the S88 Builder and provides the ability for a complex processing function within a unit.  Most batching functions can be performed with standard EM, phases and actions.  Recipe control is typically handled by a Batch sequencer system so the unit procedure is typically used for continuous processing functions that aren’t controlled by batch.

In V2, the Unit Procedure is custom logic associated with a unit that manages Actions, maintains mode, and executes unit operations, and manages State.  The individual states may have unit operations associated with them which is also known as the Unit Action Operations.  Therefore, a unit procedure is generally required if a unit action exists.   As shown below the Unit Procedure may be programmed to execute many Unit Operations.

 

In future versions, the unit procedure will be an automated recipe execution system capable of processing simple recipes or state machines downloaded to it from the S88 Builder Studio.  An automated recipe execution system would:

  • Have a recipe builder in a higher level language such as VB and downloaded into the controller
  • Interpret procedural logic and stepping through the operations
  • Check the transition conditions in the unit recipe procedure
  • Add a record of every action to a batch record
  • Provide for the three modes: Automatic, Semi-Automatic & manual

Action Management 

Unlike EM actions which are completely controlled by firmware in responses to the EMs they affect, unit actions have no built-in control scheme.  Therefore, the Unit Procedure must manage all aspects of the action live tile.  This includes:

  • Enable/Disable Live Tile
  • Menu Command visibility and enabled
  • Responding to initiated commands
  • Controlling Color Bar
  • Applying Action Control Parameters

Mode Control 

The unit procedure also has mode which directs how it manages its state and unit operations.

The procedure has 3 modes:

  • Auto Unit Procedure is in control of operation logic and transition timing.
  • Semi-Auto Unit Procedure is in control of operation logic but user choose when to transition but may not force it.
  • Manual Operator controls order of execution and transition timing.

Procedure Commands 

START/STOP/ABORT

The Unit Procedure Operations may be started and Stopped or Aborted.  Stopping or aborting the unit procedure will automatically stop or abort all owned phases.  The Stop and Abort commands may be disabled or hidden by the user’s custom unit procedure configuration.  As well as any Unit Procedure command may be hidden so the function is not available.

Is it practical for a Unit Procedure to have a Start/Stop function?  Or should the state machine be always active?

The state machine is also a bit confusing since the Unit Procedure already has inherent state as in Idle, Running, Held, Restarting, Stopping, etc.   But just a few paragraphs earlier we indicated the Unit Procedure manages custom states with a state machine.

PAUSE/RESUME & HOLD/RESTART

A unit procedure may also be paused or held.

While paused the unit operation will stop progressing at programmed safe states.  The user may Step or Resume once held.

Program a STEP command

While held the unit procedure will hold all phases owned by the procedure.  Once held, each phase may be manually restarted via the phase faceplate.   The user may also restart the unit procedure which will automatically restart all owned phases.

ADVANCE 

In Semi-Automatic mode the automatic state transitioning is suspended so the operator must press the ADVANCE button to move to the next state but this button is only enabled when the normal transition timing is triggered.  The ADVANCE button may also be forced in Automatic mode when it is desired for the operator to advance to the next state regardless of the mode.  This is required when the operator must do a manual inspection before proceeding to the next state.

State Machine 

The unit itself does not have state but when a unit procedure is programmed it is typically configured with a state machine and therefore manages the unit state.  Notice in the image above the Filter State is the same as the step name which are the unit procedure states.  The sub-states, like 3.1 – 3.3, are steps of the state’s unit operation.

Unit Operation

A unit operation, also known as an Action Operation or State Operation, is a sequence that performs a minor processing function typically triggered by an action and/or a unit procedure state change.  Complex unit actions or states typically require a unit operation to carry out the action or state.  Each step of the unit operation will typically start a phase or apply CP to an active phase.  The unit operation may start or interact with multiple phases but it is limited to interacting with the equipment through the phases exposed by the unit.  Evidence of the unit operations can be seen in the Unit Procedure state sequence illustrated in the image above.  The unit operation steps can be seen as the sub-states, such as 3.1, 3.2, & 3.3 of state 3 (Generate Filter).

Faceplate 

The unit procedure faceplate requires custom configuration but it has a lot of standard features.

  1. Unit Procedure Name
  2. Unit Procedure State
  3. Unit State
  4. Optional Unit Parameters
  5. Unit State and Operation Steps

All parts of the Unit Procedure faceplate are configured through a unit procedure structure built into the S88 Builder Engine.  In V2, this configuration is strictly custom.

Unit Procedure Name 

This is a 32 character name describing the primary function of the unit procedure.  Note: the name is not shown in the above image because it was left blank.

Unit Procedure State 

The unit procedure state is a fixed and represents the state of the procedure (not the unit)

Unit State 

The unit state depends on the current position of the unit procedure state machine which is represented in the list of steps illustrated on the faceplate.  Each step is described with a name and description in the Unit Procedure structure.

Operation Unit Parameters 

The unit has the option to display many control and report parameters.  This area just above the Unit Procedure states and operation steps is reserved for some custom displaying of those parameters.  These parameters may be mapped to phases or floating and managed by the unit procedure.

Unit State and Operation Steps 

Each unit state or operation step has a set of control and report parameters along with a small description that may be configured in the Unit Procedure structure.  These parameters are not mapped and must be programmed with custom logic to be applied as appropriate for that step.  Note: Operation states may not be selected with manual mode.

Unit State – 1, 2, 3, 4

Unit Procedure State – Running, Idle, Held

Unit Procedure Step(Unit State) – 10(1), 20(2), 30(3), 40(4)

Operation Step – .0,.1,.2,.3

Unit Procedure Configuration 

  1. Create a new Controller Scoped tag called {unit alias}Proc as UNIT_PROC
  2. Fill out these procedure members:
    1. Name        Name of Unit Proceure (ex: Mixer1 Sequence)
    2. PB…        Set the Visibility tag for each PB you want the user to have access to
    3. Batches
      1. Desc    Set the batch counter description
      2. CP    Set Min/Max, IsInteger and Visibility if desired
      3. RP    Set Visibility and IsInteger if desired
    4. SEnab
    5. SNum
    6. SName        Starting type a name for each state step where element 0 is the off state
      1.      Each row is free form on how you want it to look on the faceplate.
      2. Each major sequencing step needs as many rows as you have parameters for that step + 1 (+1 is for header row which could be skipped).
        Example: a 1ststep adds water and agitates requiring 2 control parameters so you would fill out the step names as:
        SName[1] = Add Water with Agitation
        SName[2] =     Water
        SName[3] =     Agitate
        SName[4] = [next step name]
    7. PName        Provide a parameter name (typically parameter units) on each element that corresponds with the step name previously entered.
    8. SNum        (optional) Assign a step number to each step previously entered. Only number the header rows.
      This is free form so you can use any number scheme but consecutive numbers starting at 1 work best.
    9. SEnab        Enable all steps previously defined.
    10. SMsg        (optional) Provide message to appear on phase message line 2 for each step.
    11. SErrMsg    (optional) Provide message to display on phase message line 2 if step fails
    12. CP        Set Min/Max, Enabled, Visibility and any other member that applies for each parameter as it corresponds to the SName.
    13. RP        Set Visibility and any other member that applies for each corresponding SName.
    14. StPtrLU        This is the step pointer lookup table which is consecutive for each major step. Assign the SName row that applies for each step, skipping sub rows.
    15. LastStStep Set this value to the last major step x 10.
  3. Create a new routine in the Unit Program called Unit_Procedure_Custom_{unit alias}_OP
  4. Create a new routine in the Unit Program called Unit_Procedure_Custom_{unit alias}
    1. Insert Rung calling PROC_CMD AOI, see illustration.
    2. Insert a 2nd rung calling PROC_STATE
    3. Insert a 3rd rung to call the operation procedure just previously created

 

 

Programming Access to S88 Builder Object 

In version 2 all unit action operations are custom logic in a custom routine called by the Unit Procedure.  The unit action operation must rely on aliases and element positions to do its tasks.  Following is a list of available tags to the unit operation:

  • Unit Alias Every unit has an alias pointing to its control element
  • Phase Alias Every phase has an alias but this alias points to the Batch portion of the phase.  Therefore, a program interface component of the batch phase allows control of the unit phase.
  • Unit The unit and its primary vessel is accessed via a unit alias.
  • Vessel Only the primary vessel may be accessed by the unit procedure via the unit Alias.  Access to other vessel’s status can only be done through the use of Unit Tags
  • Actions Actions exist as elements of an action array and the action’s position in the array is subject to change so an AOI exists that will find an action based on its Unit container and its 1’st line Name.
  • EMThe unit operation should not access EMs as it’s should work through the phases.  However access to the EM program interface is available via the phase program interface.
  • CM CMs may not be accessed directly so all access must be done through unit tags.
  • Instruments Only the primary vessel’s instruments are accessible via the unit’s alias.  All other instruments must be accessed through the unit tags.
  • Tags Units, Vessels, EMs, and CMs all have 1 or more definable and customizable tags that may be used to represent any value or logic conditions in the S88 Builder System.  However, only Unit and its primary Vessel tags are easily accessible from the unit procedure and operations.  But a unit tag can be configured to mirror any of the other tags if necessary.  A tag may be configured to be aliased in any object which would provide direct access to that tag from the unit procedure.

Sequence Control 

  1. Start every rung with .Mstr as an overall line permissive
  2. Next verify the State, .ST.Value.  The states jump by 10 so 10 is actually state 1.0 and 15 is state 1.5.  Each state may execute an operation procedure which would utilize the sub-states. This value is incremented automatically by the firmware as it transitions.

START PROCEDURE

  1. The Start rung is different in that it must wait for the sequence to be started.
  2. Check that this isn’t the initialize scan, .Init, which is used to reset all timers and other coils.
  3. Latch .WaitAdv to enable the Advance PB.
    The Advanced PB is automatically enabled at the completion of every state while in Semi-Automatic mode.
    While enabled it prevents the automatic mode from advancing to the next state.
    While enabled it also sets the Process State Text to UnitProcessStateText[1{held}] and sets the held color.
    This tag also causes the Unit OK Prompt to be displayed for the same purpose as the Advance PB.
    This tag is reset every scan so it must be continuously latched.
  4. Latch .Fail to trigger the alert navigator and to display the state SErrMsg.
    This tag is reset every scan so it must be continuously latched.
  5. Wait for .Advance which is 1-shot when the user presses the Advance PB.
    Pressing Advance PB will also set  .StateAdv if the current state is complete.
  6. Verify the procedure is in .Auto or .SemiAuto before starting and not .Paused.

 

STATE LOGIC 

Each state may be a simple phase or group of phases for a minor function.  Or it could trigger an operation procedure that controls various phases to do some major function.

The state logic has 3 parts: Acquire, Start, Wait

Acquire

Acquire all phases required for this state

  1. Examine Previous Step to make sure this state doesn’t jump over a step
  2. If not acquired Acquire each required phase using the PH_ACQUIRE AOI
    Proc: This process UDT
    PH: The phase alias pointing to the phase interface to acquire (This is not the FT Batch phase alias).
    Owner: The Unit (always unit.Cfg.Me)
    C: Constants (always c)
    AutoRelease: Set to 1 to have this phase be released when the state advances or 0 to manually release the phase for when the phase must be acquired across multiple states, such as an agitator.
    Release: Set when releasing the phase instead of acquiring it.
    Test: Set when just testing if the phase is acquired.  This does not acquire or release the phase.
    MiscSmMsg… Always set to tag of same name. Required for communicating with the phase.
  3. Once Acquire seal in the next Step

 

Start

Pass Control parameters to the newly acquired phase(s) and start it, or them.

  1. Check the previous step
  2. Verify State is not Complete, .StateCplt, just to make sure no parameters are resent or phases restarted.
  3. Write Unit ID and any required CP to phase until they are as expected.
    Used CMD_VALUE and CMD_PARAM respectively.
  4. Test to make sure all parameters and Unit ID are verified then send a Start command to phase(s) using CMD_SET.

WAIT

Wait for transition condition to be satisfied and mark complete.

  1. Wait for phase(s) complete or any other transition condition.
  2. Latch .StateCplt to cause the state to advance or to display the Advance PB.
  3. Also test for an alternate phase ending and set the .WaitAdv and .Fail to enable the Advance PB and Alert navigator.  Also set a custom .SubMsg to indicate what the problem is.
    (Note: Fail is optional because the Alert Navigator is also triggered by the OK Prompt. Fail also displays the SErrMsg which may or may not be desired).
  4. Then wait for the user to Advance the condition to continue to the next state. (NOTE: in SemiAuto mode this will cause the user to have to press the Advance button twice.  Once to bypass this condition and again to go to the next state.)

StPtrLU points to an offset of messages whose value is added to the Substate to get the actual message pointer in SubStatePtr

So SMsg is freeform to align with each state/substate.

PH_ACQUIRE AOI 

Acquire Phase and pass in Unit ID

Features:

  • Reset Phase if ended and already acquired
  • Verify Phase is Idle or raise an abnormal condition
  • Acquire the phase
  • Set the Unit ID
  • Enable Output when Phase is Acquired, Idle and Unit ID has been verified

PH_RELEASE AOI 

Release Phase

Features:

  • Stop Phase if not ended
  • Reset Phase
  • Release Phase

StateAdv 

Don’t allow the state advance to complete until all Auto Release phases have been released.

Problem is that it is the advance that triggers the release so hard to prevent when it already occurred.

Could Add a Proc tag called PrevStateComplete that will be default until a full scan reveals nothing left to do.

Message Propagation 

The phase message area is controlled directly by the unit procedure if it exists.

Each line is used to display different information.

There are 3 lines in the Phase Message area:

State Step Pointer 

The unit procedure is driven by state steps which are tracked as a factor of 10.  So the state steps 1, 2, 3 are represented in logic as 10, 20 & 30.  The unit state names and text elements don’t correlate directly with the procedure state step but rather through a pointer system as follows:

Sub-State pointer = StPtrLU[StateStep/10] + OpStep

StPtrLU points to the 1st message of each state so if state 1 has 2 messages then 1st state pointer would be directed to element 1 and 2nd state pointer would be directed to element 3.

OpStep is always 0 unless set by custom sequencing logic.

Operation-State Pointer (OpStatePtr) directs the messages that apply to the current state step/op-step.

Line 1 

Product/State description.

Syntax: {Product Code} – {Unit State} – {State Name}

Product Code {unit}.c.ProductCode

Unit State {unit}.c.State.Text

StateName {unit}Proc.Sname[OpStatePtr]

Or

Just {unit}.c.State.Text when not running

{unit}.c.State.Text

The unit state text is free form and is only set by custom logic as required.

Line 2 

Line 2 display’s the Sub-Message which is also displayed in the message area on the unit procedure faceplate.

The sub message is built depending on various conditions.

In order of priority:

Sub-Message {unit}Proc.SubMsg if set (set by user logic or faults in phase AOI)

{unit}Proc.SErrMsg[subStatePtr] if failed (.Fail)

{complete text} if completed (.StateCplt). Text is fixed in AOI.

{unit}Proc.SMsg[subStatePtr] Default state sub-message when none above exist

Line 3 

Line 3 is used to show the unit procedure state, but not the “Running” state, or to show the “Press OK to Advance” prompt which is displayed when the OK Prompt is visible. This text is fixed inside the Process AOI.

Unit Procedure State PressOKtoAdv When Unit Prompt is displayed

{unit}Proc.ST.Text When not Running or Idle or when Manual or Paused.

Unit Procedure State Text

This is the procedure state such as Idle, Running or Advance

Procedure State {unit}Proc.ST.Text = UnitProcStateText[ST.Value]

ST.Value = State of procedure as managed by PROC_CMD AOI.

Procedure State text comes from controller scoped UnitProcStateText array where each element represents one of the standard state enums.

0 = IDLE

1 = ADVANCE?

2 = PAUSED

3 = STARTING

4 = RUNNING

7 = HOLDING

8 = HELD

9 = RESTARTING

10 = STOPPING

12 = COMPLETING

14 = MANUAL

15 = MANUAL – RUN

Updated on January 7, 2019

Related Articles

Password Protected