LCN Wafer Inspection

Appearance

Below is a production-grade explanation aligned with your roadmap topic: Safe stop / emergency stop coordination and Emergency stop interaction points.

Emergency Stop & Safety-Critical Handling ​

Big Picture ​

An Emergency Stop is not a “software stop button.”

It is a safety-critical physical intervention designed to remove or inhibit hazardous machine energy as quickly and reliably as required by the machine design.

In a real industrial machine, when the operator presses an E-stop:

text
Operator presses E-stop
        ↓
Safety circuit opens
        ↓
Safety relay / Safety PLC / Drive STO reacts
        ↓
Drive enable / motion power / hazardous output is removed
        ↓
Machine enters a safety-stopped condition

The most important architectural point is this:

Safety hardware should make the machine safe even if the application software is frozen, crashed, delayed, or wrong.

Application software participates in the response, but it should not be the only thing protecting the machine.

Part 1 — What Emergency Stop Really Means ​

An emergency stop is a safety mechanism, not a normal operational command.

In normal software, when you call:

text
StopWorkflow()
StopAxis()
AbortInspection()

you expect the application, workflow engine, motion controller, and devices to cooperate.

But E-stop is different.

When E-stop is pressed, the safety system may immediately remove drive enable, disable outputs, cut motion power, or activate drive safety functions such as STO.

The application may only discover the result afterward:

text
Motion command failed
Drive disabled
Safety circuit open
Controller reports safety stop active
Axis no longer powered

That means software must treat E-stop as a safety-critical state transition, not as a failed command.

Example in a wafer inspection machine:

text
Normal operation:
- wafer stage is moving to inspection position
- camera is waiting for trigger
- autofocus Z axis is adjusting height
- workflow is executing recipe step 12

Operator presses E-stop:
- safety circuit opens
- stage drive is disabled
- Z axis may lose servo power
- motion command is interrupted
- workflow step 12 is no longer trustworthy
- software must not continue as if it simply paused

Part 2 — Emergency Stop vs Stop / Abort / Pause ​

These words sound similar, but architecturally they are very different.

text
+----------------+------------------------------+-----------------------------+
| Action         | Meaning                      | Typical Recovery            |
+----------------+------------------------------+-----------------------------+
| Pause          | Temporary controlled hold     | Resume may be allowed       |
| Stop           | Controlled stop at boundary   | Restart from known state    |
| Abort          | Interrupt current operation   | Cleanup / reset workflow    |
| Emergency Stop | Safety-critical intervention  | Safety reset + revalidate   |
+----------------+------------------------------+-----------------------------+

A better mental model:

text
Pause
  = "Hold this operation safely, but keep context valid."

Stop
  = "End operation in a controlled way."

Abort
  = "Terminate operation now and clean up."

Emergency Stop
  = "Safety system has interrupted hazardous behavior.
     Software state is no longer fully trustworthy."

The common mistake is treating E-stop like this:

text
E-stop released → clear alarm → resume workflow

That is dangerous because physical reality may have changed.

After E-stop:

  • axes may have lost power
  • position may be uncertain
  • clamps may have released
  • vacuum may have dropped
  • wafer/material may have shifted
  • workflow step may be half-completed
  • device command state may be stale
  • software may not know exactly what happened physically

So E-stop recovery is not “resume.” It is reset, revalidate, then decide.

Part 3 — Software Responsibility During E-stop ​

Software should do several things immediately when it observes an E-stop or safety-critical state.

Software should detect and model it ​

The application should have explicit safety state inputs:

text
SafetyCircuitOpen
EmergencyStopActive
MotionPowerDisabled
DriveSafetyStopActive
SafetyResetRequired

It should not only see:

text
AxisError
CommandTimeout
DeviceNotReady

Those are symptoms. The root condition may be safety-related.

Software should stop issuing new commands ​

There should be a central command gate:

text
UI Button
   ↓
Workflow
   ↓
Command Gateway
   ↓
Device / Motion Controller

During E-stop, the command gateway should reject dangerous commands:

text
MoveAxis
StartInspection
EnableLaser
StartRobotTransfer
OpenProcessSequence

The key is centralization.

Do not rely on every screen, workflow, or developer remembering to check E-stop manually.

Software should invalidate active workflow context ​

If the workflow was running, its state may no longer be valid.

Bad model:

text
WorkflowState = Paused
CurrentStep = MoveToInspectionPosition
CanResume = true

Better model:

text
WorkflowState = InvalidatedBySafetyStop
CurrentStep = UnknownCompletion
RecoveryRequired = true
CanResume = false until validation completes

Software should preserve diagnostic evidence ​

Before reset clears evidence, capture:

text
timestamp
active workflow
active recipe
current step
active command
axis positions
drive states
IO snapshot
safety input states
alarms before/after E-stop
operator action if known

This matters because after recovery, many symptoms disappear.

Part 4 — Safety Hardware vs Application Software Boundary ​

This boundary is one of the most important architectural ideas in industrial software.

text
+------------------------------------------------------+
|                  SAFETY HARDWARE                     |
|                                                      |
|  Operator E-Stop Button                              |
|          ↓                                           |
|  Safety Relay / Safety PLC / Drive STO               |
|          ↓                                           |
|  Physically disables hazardous action                |
|          ↓                                           |
|  Motors / drives / actuators / hazardous outputs     |
+------------------------------------------------------+

                         ↑ observes

+------------------------------------------------------+
|                APPLICATION SOFTWARE                  |
|                                                      |
|  Safety State Monitor                                |
|          ↓                                           |
|  Machine State Manager                               |
|          ↓                                           |
|  Command Blocking / Workflow Invalidation            |
|          ↓                                           |
|  Operator Guidance / Recovery Procedure              |
|          ↓                                           |
|  Event History / Diagnostics                         |
+------------------------------------------------------+

Safety hardware owns:

text
Immediate hazardous-energy control

Application software owns:

text
Coordination
State correctness
Command blocking
Workflow invalidation
Operator guidance
Recovery flow
Traceability

A strong software architect does not say:

“The software stops the machine safely.”

A stronger answer is:

“The safety circuit removes or inhibits hazardous energy independently. The application observes the safety state, blocks further commands, invalidates unsafe assumptions, records evidence, and guides explicit recovery.”

Part 5 — State Model After E-stop ​

After E-stop, the machine is not simply:

text
Stopped

That is too vague.

A better model includes safety-specific states:

text
EmergencyStopActive
SafetyCircuitOpen
MotionPowerDisabled
SafetyResetRequired
UnknownPosition
WorkflowInvalidated
RecoveryRequired
ReadyAfterValidation

State diagram:

text
+---------+
| Running |
+----+----+
     |
     | E-stop pressed / safety circuit opens
     v
+-------------------+
| EmergencyStopActive|
+----+--------------+
     |
     | E-stop released + safety reset
     v
+-------------------+
| SafetyReset       |
| Not Ready Yet     |
+----+--------------+
     |
     | Revalidate machine state
     v
+-------------------+
| Revalidating      |
+----+--------------+
     |
     +----------------------+
     |                      |
     v                      v
+-----------+        +------------------+
| Ready     |        | RecoveryRequired |
+-----------+        +------------------+

Important distinction:

text
Safety reset != machine ready

Safety reset only means the safety circuit is no longer active.

It does not prove:

  • axes are referenced
  • material is still in place
  • workflow context is valid
  • devices are initialized
  • clamps/vacuum are correct
  • inspection can continue
  • recipe step is safely resumable

Part 6 — Recovery After Emergency Stop ​

A safe recovery flow usually looks like this:

text
+-----------------------------+
| 1. E-stop physically resolved|
+--------------+--------------+
               |
               v
+-----------------------------+
| 2. Safety circuit reset      |
+--------------+--------------+
               |
               v
+-----------------------------+
| 3. Software observes cleared |
+--------------+--------------+
               |
               v
+-----------------------------+
| 4. Machine remains Not Ready |
+--------------+--------------+
               |
               v
+-----------------------------+
| 5. Re-enable / reconnect     |
|    affected devices          |
+--------------+--------------+
               |
               v
+-----------------------------+
| 6. Revalidate physical state |
|    axes / IO / part / vacuum |
+--------------+--------------+
               |
               v
+-----------------------------+
| 7. Decide recovery path      |
|    Resume / Abort / Manual   |
+--------------+--------------+
               |
               v
+-----------------------------+
| 8. Operator confirms action  |
+-----------------------------+

The recovery must be explicit because E-stop creates uncertainty.

A good recovery design asks:

text
Do we still know where the axes are?
Is the part still present?
Is vacuum still valid?
Are clamps still engaged?
Did the workflow step complete?
Did any command fail halfway?
Are devices still connected?
Is homing required?
Is manual intervention required?

Automatic resume is usually unsafe because the software may be resuming from a fantasy version of the machine.

Part 7 — Real-World Failure Scenarios ​

1. UI shows Idle after E-stop, but drives are disabled ​

What it looks like:

text
Operator sees "Idle"
Clicks Start
Machine does nothing
Motion commands fail
Technician sees drive disabled

Why it happens:

text
Software mapped E-stop to normal Stop.
MachineState = Idle was used too broadly.

How experienced engineers prevent it:

text
Use explicit states:
- EmergencyStopActive
- MotionPowerDisabled
- RecoveryRequired

Never show normal Idle when safety reset or revalidation is still required.

2. Software resumes workflow after E-stop without revalidation ​

What it looks like:

text
Workflow continues from step 37.
Axis position is assumed correct.
Camera captures wrong location.
Wafer alignment is wrong.
Material may be damaged or inspection result becomes invalid.

Why it happens:

text
Workflow engine treated E-stop as Pause.
CurrentStep was preserved without invalidation.

Prevention:

text
E-stop invalidates active workflow context.
Resume requires explicit validation rules.
Some workflows must always abort after E-stop.

3. E-stop clears physically, but application remains stuck ​

What it looks like:

text
Safety relay reset is done.
Drives are ready.
But app still says "E-stop active."
Operator cannot continue.

Why it happens:

text
Software missed safety-state transition.
Polling/cache/state synchronization is weak.
No clear reset path exists in state machine.

Prevention:

text
Safety state monitor should reconcile live IO/controller state.
Recovery state machine should support clear transitions:
Active → ClearedButNotReady → Revalidating → Ready.

4. App clears alarm, but safety circuit is still open ​

What it looks like:

text
Operator clicks Clear Alarm.
UI looks clean.
Start still fails.
Technician later discovers guard/E-stop circuit open.

Why it happens:

text
Alarm clearing was confused with condition clearing.
UI alarm state was not tied to live safety state.

Prevention:

text
Alarms can be acknowledged, but safety conditions remain active until live inputs prove they are cleared.

5. Active command times out and is misclassified as device failure ​

What it looks like:

text
Move command times out.
System reports "Motion controller error."
But real cause was E-stop during motion.

Why it happens:

text
Command timeout logic did not check safety state.

Prevention:

text
When a command fails, classify using surrounding context:
- Was safety circuit opened?
- Was drive enable removed?
- Was controller safety stop active?
- Was motion power disabled?

6. Position is trusted after drive power loss ​

What it looks like:

text
Software says X = 120.000 mm.
Drive lost power during E-stop.
After reset, motion continues from assumed position.
Physical position is no longer guaranteed.

Why it happens:

text
Software cached position was treated as physical truth.

Prevention:

text
After drive disable, mark axis position confidence:
- Known
- LastKnownButUnverified
- UnknownRequiresHoming
- KnownAfterControllerValidation

7. Operator thinks Stop and E-stop are equivalent ​

What it looks like:

text
Operator presses E-stop to stop normal production.
Machine recovery takes longer.
Workflow is invalidated.
Service team gets unnecessary downtime.

Why it happens:

text
HMI and training did not distinguish operational stop from emergency stop.

Prevention:

text
Make normal Stop visible and reliable.
Make E-stop recovery clearly different.
Teach that E-stop is for unsafe or urgent conditions, not normal stopping.

8. Diagnostic evidence is lost during reset ​

What it looks like:

text
After reset, all statuses look normal.
Nobody knows what command was active when E-stop happened.
Root cause cannot be reconstructed.

Why it happens:

text
The system cleared volatile state before recording the event.

Prevention:

text
On safety event, immediately snapshot:
- workflow
- command
- IO
- device states
- axis states
- alarms
- operator/session context

Part 8 — Software Design Implications ​

Emergency stop handling must be a first-class architecture path, not an exception bolted onto normal stop logic.

Component diagram:

text
+--------------------+
| Safety State Input |
| E-stop / STO / IO  |
+---------+----------+
          |
          v
+----------------------+
| Safety State Monitor |
+---------+------------+
          |
          v
+-----------------------+
| Machine State Manager |
+---------+-------------+
          |
          +--------------------------+
          |                          |
          v                          v
+------------------+        +------------------+
| Command Gateway  |        | Workflow Manager |
| Blocks commands  |        | Invalidates run  |
+------------------+        +------------------+
          |
          v
+------------------+
| HMI Guidance     |
| Recovery steps   |
+------------------+
          |
          v
+------------------+
| Recovery         |
| Procedure        |
+------------------+

Bad approach:

text
E-stop = Stop
Clear alarm = Ready
Last software position = physical truth
Resume workflow automatically

Good approach:

text
E-stop = safety-critical state
Block unsafe commands centrally
Invalidate active workflow
Mark physical assumptions uncertain
Require safety reset
Require revalidation
Guide recovery explicitly
Record traceable event history

A useful command guard model:

csharp
public sealed class CommandGateway
{
    private readonly ISafetyStateProvider _safety;
    private readonly IMachineStateProvider _machine;

    public async Task ExecuteAsync(IMachineCommand command, CancellationToken ct)
    {
        var safety = _safety.Current;
        var machine = _machine.Current;

        if (safety.EmergencyStopActive ||
            safety.SafetyCircuitOpen ||
            machine.RecoveryRequired)
        {
            throw new CommandRejectedException(
                command.Name,
                "Command rejected because machine is in safety-stopped or recovery-required state.");
        }

        await command.ExecuteAsync(ct);
    }
}

The point is not this exact code.

The point is architectural:

Safety-related command blocking should be centralized and state-driven.

Part 9 — Interview / Real-World Talking Points ​

A strong interview answer:

“I do not treat emergency stop as a normal software stop. E-stop is handled primarily by safety hardware such as a safety relay, safety PLC, or drive safety function. The application observes the safety state and reacts by blocking commands, invalidating active workflows, recording diagnostics, and guiding recovery. After E-stop is reset, the machine is not automatically ready. The software must revalidate physical state such as axis position, IO, material presence, vacuum, clamps, and device readiness before allowing resume or restart.”

Common mistakes software engineers make when entering industrial systems:

text
1. Thinking E-stop is just another button event.
2. Modeling E-stop as Stop or Pause.
3. Assuming software controls all safety behavior.
4. Trusting cached software state after power/drive loss.
5. Allowing automatic resume after safety reset.
6. Clearing UI alarms without checking live safety state.
7. Forgetting to preserve diagnostic evidence.
8. Scattering safety checks across UI screens instead of centralizing command gating.

The strongest mental model:

text
Safety hardware makes the machine safe.
Software makes the system understandable, recoverable, and hard to misuse.

Or even shorter:

text
E-stop protects people and equipment.
Software protects correctness after the event.

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype