LCN Wafer Inspection

Appearance

Below is a principal-level explanation aligned to your project source of truth, especially the emphasis on sequencing, deterministic workflow execution, start/stop/pause/resume/abort semantics, orchestration patterns, and separation of UI, workflow, and device logic.

Application Orchestration & Control Flow ​

PART 1 — WHAT “ORCHESTRATION” MEANS IN MACHINE SOFTWARE ​

In industrial machine software, orchestration means coordinating multiple subsystems so the machine achieves a meaningful operational goal safely and predictably.

That sounds abstract, so here is the practical version:

A machine almost never does useful work by talking to one device once.

Real work looks more like:

  • verify machine mode
  • confirm safety conditions
  • make sure required devices are ready
  • move hardware to the correct position
  • wait for motion completion
  • arm triggers
  • capture data
  • run analysis
  • update workflow state
  • decide what to do next
  • handle interruptions or failures at any point

That coordinating logic is orchestration.

The roadmap already points in this direction through topics like machine sequence control, recipe-driven operation, start / stop / pause / resume / abort semantics, orchestrator patterns, command / event driven design, and session / run / recipe execution models.

Orchestration vs direct control ​

Direct control is when code calls a specific subsystem or device API.

Example:

  • motionAxis.MoveAbsolute(125.0)
  • camera.StartAcquisition()
  • lightController.SetIntensity(80)

These are direct actions.

Orchestration is when the application coordinates many such actions into a controlled flow.

Example: inspection sequence

  • ensure wafer loaded
  • ensure vacuum is on
  • move XY stage to target
  • wait until in-position
  • adjust focus
  • trigger camera
  • wait for image
  • send image to analysis
  • interpret result
  • record defect
  • continue to next site or stop on failure

That is not device logic. That is application-level coordination.

Why “conductor” is the right mental model ​

The application layer is like a conductor in an orchestra.

  • motion subsystem knows how to move
  • camera subsystem knows how to acquire
  • analysis subsystem knows how to process
  • safety subsystem knows current permissives/interlocks
  • recipe subsystem knows parameters
  • UI shows status and sends operator intent

But none of those alone knows the full machine intent.

The orchestrator is the component that says:

  • what should happen next
  • under what conditions
  • in what order
  • what to wait for
  • what to do if something goes wrong
  • whether the workflow may continue

Example 1: inspection sequence ​

A wafer inspection step may coordinate:

  • motion
  • autofocus
  • lighting
  • camera
  • image pipeline
  • result storage
  • alarm handling

No single subsystem should own that whole sequence.

Example 2: pick-and-place cycle ​

A robot handling cycle may coordinate:

  • input sensor check
  • clamp state
  • robot move to pick position
  • vacuum on
  • part-present confirmation
  • robot move to place position
  • vacuum off
  • place verification
  • error branch if confirmation fails

Again, this is orchestration, not “just robot control.”

PART 2 — CONTROL FLOW ACROSS SUBSYSTEMS ​

In a well-structured machine application, control flow usually moves like this:

UI → Application Orchestrator → Subsystems → Devices

The important point is that the flow is not only downward. Results, completion signals, faults, and events flow back upward.

Typical control path ​

  1. Operator starts a run from the UI.
  2. Application orchestrator validates prerequisites.
  3. Orchestrator issues commands to motion, vision, IO, safety-aware services.
  4. Subsystems translate those commands into device operations.
  5. Devices execute asynchronously.
  6. Completion, feedback, or faults return as events/status.
  7. Orchestrator decides next action.

Why this must be explicit ​

In business software, control flow can sometimes be loose and still be acceptable.

In machine software, implicit control flow becomes dangerous because:

  • actions take time
  • the physical world changes during waiting
  • events can arrive unexpectedly
  • devices may partially succeed
  • operators may interrupt mid-step
  • incorrect ordering can cause collisions, bad measurements, or hangs

So the control flow must be:

  • explicit
  • observable
  • deterministic
  • interruption-aware

Sequence diagram ​

text
Operator/UI        Orchestrator        SafetySvc       MotionSvc        CameraSvc       AnalysisSvc
    |                   |                  |               |                |                |
    | Start Run         |                  |               |                |                |
    |------------------>|                  |               |                |                |
    |                   | Check permissives|               |                |                |
    |                   |----------------->|               |                |                |
    |                   |<-----------------| SafeToRun     |                |                |
    |                   | Command move                     |                |                |
    |                   |--------------------------------->|                |                |
    |                   |<---------------------------------| InMotion       |                |
    |                   | wait for settle                  |                |                |
    |                   |<---------------------------------| InPosition     |                |
    |                   | Trigger capture                                   |                |
    |                   |-------------------------------------------------->|                |
    |                   |<--------------------------------------------------| ImageReady     |
    |                   | Send image                                                          |
    |                   |-------------------------------------------------------------------->|
    |                   |<--------------------------------------------------------------------| ResultReady
    |                   | Update run state               |                |                |
    |<------------------| Progress / status              |                |                |

What this diagram shows ​

The orchestrator does not “do motion” or “do imaging” itself.

It:

  • checks whether the run may proceed
  • tells subsystems what to do
  • waits for meaningful completion
  • reacts to the returned state/events
  • advances the workflow only when conditions are satisfied

That is the essence of application-level coordination.

PART 3 — ORCHESTRATION VS BUSINESS LOGIC VS DEVICE LOGIC ​

A lot of machine systems become fragile because these three get mixed together.

1. Domain model responsibilities ​

The domain model should represent machine concepts and rules, for example:

  • run
  • recipe
  • wafer
  • inspection site
  • subsystem readiness
  • allowed modes
  • operational constraints
  • workflow intent at a conceptual level

It answers questions like:

  • what is a run
  • what is a valid recipe
  • what states are meaningful
  • what conditions must hold before a step may begin

It should not be full of device calls.

2. Orchestration layer responsibilities ​

The orchestration layer owns:

  • sequencing
  • coordination across subsystems
  • waiting for completion/events
  • timeout/failure paths
  • interruption handling
  • run-level progress
  • cross-subsystem decisions

It answers questions like:

  • what happens next
  • when do we continue
  • which subsystem should be called now
  • what do we do if one part succeeds and another fails

3. Device layer responsibilities ​

The device/subsystem layer owns:

  • communicating with hardware
  • managing low-level device state
  • translating device API details
  • exposing meaningful commands/status
  • shielding vendor SDK quirks from the application

It answers questions like:

  • how to move the axis
  • how to subscribe to the camera frame callback
  • how to reconnect the controller
  • how to expose MoveCompleted safely

Why mixing them is dangerous ​

When orchestration leaks into UI:

  • control flow gets scattered across button handlers
  • pause/abort behavior becomes inconsistent
  • status changes depend on view timing

When orchestration leaks into device services:

  • a motion service starts deciding inspection workflow
  • subsystems become tightly coupled
  • reuse becomes hard
  • fault paths become hidden

When domain rules leak into device code:

  • configuration and machine intent become buried in hardware adapters
  • changing workflow behavior requires device-layer edits
  • debugging becomes cross-layer archaeology

Good mental model ​

  • Domain model = what the machine conceptually is
  • Orchestrator = how the machine conducts a task
  • Device layer = how the machine talks to physical components

PART 4 — HANDLING ASYNCHRONOUS OPERATIONS ​

Industrial orchestration is inherently asynchronous because physical operations take time. Your source-of-truth material already emphasizes that machine operations are long-running, asynchronous, timing-sensitive, and command → execution → completion driven.

A software call is not the operation.

Calling:

text
MoveTo(siteX, siteY)

does not mean the stage is already there.

It means:

  • command accepted
  • motion begins later or immediately
  • motion progresses over time
  • motion eventually completes, faults, or times out

That gap is where orchestration lives.

What the orchestrator must do ​

For every long-running action, it usually must:

  • issue a command
  • track that the operation started
  • wait for completion or meaningful status
  • monitor timeouts
  • handle cancellation or abort
  • verify resulting state before continuing

Why async is not optional ​

You cannot safely write industrial orchestration as if everything were synchronous request/response code, because:

  • physical devices do not complete instantly
  • some operations are event-driven
  • some devices acknowledge before actual completion
  • callbacks may arrive on arbitrary threads
  • multiple operations may overlap
  • UI must remain responsive
  • interrupts can arrive while waiting

A common mistake ​

A weak design says:

text
Move stage
Sleep 500 ms
Trigger camera

That is not orchestration. That is hope.

A stronger design says:

text
Command move
Wait for in-position confirmation
Verify no fault and not aborted
Then trigger camera

Another common mistake ​

Treating “command sent successfully” as “operation succeeded.”

In machine systems, these are different states:

  • command accepted
  • operation started
  • operation completed
  • operation completed within tolerance
  • operation completed and system still safe to continue

The orchestrator must care about those distinctions.

PART 5 — COORDINATING STATE, EVENTS, AND COMMANDS ​

At application level, orchestration is basically the controlled interaction of three things:

  • current state
  • incoming events
  • outgoing commands

State ​

Examples:

  • machine mode = Auto
  • run state = InspectingSite42
  • motion state = Moving
  • camera state = Armed
  • safety state = DoorClosed
  • pause requested = false
  • abort requested = false

Events ​

Examples:

  • motion completed
  • camera frame received
  • vacuum lost
  • timeout expired
  • analysis finished
  • operator pressed pause
  • subsystem faulted

Commands ​

Examples:

  • move stage
  • turn on vacuum
  • trigger camera
  • save result
  • stop sequence
  • enter alarm state

The orchestrator consumes events in the context of current state and decides which command to emit next.

Control-flow diagram ​

text
                +----------------------+
                | Current Run State    |
                | mode, step, flags,   |
                | subsystem readiness  |
                +----------+-----------+
                           |
                           v
                 +---------+----------+
                 | Incoming Event     |
                 | completion/fault/  |
                 | operator command   |
                 +---------+----------+
                           |
                           v
                 +---------+----------+
                 | Orchestration      |
                 | Decision Logic     |
                 |                    |
                 | - is event valid?  |
                 | - still same step? |
                 | - paused/aborted?  |
                 | - timeout/fault?   |
                 +----+----------+----+
                      |          |
            continue  |          | fail/interrupt
                      v          v
           +----------+--+   +---+----------------+
           | Issue Next   |   | Stop / Alarm /    |
           | Command      |   | Recovery Path     |
           +------------- +   +-------------------+

What strong engineers understand ​

An event is never meaningful by itself.

“MotionComplete” means different things depending on context:

  • expected completion for current step
  • stale completion from previous attempt
  • completion after abort request
  • completion after timeout already declared
  • completion for wrong axis or wrong correlation id

So orchestration must interpret events against workflow state, not just react blindly.

PART 6 — INTERRUPTION & CONTROL COMMANDS ​

This is where orchestration gets truly hard.

Real machines must handle:

  • start
  • stop
  • pause
  • resume
  • abort

These are not just UI commands. They are system-level control semantics.

Start ​

Start usually means:

  • validate machine mode
  • validate recipe
  • confirm subsystem readiness
  • allocate run/session context
  • begin first orchestrated step

Stop ​

Stop often means:

  • finish current safe boundary
  • prevent new work from starting
  • transition to controlled idle or stop state

This is usually graceful.

Pause ​

Pause usually means:

  • stop advancing workflow at a safe point
  • preserve state needed for resume
  • keep machine in a safe held condition

Pause is difficult because not every moment is pausable.

Resume ​

Resume means:

  • verify saved context is still valid
  • verify machine still satisfies prerequisites
  • continue from the correct boundary, not from a guessed one

Abort ​

Abort is the harshest control action.

It usually means:

  • stop as soon as safely possible
  • cancel pending waits
  • suppress further workflow advancement
  • move system toward known safe state
  • mark run as incomplete/aborted

Why interruption handling is complex ​

Because an interrupt can arrive:

  • before a command is sent
  • after a command is sent but before acknowledgment
  • while waiting for completion
  • after physical completion but before event processing
  • during fault handling
  • during partial recovery

That creates many edge cases.

Example ​

Suppose the sequence is:

  1. move stage
  2. wait for in-position
  3. trigger camera

Now pause arrives after the move completed physically, but before the in-position event is processed by the orchestrator.

What is the correct result?

Possible wrong answers:

  • continue and capture image anyway
  • lose the completion event and hang
  • pause too late but report paused
  • mark workflow paused while camera still triggers

Good orchestration handles these edge timings explicitly.

PART 7 — REAL-WORLD FAILURE SCENARIOS ​

1. Orchestration continues before subsystem ready ​

What it looks like ​

  • run starts immediately after startup
  • motion is commanded before homing completed
  • capture starts before camera is armed
  • wafer transfer begins before vacuum stable

Why it happens ​

  • readiness treated as a boolean set too early
  • no explicit startup gating
  • asynchronous initialization not awaited correctly
  • subsystem exposes “connected” but not “operationally ready”

How engineers debug it ​

They compare:

  • startup timeline
  • subsystem readiness transitions
  • first workflow commands
  • whether orchestration used the right readiness condition

Often the bug is not device failure. It is orchestration using the wrong definition of ready.

2. Missed event causes workflow to hang ​

What it looks like ​

  • stage moved physically
  • software stays stuck on “waiting for motion complete”
  • operator says “machine already finished the move”

Why it happens ​

  • event subscription attached too late
  • event fired before waiting logic armed
  • callback thread deadlocked or blocked
  • stale state caused event to be ignored

How engineers debug it ​

They inspect:

  • command time
  • event publication time
  • event subscription lifecycle
  • thread/queue traces
  • correlation between command and completion

A classic orchestration lesson: if waiting is not carefully designed, the workflow can miss reality.

3. Race between event and command ​

What it looks like ​

  • stop or abort pressed
  • one more motion or capture still happens
  • duplicate transition occurs
  • system enters impossible combination of states

Why it happens ​

  • no serialized orchestration context
  • event processing and command issuance occur concurrently
  • shared flags updated without clear ownership
  • operator control commands bypass orchestrator and talk directly to services

How engineers debug it ​

They reconstruct precise ordering:

  • when operator action was received
  • when command was emitted
  • when callback arrived
  • which thread changed workflow state
  • whether orchestration decisions were serialized

This is why centralized orchestration matters.

4. Partial completion leaves system inconsistent ​

What it looks like ​

  • motion succeeded, image save failed
  • wafer picked but not placed
  • result recorded but run state not advanced
  • subsystem one reset, subsystem two not reset

Why it happens ​

  • sequence assumed all-or-nothing behavior
  • no explicit compensation or recovery path
  • no persisted workflow checkpoint
  • failure handling designed only for full success or full failure

How engineers debug it ​

They ask:

  • what exactly completed
  • what side effects already happened
  • what state was persisted
  • what step the orchestrator thought it was in
  • what the physical machine state actually was

In machine systems, partial completion is normal, not exceptional.

5. Retry logic causes duplicate actions ​

What it looks like ​

  • same site inspected twice
  • robot retries pick after pick already succeeded
  • result saved twice
  • motion resent to already-reached position, causing unexpected extra settling

Why it happens ​

  • retry built at wrong layer
  • timeout mistaken for guaranteed failure
  • command idempotency not considered
  • orchestrator does not know whether the first attempt actually took effect

How engineers debug it ​

They trace:

  • original command
  • timeout point
  • device-side actual behavior
  • whether completion came late
  • whether retry logic was state-aware

Good engineers learn that retry in machine software is not a generic utility feature. It is a semantic decision.

PART 8 — SOFTWARE DESIGN IMPLICATIONS ​

The roadmap explicitly highlights orchestrator patterns, stateful components, command/event-driven design, separation of UI/workflow/device logic, and long-lived process architecture. Those are exactly the design implications of this topic.

Why orchestration should be centralized and explicit ​

Because the system needs one place that clearly answers:

  • what operation is in progress
  • what step is next
  • what conditions gate progress
  • what interrupts are pending
  • which events matter right now
  • what recovery path applies

If those answers are scattered, the machine becomes unpredictable.

Bad approach ​

text
UI button handler calls MotionService
MotionService directly triggers CameraService
Camera callback updates ViewModel
ViewModel decides next workflow step
AlarmService interrupts some services directly
Background timer retries things on its own

This creates:

  • hidden control flow
  • duplicated decisions
  • inconsistent interruption handling
  • race conditions
  • impossible debugging

Good approach ​

text
UI sends operator intent to Orchestrator
Orchestrator owns workflow progression
Subsystems expose commands + events/status
Device adapters stay below subsystem boundary
UI only displays state and sends intent

This gives:

  • single place to reason about control flow
  • clear interruption semantics
  • testable workflow behavior
  • diagnosable event timelines
  • safer evolution over time

Component diagram ​

text
+-------------------+
| UI / HMI          |
| - operator intent |
| - status display  |
+---------+---------+
          |
          v
+---------+----------------------------------+
| Application Orchestration Layer            |
|                                            |
| - run/session controller                   |
| - workflow coordinator                     |
| - interruption handling                    |
| - timeout/fault coordination               |
| - command/event decision logic             |
+----+---------------+---------------+-------+
     |               |               |
     v               v               v
+----+-----+   +-----+-----+   +-----+------+
| MotionSvc |   | VisionSvc |   | SafetySvc  |
| IO/Robot  |   | Analysis  |   | RecipeSvc  |
| subsystem |   | subsystem |   | etc.       |
+----+-----+   +-----+-----+   +-----+------+
     |               |               |
     v               v               v
+----+-----+   +-----+-----+   +-----+------+
| Device    |   | Device    |   | Device     |
| Adapters  |   | Adapters  |   | Adapters   |
| SDK/PLC   |   | SDK/DLL   |   | IO/fieldbus|
+---------- +   +---------- +   +----------- +

Explain the diagram ​

The orchestrator sits above subsystems and below the UI.

It is not the hardware layer. It is not the view model. It is the layer that coordinates system behavior.

That is where application-level control flow belongs.

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ​

How to explain orchestration clearly ​

A good interview answer:

In industrial machine software, orchestration is the application-level coordination of workflows across multiple subsystems. It does not directly implement device communication. It manages sequencing, waits for asynchronous completion, handles interrupts and faults, and ensures the machine progresses predictably from one safe step to the next.

Difference between orchestration and direct control ​

A crisp distinction:

  • Direct control sends a command to a specific subsystem or device.
  • Orchestration coordinates many subsystem actions into a larger machine behavior.

Example:

  • direct control = MoveAxis(X, 100)
  • orchestration = “execute inspection at site N by validating readiness, moving stage, waiting for in-position, triggering acquisition, analyzing result, recording outcome, and handling pause/abort/fault correctly at every step”

Common mistakes engineers make ​

  1. Putting orchestration in the UI Button handlers become workflow engines.

  2. Letting subsystems decide workflow Motion or camera services start owning machine sequence behavior.

  3. Treating async device calls like synchronous business calls Command accepted gets confused with operation completed.

  4. Not designing interruption semantics explicitly Pause/stop/abort are added late and become inconsistent.

  5. Reacting to events without workflow context Completion events are processed blindly.

  6. Scattering control decisions across threads/services Leads to race conditions and impossible debugging.

  7. Assuming retries are always safe Duplicate physical actions happen.

What strong engineers understand about coordination ​

Strong engineers understand that:

  • the machine is a long-running stateful system
  • orchestration is about correctness, not just structure
  • explicit flow is safer than implicit flow
  • async completion and interruption are first-class concerns
  • partial completion is normal and must be modeled
  • events must be interpreted in context
  • UI should observe orchestration, not own it
  • device layers should expose capabilities, not workflow decisions

One strong closing statement for interviews ​

In machine systems, good orchestration makes behavior understandable, predictable, and safe. Poor orchestration usually does not fail as a clean exception. It fails as hangs, duplicate actions, wrong sequencing, inconsistent recovery, or unsafe machine behavior.

Final mental model ​

If you remember only one thing, remember this:

The orchestrator is the part of the application that turns subsystem capabilities into controlled machine behavior.

It is responsible for:

  • sequencing
  • waiting
  • deciding
  • reacting
  • interrupting
  • recovering

It does not replace device logic. It does not replace domain concepts. It sits between them and coordinates the machine as a working system.

That is why it is one of the most important architectural responsibilities in industrial software. It is directly aligned with your roadmap’s emphasis on machine sequence control, deterministic workflow execution, start/stop/pause/resume/abort semantics, orchestrator patterns, command/event-driven design, and separation of UI, workflow, and device logic.

If you want, I can turn this next into a concrete .NET/WPF architecture example with interfaces like IRunOrchestrator, IMotionSubsystem, IVisionSubsystem, command/event contracts, and a sample inspection flow.

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype