Suppose the operator holds Jog and then selects Auto. Merely placing a selector in front of the output does not tell you what should happen to an interrupted automatic sequence, a held button or a pending request. Write the transition contract first. For the teaching station, a mode change withdraws existing ordinary motion requests and requires a newly eligible request under the selected mode. The exact machine procedure must account for its physical state.
A mode decides who may request what
Auto and Manual are often presented as two labels on a selector. In a well-defined program, they are rules about authority and permitted behaviour. Auto may let a sequence request actions. Manual may let an operator request individual actions under defined conditions. Neither label explains by itself how a mode change is handled during motion.
For the packaging cell, suppose a carton is halfway through filling when Manual is selected. Should filling stop immediately, finish the current dose, or enter a controlled interruption? What happens to the partly filled carton? Who may move the conveyor afterward? These are process decisions, not details to discover after adding a selector switch.
Start with a mode table. Include command sources, allowed operations, entry conditions, and what happens to an operation already in progress.
Separate requested mode from accepted mode
An HMI selection can request Manual while the controller still needs to complete an agreed transition. Represent that honestly: RequestedMode and ActiveMode may differ. Expose the reason if acceptance is delayed.
Do not display “Manual” merely because the screen button changed colour. The operator needs to know which command source the controller actually accepts. Likewise, reject stale Auto requests after a switch to Manual instead of letting them remain armed for a later return.
For a simple teaching policy, accept a mode change only after active requests have been removed and the cell has entered a defined interrupted or idle condition. Require fresh commands after acceptance. This policy is easy to test, but it is not universal; some processes need controlled completion before changing authority.
Manual does not mean unrestricted
An operator may need to jog the conveyor to inspect a carton, but that does not imply the conveyor may run while the filling head obstructs its path. Keep operational conflict checks in the actuator owner shared by Auto and Manual requests.
(* Excerpt: ordinary operational command arbitration only. *)
AutoConveyorRequest := (ActiveMode = MODE_AUTO)
AND SequenceConveyorRequest;
ManualConveyorRequest := (ActiveMode = MODE_MANUAL)
AND JogRequestFresh
AND JogHeld;
ConveyorRequest := AutoConveyorRequest OR ManualConveyorRequest;
ConveyorCmd := ConveyorRequest AND ConveyorPermitted;JogRequestFresh represents the project's command-validity policy, not a built-in instruction. For a networked HMI, a true button tag can remain true after communication fails. The controller needs an agreed method of detecting stale commands and responding to connection loss. A screen's mouse-up event alone is not a reliable machine-control contract.
Manual operation, reduced-speed setup, and protective functions require appropriate machine-specific design. This example teaches request ownership; it does not validate a manual-motion safety arrangement.
Stop, abort, pause, and reset need distinct meanings
A pause may preserve an operation so it can resume under defined conditions. A stop may end the current cycle and require a new start. An abort may abandon process progress and require recovery or product disposal. Reset may clear an eligible fault record without authorizing any movement.
Choose terms that the operators understand, then make the program match them. If “Pause” dumps a partial dose and loses its recipe context, the label is misleading. If “Reset” restarts an actuator, the label hides a motion request.
For our filling cell, retaining a partial-fill amount may support a later recovery decision. It does not automatically justify topping up. Measurement drift, material settling, recipe changes, and product quality rules can make continuation unacceptable. Record enough context for the process owner to choose a recovery policy.
Power return is a new observation problem
The controller may remember that it was Filling before power disappeared. The machine may have changed: a valve may have moved to its de-energized position, a carton may have been removed, pressure may have decayed, or an operator may have cleared a jam.
Therefore, a retained state number is historical evidence, not current physical truth. On restart, enter an assessment state with the defined output requests removed. Check current observations, data validity, mode, recipe consistency, and any required recovery acknowledgment before allowing new production.
Retention behaviour depends on the controller, runtime configuration, and restart type. Warm restart, cold restart, download, and memory reset may affect values differently. Build a restart test matrix for the actual target instead of assuming one successful power cycle proves every case.
Decide what to retain by meaning
Useful retained data may include production totals, calibrated parameters, recipe identifiers, and an interrupted-cycle record. Each needs integrity and plausibility checks. A retained target outside the supported range should not become acceptable merely because it came from memory.
Working requests, edge-detector history, and state-machine internals need more careful treatment. An old Start request should not become a new authorization. A retained edge history can also suppress or manufacture an apparent event if it no longer matches the physical input.
For the teaching cell, initialize request arming false and require a released control to be observed before accepting a new press. Preserve interrupted-cycle information separately from the active state. This separates “what happened before” from “what the controller is now allowed to do.”
Recovery needs evidence and a destination
“Press Reset until it works” is not a recovery procedure. A useful procedure identifies the fault, establishes the necessary physical conditions, confirms appropriate feedback, chooses the disposition of affected product, and ends in a named state.
Suppose an arrival timeout occurs. Recovery might require checking the route, removing or repositioning the carton under an approved procedure, then confirming the station is clear. Reset clears the eligible fault and returns to assessment. Once assessment succeeds, the machine becomes Ready. A separate Start begins a new cycle.
The interface should explain the unmet condition: “Waiting for fill position to be clear,” for example. That is more helpful than an unexplained disabled Start button. Keep messages tied to real observations; do not instruct the operator to check a switch the machine does not have.
Try it
Power fails while the cell is Filling. On restart, the retained state says Filling, the carton sensor is active, the scale reports a plausible value, and the Start button is still held. A developer proposes restoring the state and continuing until the target is reached.
List the assumptions hidden in that proposal. Then define a teaching recovery policy and three tests that challenge it.
Work through the answer
The proposal assumes the same carton remains present, the retained target belongs to it, the scale is valid and settled, the dispenser is in a known condition, partial filling may resume, and a held Start is still authorization. None follows merely from a retained state number and one active sensor.
For the model, enter RecoveryAssessment with dispensing and conveyor requests off. Mark the interrupted carton as requiring disposition. Require current valid measurements, agreed actuator feedback, and an explicit recovery acknowledgment after the product decision. When those conditions establish Ready, require Start release followed by a new press.
Test restart with the carton removed, with an invalid scale status, and with Start continuously held. None should resume filling. Add a fourth test in which the operator correctly clears the interrupted product and acknowledges recovery; the machine should reach Ready without motion, then respond to a separate valid Start.
You now have the foundations of a program that can explain itself: named observations, explicit requests, bounded waiting, counted events, state ownership, and recovery rules. Carry those artifacts into every later design. They are what turn a blank editor into a sequence of answerable engineering questions.