LCN Wafer Inspection

Appearance

Below is a production-grade view of Service, Manual Control & Engineering Interfaces for industrial HMIs, aligned with your roadmap’s HMI topics such as manual control screens, service/maintenance screens, safe command enablement, and auditability .

Service, Manual Control & Engineering Interfaces ​

Big Picture ​

A production operator UI helps the operator run the machine safely and consistently.

A service or engineering UI helps technical users understand, recover, calibrate, and maintain the machine.

The key rule is:

Service UI gives deeper access, but it must not become a shortcut around machine safety, state, ownership, or logging.

In industrial software, a service screen is not just an “admin page.” It can move axes, toggle outputs, open clamps, reset devices, trigger cameras, change modes, or recover abnormal machine states. That makes it powerful — and dangerous.

PART 1 — Why Service Interfaces Exist ​

Production operators usually need a simple workflow:

text
Load product → Select job → Start → Monitor → Respond to alarms → Unload

They should not need to understand raw IO, servo status words, camera SDK states, vacuum sensor thresholds, or calibration offsets.

Service engineers need deeper access because they handle:

  • machine setup
  • commissioning
  • calibration
  • troubleshooting
  • device recovery
  • abnormal-state recovery
  • diagnostics

Example service actions:

text
Jog X axis
Move Z to service height
Toggle vacuum ON/OFF
Open or close clamp
Trigger camera acquisition
Read raw sensor input
Reset motion controller
Reinitialize camera
Run calibration step

Vietnamese explanation:

Giao diện vận hành bình thường giúp operator chạy máy theo quy trình an toàn. Nhưng kỹ sư service cần nhiều quyền kiểm tra sâu hơn để cài đặt, bảo trì, hiệu chỉnh và xử lý lỗi. Vì vậy service UI cần tồn tại, nhưng nó phải được kiểm soát rất chặt.

PART 2 — Operator UI vs Service UI ​

Operator UI ​

Operator UI is:

  • task-focused
  • workflow-driven
  • constrained
  • safe by default
  • minimal decision-making
  • designed for repeated production use

Example:

text
Start Run
Pause Run
Acknowledge Alarm
Unload Wafer
View Inspection Result

Service UI ​

Service UI is:

  • diagnostic-focused
  • subsystem-focused
  • more technical
  • lower-level
  • riskier
  • used less frequently but under higher pressure

Example:

text
Jog Axis
Home Selected Axis
Toggle Output
Force Device Reconnect
View Raw IO
Run Calibration Step
Export Diagnostic Package

Why mixing them is dangerous ​

If production operators can casually access service functions, they may “fix” symptoms while breaking machine state.

For example:

text
Workflow thinks clamp is closed.
Operator opens clamp from service screen.
Workflow continues as if part is still secured.
Machine moves.
Part shifts or falls.

ASCII comparison diagram ​

text
+---------------------------+        +-------------------------------+
|        Operator UI         |        |          Service UI            |
+---------------------------+        +-------------------------------+
| Run production             |        | Diagnose subsystems            |
| Follow guided workflow     |        | Inspect raw machine state       |
| Limited commands           |        | Manual/semi-manual controls     |
| Few decisions              |        | Technical decisions required    |
| Safe defaults              |        | Powerful but guarded actions    |
| Used every shift           |        | Used during setup/recovery      |
+---------------------------+        +-------------------------------+

The important architecture point:

Operator UI and service UI may be different screens, but they must not be different safety paths.

Both should use controlled command paths.

PART 3 — Manual Control Design ​

Manual controls allow a service engineer to operate parts of the machine outside the normal automatic workflow.

Common manual controls include:

text
Jog axis
Move to named position
Home selected axis
Turn vacuum ON/OFF
Open/close clamp
Trigger camera
Turn light ON/OFF
Reset device
Read sensor state

But “manual” does not mean “direct hardware access.”

A manual command still needs:

  • machine state validation
  • mode validation
  • interlock checks
  • resource ownership checks
  • command logging
  • timeout handling
  • result reporting

Bad mental model ​

text
Button click → device.Move()

This is dangerous.

Good mental model ​

text
Button click → command request → validation → machine controller → device adapter

Manual command flow diagram ​

text
+------------------+
|   Service UI     |
| Jog X +10mm      |
+--------+---------+
         |
         v
+--------------------------+
| Manual Command Request   |
| Command: JogAxis         |
| Axis: X                  |
| Distance: +10mm          |
| RequestedBy: ServiceUser |
+-----------+--------------+
            |
            v
+--------------------------+
| Validation Layer         |
| - Is service mode active?|
| - Is axis enabled?       |
| - Is door/guard safe?    |
| - Is axis homed?         |
| - Is target in limits?   |
| - Does workflow own axis?|
+-----------+--------------+
            |
            v
+--------------------------+
| Machine Controller       |
| Owns machine state       |
| Executes approved command|
+-----------+--------------+
            |
            v
+--------------------------+
| Device Layer             |
| Motion controller / IO   |
+-----------+--------------+
            |
            v
+--------------------------+
| Diagnostics / Audit Log  |
| Who, what, when, result  |
+--------------------------+

The service UI should request action. It should not own execution authority.

PART 4 — Service Mode & Maintenance Mode ​

Service mode changes what actions are allowed.

It should not mean:

text
Ignore safety
Ignore interlocks
Bypass state machine
Directly control hardware
Disable logging

It should mean:

text
Allow controlled service-only commands
Disable incompatible production workflows
Show deeper diagnostics
Require explicit mode entry
Require known-state recovery before production resumes

Mode diagram ​

text
                  +----------------+
                  |    Offline     |
                  +--------+-------+
                           |
                           v
+-------------+     +------+-------+     +----------------+
| Maintenance |<--->|   Idle       |<--->|  Auto/Production|
| / Service   |     +------+-------+     +----------------+
+------+------+            |
       |                   v
       |            +------+-------+
       +----------->|   Recovery   |
                    +--------------+

Explanation ​

  • Idle: machine is powered and controlled, but not running production.
  • Auto/Production: normal workflow owns devices and subsystems.
  • Service/Maintenance: service commands are allowed, but only through validation.
  • Recovery: machine is in abnormal state and needs guided restoration.
  • Offline: machine or subsystem is not ready for controlled operation.

A strong rule:

Service mode should usually be entered from a safe state, not from the middle of an uncontrolled workflow.

Before returning to production, the system should verify known conditions:

text
Axes homed?
Clamp state known?
Vacuum state known?
Part presence known?
Device connections healthy?
Workflow state reset or recovered?
Alarms cleared correctly?

This connects strongly with machine-control design principles: systems should be state-driven, validate physical actions, and treat failures explicitly .

PART 5 — Engineering Diagnostics Interfaces ​

Service screens often expose deeper diagnostics such as:

text
Raw IO monitor
Motion status
Servo enable state
Axis position and following error
Limit switch state
Vacuum pressure
Clamp sensor state
Camera connection state
Frame trigger count
Vision processing timing
Communication trace
Alarm history
Calibration status
Device health metrics

But raw values alone are not enough.

Bad diagnostic UI:

text
Input 17 = TRUE
Output 05 = FALSE
AxisStatus = 0x4087
CameraState = 3

Good diagnostic UI:

text
Wafer clamp closed sensor: ON
Vacuum pressure: OK, -72 kPa
X axis: Homed, servo ON, ready
Camera: Connected, grabbing disabled, last frame 120 ms ago
Light controller: Connected, channel 2 at 65%

The principle:

Diagnostics should translate machine signals into useful engineering meaning.

Raw values are useful, but they should be accompanied by semantic labels, expected ranges, timestamps, and subsystem context.

PART 6 — Recovery and Troubleshooting Flows ​

Service interfaces are often used when the machine is not in a clean normal state.

Examples:

text
Homing failed
Part stuck in clamp
Vacuum not released
Camera disconnected
Axis stopped between stations
Sensor disagreement
Workflow aborted mid-step
Jam condition detected

A weak service UI gives many buttons and expects the engineer to know what to do.

A strong service UI provides guided recovery.

Example: failed homing recovery

text
1. Show current axis position/state
2. Show blocking alarm
3. Check limit switch state
4. Ask engineer to move axis to safe region
5. Re-enable servo if allowed
6. Retry homing
7. Verify homed state
8. Return subsystem to idle

Manual recovery without context is dangerous because it may fix the visible symptom while leaving hidden state inconsistent.

Example:

text
Engineer manually releases stuck wafer.
But workflow still believes wafer is inside inspection station.
Next production step assumes wafer exists.
Machine produces wrong traceability result.

Good recovery must update or reconcile:

text
physical state
workflow state
device state
alarm state
traceability state
operator/service log

PART 7 — Real-World Failure Scenarios ​

1. Service screen toggles output while workflow still owns device ​

What it looks like ​

During automatic production, the workflow controls a clamp. A service screen lets someone manually open the clamp.

The workflow still believes the clamp is closed.

Why it happens ​

The service UI directly calls the IO/device layer.

text
Service button → IO board output

No ownership check exists.

Prevention ​

Use resource ownership:

text
Clamp is owned by AutoWorkflow.
Manual command rejected unless workflow releases ownership.

Better behavior:

text
Cannot open clamp manually.
Reason: Clamp currently owned by Production Workflow Step 42.
Action: Pause/abort workflow before manual control.

2. Manual jog allowed while guard/interlock unsafe ​

What it looks like ​

A service engineer opens a guard door and jogs an axis.

Why it happens ​

Manual mode was treated as a bypass mode.

Prevention ​

Manual jog still checks interlocks:

text
Guard closed?
Safe speed mode active?
Axis enabled?
Travel within limits?
Emergency stop healthy?

Service mode may allow special controlled movement, but it must not ignore safety.

3. Operator uses service screen to bypass normal process ​

What it looks like ​

An operator sees a production alarm and uses a service screen to force an output, clear a sensor, or reset a device.

The machine continues, but traceability is wrong.

Why it happens ​

Service screen is visible in production context, or service functions are too easy to access.

Prevention ​

Separate operator and service workflows clearly.

Also show strong context:

text
Current mode: Auto Production
Manual controls disabled
Reason: Production workflow active

4. Service mode left active after maintenance ​

What it looks like ​

Machine returns to production, but service-only commands remain enabled.

Operators see confusing controls or altered behavior.

Why it happens ​

Mode exit was not explicit or verified.

Prevention ​

Require service exit checks:

text
All manual outputs returned to automatic control?
Temporary overrides cleared?
Axes in known positions?
Devices initialized?
No service locks active?

Good systems show:

text
Cannot enter Auto mode.
Reason: Service mode active / manual override still applied to VacuumValve01.

5. Diagnostic screen shows raw values without meaning ​

What it looks like ​

A field engineer sees:

text
DI_23 = 1
AI_04 = 3.21
AxisFlag = 0x1008

But no one knows whether this is good or bad.

Why it happens ​

Diagnostics expose implementation details, not domain meaning.

Prevention ​

Map raw values to machine semantics:

text
DI_23 → Load port door closed sensor
AI_04 → Vacuum pressure sensor
AxisFlag → Servo enabled, homed, no active fault

Show expected ranges and timestamps.

6. Manual action fixes symptom but leaves workflow state inconsistent ​

What it looks like ​

Engineer manually moves a wafer stage back to home position. Physically it looks correct.

But workflow still thinks the stage is at inspection position.

Why it happens ​

Physical state and software workflow state were not reconciled.

Prevention ​

Recovery actions should include state reconciliation:

text
Manual move complete.
Do you want to mark StagePosition as ServiceHome?
Require verification before workflow resumes.

Better: force a recovery workflow instead of allowing arbitrary resume.

7. Engineering command not logged ​

What it looks like ​

A machine fails later. Logs show nothing unusual.

But someone manually reset a controller or toggled an output earlier.

Why it happens ​

Service commands were considered “debug actions” and not audited.

Prevention ​

Every service action should be logged:

text
Timestamp
User
Mode
Command
Parameters
Validation result
Execution result
Device response
Related alarm/workflow state

This is not bureaucracy. It is root-cause survival.

PART 8 — Software Design Implications ​

The service/manual UI must be a controlled interface, not a shortcut.

Bad architecture ​

text
+-------------+
| Service UI  |
+------+------+
       |
       v
+-------------+
| Device SDK  |
+-------------+

This is risky because the UI bypasses:

text
machine state
interlocks
mode rules
ownership
logging
workflow consistency

Good architecture ​

text
+----------------------+
| Service / Manual UI  |
+----------+-----------+
           |
           v
+-------------------------------+
| Command Gateway               |
| + Safety Validation           |
| + Mode Validation             |
| + Ownership Checks            |
| + Audit Logging               |
+----------+--------------------+
           |
           v
+-------------------------------+
| Machine Controller / Subsystem|
| Owns state and behavior       |
+----------+--------------------+
           |
           v
+-------------------------------+
| Device Layer                  |
| Motion / IO / Camera / Vacuum |
+----------+--------------------+
           |
           v
+-------------------------------+
| Diagnostics / Audit Trail     |
| Logs, events, traces, metrics |
+-------------------------------+

Key design rules ​

Service UI should:

  • show current machine state before action
  • use the same command gateway as production commands
  • add service-only commands, not unsafe bypasses
  • respect mode and interlock rules
  • check subsystem/resource ownership
  • log every meaningful action
  • provide guided recovery where possible
  • clearly separate production UI from service UI
  • never call hardware directly from button handlers

Example command object ​

csharp
public sealed record JogAxisCommand(
    string AxisName,
    double DistanceMm,
    double SpeedMmPerSec,
    string RequestedBy,
    string Reason);

Example validation mindset ​

csharp
public async Task<CommandResult> HandleAsync(JogAxisCommand command)
{
    if (!_machineMode.IsServiceMode)
        return CommandResult.Rejected("Jog is only allowed in Service Mode.");

    if (!_interlocks.CanMoveAxis(command.AxisName))
        return CommandResult.Rejected("Axis movement blocked by active interlock.");

    if (!_ownership.CanAcquire(command.AxisName, owner: "ServiceManualControl"))
        return CommandResult.Rejected("Axis is currently owned by another workflow.");

    if (!_limits.IsJogWithinSoftLimits(command.AxisName, command.DistanceMm))
        return CommandResult.Rejected("Jog target exceeds soft limits.");

    await _audit.LogRequested(command);

    var result = await _motionController.JogAsync(
        command.AxisName,
        command.DistanceMm,
        command.SpeedMmPerSec);

    await _audit.LogCompleted(command, result);

    return result;
}

The important point is not the exact C# code. The important point is the boundary:

The UI requests. The command layer validates. The machine controller executes. The device layer talks to hardware.

PART 9 — Interview / Real-World Talking Points ​

How to explain service/manual interfaces clearly ​

You can say:

In an industrial HMI, the service interface exposes lower-level machine controls for commissioning, troubleshooting, calibration, and recovery. But it should not bypass the machine architecture. Manual commands still need mode checks, interlock validation, resource ownership, state consistency, and audit logging.

Why service mode is not a safety bypass ​

Strong answer:

Service mode changes the allowed command set, but it does not remove safety rules. It may allow controlled manual actions, but those actions still need to respect interlocks, machine state, limits, and ownership. Otherwise, service mode becomes a hidden unsafe path through the system.

Common mistakes software engineers make ​

The most common mistake is treating service screens like developer debug panels.

Bad assumptions:

text
“It is only for engineers.”
“It is okay if it calls the device directly.”
“It is fine if it is not logged.”
“Manual mode means we can ignore workflow state.”
“Interlocks are handled somewhere else.”

In real machines, these assumptions cause unsafe movement, damaged parts, inconsistent workflow state, and impossible root-cause analysis.

What strong engineers understand ​

Strong engineers understand that service UI is part of the machine control system.

They design it with:

text
controlled commands
clear mode boundaries
safe enablement
interlock awareness
resource ownership
guided recovery
diagnostic context
audit trails
state reconciliation

A good summary:

The best service UI gives engineers power without giving them uncontrolled power.

Or more practically:

Every manual action should answer five questions: Is it allowed now? Is it safe now? Who owns the resource? What state changes afterward? Can we trace what happened later?

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype