Below is the refined deep-dive for Topic 6.3 — Command Handling & Safe Control, aligned with your roadmap’s emphasis on safe command enablement, machine states, modes, interlocks, and start/stop/pause/resume/abort semantics.
Command Handling & Safe Control
In industrial HMI software, a button is never “just a button.”
In a business application, clicking a button may save a form, submit a request, or refresh data. If something goes wrong, the result is usually a validation error, a failed transaction, or a bad user experience.
In an industrial machine, clicking a button may:
- start motion
- activate vacuum
- open a clamp
- move a wafer stage
- start inspection
- reset a fault
- resume an interrupted workflow
- place the machine into manual mode
- trigger a device action
That means HMI command handling is part of the machine’s control boundary.
The UI does not merely collect user input. It expresses operator intent into a system that may cause physical behavior.
A strong industrial architecture treats every operator command as something that must be accepted, validated, routed, executed, rejected, logged, and explained.
PART 1 — WHY UI COMMANDS ARE SAFETY-CRITICAL
A common mistake from engineers entering industrial UI is thinking:
“The button is disabled when the action is not allowed, so we are safe.”
That is not enough.
Button enablement is only a user-experience hint. It helps guide the operator, but it must never be the final safety mechanism.
The real safety boundary must exist behind the UI, in the application/control layer.
Why?
Because UI state can be stale.
The HMI may believe the machine is idle, but the machine controller may have already transitioned into running. The HMI may believe an axis is ready, but the motion controller may have faulted 200 milliseconds ago. The UI may disable a command, but the same command may still be sent from a keyboard shortcut, service screen, remote API, automation script, or delayed event handler.
In machine software, the real question is not:
“Is the button enabled?”
The real question is:
“At the exact moment this command reaches the command boundary, is it still valid and safe?”
Consider a few examples.
A Start command while the machine is not ready may start a workflow with an unhomed axis, missing wafer, invalid recipe, open guard door, or unavailable camera.
A manual jog command while an automatic workflow is running may move an axis that the workflow assumes it owns. The result can be wrong positioning, collision risk, failed inspection, or corrupted workflow state.
A Reset Alarm command may clear the UI message, but if the physical cause remains — vacuum lost, door open, servo fault, clamp not closed — the machine is not actually safe to continue.
So HMI command handling must be designed as a controlled safety boundary, not as casual event handling.
PART 2 — COMMAND INTENT VS COMMAND EXECUTION
A key architectural principle is:
The UI expresses intent. It does not execute machine behavior directly.
The operator says:
“I want to start.” “I want to pause.” “I want to jog X positive.” “I want to reset this fault.” “I want to turn vacuum on.”
But the UI should not decide alone whether the command is safe.
The application/control layer evaluates the intent against current machine state, mode, interlocks, user role, workflow ownership, and device readiness. Only after that does the machine controller execute the validated action.
+----------+ +-------------------+ +-------------------+
| Operator | ---> | HMI / ViewModel | ---> | Command Intent |
+----------+ +-------------------+ +-------------------+
|
v
+---------------------+
| Command Validator |
+---------------------+
|
accepted / rejected / confirmation required
|
v
+---------------------+
| Machine Controller |
+---------------------+
|
v
+---------------------+
| Device Layer |
+---------------------+This diagram shows the most important separation.
The HMI does not call the device directly.
Bad:
Button Click -> Axis.MoveRelative(10)Good:
Button Click -> JogAxisCommandIntent
-> Command Gateway
-> Validate mode/state/interlocks/ownership
-> Machine Controller
-> Motion subsystemThis matters because physical execution must be centralized, serialized where needed, auditable, and validated against the real machine state.
PART 3 — COMMAND ENABLEMENT / DISABLEMENT
Command enablement means the HMI shows whether an action appears currently allowed.
For example:
- Start enabled only when machine is idle, ready, recipe loaded, and no blocking alarms exist.
- Pause enabled only when workflow is running and currently pausable.
- Resume enabled only when workflow is paused and context is still valid.
- Abort enabled only when an operation is active or recovering.
- Manual Jog enabled only in manual/maintenance mode, with axis ready and no workflow owning the axis.
- Reset Fault enabled only when the user role allows it and the fault is resettable.
Enablement depends on multiple signals:
Command Enablement =
Machine State
+ Operating Mode
+ User Role
+ Interlock State
+ Workflow Status
+ Device Readiness
+ Alarm/Fault Status
+ Resource OwnershipA button should not be enabled just because the screen is visible.
For example, a “Jog X+” button may depend on:
- machine mode = Manual
- user role = Technician or Engineer
- axis X homed = true
- servo enabled = true
- no hard limit active
- no soft limit violation
- guard/interlock policy allows manual motion
- workflow is not running
- axis X is not owned by another subsystem
- command rate limit is satisfied
However, enablement is still not enough.
The UI may render based on state snapshot T1, but the command reaches the backend at T2.
Between T1 and T2, the machine may change.
Time T1:
UI sees MachineState = Idle
Start button enabled
Time T2:
Operator clicks Start
Time T3:
Before command is processed, machine enters Faulted
Result:
Backend must reject StartSo the rule is:
UI enablement improves operator guidance. Backend validation enforces correctness.
PART 4 — SAFE COMMAND GATING
Safe command gating is the validation pipeline between operator intent and machine action.
A typical command gate checks:
- Is the user authorized?
- Is the command valid in the current operating mode?
- Is the command valid in the current machine state?
- Are interlocks and permissives satisfied?
- Are required devices ready?
- Is the workflow at a valid transition point?
- Should the command be accepted, rejected, queued, or require confirmation?
A useful validation model looks like this:
+----------------------+
| Operator Command |
| e.g. Start, Jog, |
| Pause, Reset Fault |
+----------+-----------+
|
v
+----------------------+
| User Authorized? |
+----------+-----------+
|
no ----------+---------- yes
| |
v v
+-------------+ +----------------------+
| Reject | | Mode Allows Command? |
| Unauthorized| +----------+-----------+
+-------------+ |
no -------+------- yes
| |
v v
+-------------+ +----------------------+
| Reject | | State Allows Command?|
| Wrong Mode | +----------+-----------+
+-------------+ |
no -----+----- yes
| |
v v
+-------------+ +----------------------+
| Reject | | Interlocks OK? |
| Bad State | +----------+-----------+
+-------------+ |
no ------+------ yes
| |
v v
+-------------+ +----------------------+
| Reject | | Devices Ready? |
| Interlocked | +----------+-----------+
+-------------+ |
no ------+------ yes
| |
v v
+-------------+ +----------------------+
| Reject | | Workflow Transition |
| Not Ready | | Point Valid? |
+-------------+ +----------+-----------+
|
no ------+------ yes
| |
v v
+-------------+ +----------------+
| Reject | | Accept Command |
| Bad Timing | +----------------+
+-------------+The rejection must be explicit.
Bad rejection:
Command failed.Good rejection:
Start rejected:
Machine is in Faulted state.
Blocking fault: Vacuum pressure low.
Required action: restore vacuum, then reset fault.Operators and service engineers need to understand why the command was rejected.
A rejected command is not just an error. It is part of operator guidance and machine diagnosability.
PART 5 — HANDLING START / STOP / PAUSE / RESUME / ABORT
These commands sound simple, but in real machines they have very different meanings.
They must not be treated as synonyms.
Start
Start means:
Begin a controlled workflow only if all required preconditions are satisfied.
Typical Start checks:
- correct mode, usually Auto
- valid recipe loaded
- machine initialized
- required axes homed
- devices ready
- no blocking alarms
- safety/interlocks satisfied
- product/job/lot context valid
- workflow not already running
- no conflicting manual ownership
Start should create or activate a controlled workflow session. It should not directly fire random device calls from the UI.
Start Intent
-> Validate machine readiness
-> Validate recipe/job context
-> Create workflow run context
-> Start workflow through controller
-> Return accepted resultStop
Stop usually means:
Stop in a controlled way at a safe boundary.
A Stop command may allow the current motion, inspection, or handling step to reach a safe point before stopping.
For example:
- finish current image acquisition
- stop after current wafer is returned to a safe position
- stop after clamp closes
- stop after motion decelerates normally
- stop before starting the next workflow step
Stop is usually cooperative.
It should leave the machine in a known, recoverable condition.
Pause
Pause means:
Suspend workflow execution safely while preserving context.
Pause is not simply “freeze everything.”
A machine may need to reach a safe pause point first. It may need to complete a motion segment, turn off illumination, hold vacuum, keep servo enabled, or maintain current product state.
Pause must define what remains active.
For example:
- Is vacuum still held?
- Are motors still servo-on?
- Is the camera acquisition stopped?
- Is the current wafer still considered in process?
- Can the door be opened?
- Can manual controls be used while paused?
Without explicit semantics, pause becomes dangerous.
Resume
Resume means:
Continue from a paused state only if the original context is still valid.
Resume must revalidate.
A workflow paused five minutes ago may no longer be safe to resume.
Things may have changed:
- operator opened a door
- axis lost position
- device disconnected
- recipe changed
- wafer was removed
- alarm occurred
- manual command moved an axis
- inspection context expired or was invalidated
Resume must not blindly continue.
Resume Intent
-> Is workflow paused?
-> Is pause context still valid?
-> Did any safety/device/recipe/product state change?
-> Are required resources still owned?
-> Continue or reject with reasonAbort
Abort means:
Interrupt more aggressively and drive the system into a known recovery state.
Abort is not just a faster Stop.
Abort may cancel workflow execution, stop pending operations, invalidate current product context, release or preserve specific resources, and require recovery before restarting.
Abort should be explicit because it may leave product or process state incomplete.
For example:
- wafer may be in unknown inspection status
- image sequence may be incomplete
- alignment result may be invalid
- motion may be stopped mid-sequence
- operator may need recovery guidance
A strong system clearly distinguishes:
Stop = controlled stop at safe boundary
Pause = temporary suspension with resumable context
Abort = interrupt and transition to recovery pathPART 6 — MANUAL CONTROL COMMANDS
Manual control is one of the riskiest areas in an HMI.
Manual commands include:
- jog axis
- move to position
- home axis
- enable/disable servo
- turn vacuum on/off
- open/close clamp
- trigger camera
- turn illumination on/off
- move robot arm
- reset a device
- override a subsystem state
Manual screens are often used by technicians, engineers, and service teams. They are powerful because they help with setup, debugging, calibration, and recovery.
But manual mode must not mean:
“Bypass all rules.”
That is a dangerous design.
Manual commands still need gating.
Manual Command Gate =
Correct mode?
+ Correct role?
+ Safety state OK?
+ Interlocks satisfied?
+ Device ready?
+ Resource not owned by workflow?
+ Command within limits?
+ Command rate acceptable?
+ Confirmation required?Example: jog axis.
The UI may show a jog button. But the backend must still check:
- Is machine in Manual or Maintenance mode?
- Is the axis homed if homing is required for safe jogging?
- Is the requested direction allowed?
- Will this exceed soft limits?
- Is a hard limit already active?
- Is the axis faulted?
- Is any workflow currently using the axis?
- Is the guard door state compatible with this motion?
- Is the operator allowed to perform motion commands?
Manual command ownership is especially important.
If an auto workflow owns the stage, manual jog must be rejected.
+-------------------+ owns +-------------------+
| Auto Workflow | ------------------> | X/Y Stage |
+-------------------+ +-------------------+
Manual Jog Request
|
v
+-------------------+
| Command Gateway |
+-------------------+
|
v
Reject: Stage is currently owned by Auto WorkflowWithout ownership rules, manual screens can corrupt the assumptions of running workflows.
PART 7 — REAL-WORLD FAILURE SCENARIOS
1. UI button enabled based on stale state
What it looks like:
The Start button is enabled. Operator clicks it. Machine rejects it, or worse, starts incorrectly.
Why it happens:
The UI was showing an old machine snapshot. The backend state had already changed.
How experienced engineers handle it:
They treat UI enablement as advisory only. Every command is revalidated at the command gateway using the latest authoritative machine state.
2. UI disables command, but backend still accepts it from another path
What it looks like:
The button is disabled on the main screen, but the same command still works from a service screen, hotkey, script, remote interface, or delayed message.
Why it happens:
Validation logic was placed in the ViewModel instead of the backend command boundary.
How experienced engineers handle it:
They centralize command validation. Every path goes through the same command gateway.
Main Screen Button ----+
Service Screen Button -+
Hotkey --------------- +----> Command Gateway ----> Validation ----> Execution
Remote Command --------+The rule:
No command path bypasses the gate.
3. Operator double-click causes duplicate command
What it looks like:
Operator double-clicks Start. Two workflow starts are requested. The system creates duplicate runs, sends duplicate device commands, or enters inconsistent state.
Why it happens:
The command is not idempotent, not serialized, and not protected by transition guards.
How experienced engineers handle it:
They use command IDs, transition locks, idempotency checks, and state validation.
Example:
First Start:
Idle -> Starting
Accepted
Second Start:
Machine already Starting
Rejected or ignored as duplicateThe command handler should understand that Start is not valid once the machine has left Idle.
4. Manual command conflicts with running workflow
What it looks like:
A technician jogs an axis while automatic inspection is running. The workflow later assumes the old position and captures images at the wrong location.
Why it happens:
Manual command validation checked only mode or role, but not resource ownership.
How experienced engineers handle it:
They model ownership explicitly.
Resource: Stage
Owner: AutoInspectionWorkflow
Allowed manual command: No
Reason: Resource locked by active workflow5. Reset command clears UI alarm but subsystem is still unsafe
What it looks like:
Operator clicks Reset. The alarm disappears from the HMI. Then the machine immediately faults again or continues in an unsafe condition.
Why it happens:
The UI cleared visual state instead of requesting a real subsystem reset and verifying physical conditions.
How experienced engineers handle it:
Reset is treated as a command, not a UI action.
Reset Fault Intent
-> Check user role
-> Check fault is resettable
-> Ask subsystem to reset
-> Re-read subsystem state
-> Clear alarm only if physical condition is resolvedThe UI must reflect machine reality. It must not invent it.
6. Command accepted while device is not ready
What it looks like:
Start is accepted, but the camera is still initializing. Workflow fails halfway through.
Why it happens:
Readiness was assumed, or readiness check was too shallow.
How experienced engineers handle it:
They define readiness contracts.
For example:
Camera Ready =
Connected
+ Initialized
+ Correct configuration loaded
+ Not acquiring
+ Temperature/status acceptable
+ Last health check valid“Device object exists” is not the same as “device ready.”
7. Stop command behaves differently depending on hidden state
What it looks like:
Sometimes Stop stops immediately. Sometimes it waits. Sometimes it aborts. Operators lose trust because behavior feels inconsistent.
Why it happens:
Stop semantics were not explicit. Different workflow steps implemented their own stop behavior.
How experienced engineers handle it:
They define stop behavior clearly at the workflow/control layer.
Stop Requested During Motion:
Decelerate normally
Move to safe boundary if required
Mark workflow Stopped
Stop Requested During Image Processing:
Finish current frame or cancel processing safely
Do not start next acquisition
Stop Requested During Transfer:
Complete safe transfer or enter recoveryThe operator should understand what Stop means.
PART 8 — SOFTWARE DESIGN IMPLICATIONS
Safe command handling needs a clear architecture.
Bad architecture:
ViewModel
-> Button Click
-> Device SDK
-> Motion Controller
-> Camera
-> Workflow objectThis becomes unsafe because validation is scattered. Different screens can behave differently. It is difficult to audit. It is easy to bypass rules.
Good architecture:
+----------------------+
| View / ViewModel |
| Shows state |
| Captures intent |
+----------+-----------+
|
| CommandIntent
v
+----------------------+
| Application Command |
| Gateway |
+----------+-----------+
|
| Validate
v
+----------------------+
| Command Validation |
| Service |
+----------+-----------+
|
| Accepted command
v
+----------------------+
| Machine Controller / |
| Workflow Layer |
+----------+-----------+
|
| Execute
v
+----------------------+
| Device Layer |
+----------+-----------+
|
| Result / Events
v
+----------------------+
| CommandResult |
| UI / Audit / Logs |
+----------------------+The key design elements are:
Command objects / requests
Commands should be represented explicitly.
Examples:
StartMachineCommand
StopMachineCommand
PauseWorkflowCommand
ResumeWorkflowCommand
AbortWorkflowCommand
JogAxisCommand
MoveAxisToPositionCommand
ResetFaultCommand
SetVacuumCommand
TriggerCameraCommandA command should carry useful metadata:
CommandId
CommandType
OperatorId
UserRole
SourceScreen
Timestamp
TargetResource
Parameters
CorrelationId
ExpectedStateVersion, if neededThis makes commands traceable and diagnosable.
Command validation service
Validation should be centralized.
It should answer:
Can this command run now?
If not, why not?
Is confirmation required?
Is the command rejected, accepted, queued, or ignored as duplicate?Central command gateway
The command gateway is the controlled entry point.
Every operator command path should pass through it:
- main HMI
- service screen
- maintenance screen
- hotkey
- script
- remote operation
- test console
- automation tool
No bypass.
Backend enforcement independent of UI enablement
Even if the UI disables buttons perfectly, backend validation remains mandatory.
This protects against:
- stale UI state
- race conditions
- multiple command sources
- delayed messages
- malicious or accidental bypass
- bugs in ViewModel logic
Idempotency / duplicate prevention
Some commands must be protected against duplicates.
Examples:
- Start
- Abort
- Reset
- Open clamp
- Create run
- Load recipe
- Begin inspection
For Start:
Idle -> Starting -> RunningOnce the first Start transitions the machine to Starting, the second Start should not create a second workflow.
Audit trail
Operator actions should be logged.
Not just failures. Accepted and rejected commands both matter.
A good audit entry includes:
Timestamp
Operator
Command
Parameters
Machine state at request time
Validation result
Rejection reason, if any
Execution result
Correlation IDThis is extremely valuable during production incidents.
Explicit rejection reasons
A command rejection should help the operator or technician know what to do.
Bad:
Cannot execute command.Good:
Jog X rejected:
Machine is in Auto mode.
Switch to Manual mode and stop active workflow before jogging axis.Better:
Start rejected:
Machine is not ready.
Blocking conditions:
- Recipe not loaded
- Camera not ready
- Vacuum pressure below thresholdAccepted Command Sequence
Operator HMI/ViewModel Command Gateway Validator Controller Device
| | | | | |
| Click Start | | | | |
|---------------> | | | | |
| | Create StartIntent | | | |
| |------------------->| | | |
| | | Validate | | |
| | |------------------->| | |
| | | | OK | |
| | |<-------------------| | |
| | | Execute | | |
| | |----------------------------------->| |
| | | | | Start flow |
| | | | |------------>|
| | | | | Result |
| | |<-----------------------------------| |
| | Show Accepted | | | |
|<----------------| | | | |This sequence shows that the UI does not start hardware directly. It sends intent, receives a result, and updates the operator display.
Rejected Command Sequence
Operator HMI/ViewModel Command Gateway Validator
| | | |
| Click Start | | |
|---------------> | | |
| | Create StartIntent | |
| |------------------->| |
| | | Validate |
| | |------------------->|
| | | Reject: Faulted |
| | |<-------------------|
| | Show rejection | |
|<----------------| | |A rejected command is not a system failure. It is a correct safety behavior.
The important part is that the rejection is specific, visible, and logged.
PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS
A strong way to explain this in an interview:
In industrial HMI systems, I would not let UI buttons directly control hardware or workflow objects. The UI should express command intent, and all commands should go through a central command gateway. That gateway validates the command against user role, machine mode, current state, interlocks, device readiness, workflow transition points, and resource ownership. UI enablement is useful for operator guidance, but it is never the final safety mechanism because UI state can be stale or bypassed. The backend must enforce the rules and return explicit accepted or rejected command results with audit logging.
Common mistakes software engineers make when entering this domain:
- putting safety checks only in ViewModels
- treating disabled buttons as safety protection
- calling device APIs directly from button handlers
- not distinguishing Stop, Pause, and Abort
- allowing manual mode to bypass workflow/resource ownership
- not handling duplicate clicks or repeated commands
- clearing alarms visually without verifying subsystem state
- failing to log rejected commands
- giving vague command failure messages
- assuming device object existence means device readiness
What strong engineers understand:
HMI command handling is not UI plumbing. It is a controlled boundary between human intent and physical machine behavior.
The UI should be responsive and clear, but the machine must be protected by centralized validation, explicit state transitions, interlocks, ownership rules, duplicate protection, and traceable command results.
That is the difference between a desktop application that merely has buttons and an industrial HMI that safely controls a real machine.