Recipe & Configuration UI

Designing safe editing, validation, activation, and traceability in industrial HMIs

This topic fits your roadmap under HMI recipe editors and the broader configuration/recipe management area, where industrial systems must handle recipe-driven operation, parameter validation, loading/saving/activation, audit trails, and safe parameter changes.

---

PART 1 — Why Recipe / Configuration UI Is Risky

A recipe/configuration screen is not just a data-entry form.

In business software, editing a value may change a report, price, profile, or workflow rule. In industrial machine software, editing a value may change how the machine physically behaves.

A recipe may control:

- motion positions
- scan speed
- acceleration / deceleration
- inspection thresholds
- camera exposure
- light intensity
- autofocus behavior
- vacuum timing
- retry counts
- alignment offsets
- enable / disable flags

That means a bad value can affect quality, safety, throughput, and equipment health.

For example, in a wafer inspection machine:

Operator changes scan speed from 50 mm/s to 120 mm/s.

But exposure time, illumination intensity, trigger spacing, and image processing assumptions
were tuned for the original speed.

The machine still moves correctly.
The camera still captures images.
The UI still shows results.

But inspection quality silently degrades.

That is what makes recipe UI dangerous: the machine may appear “working” while producing unreliable results.

Another example:

Engineer changes an X/Y alignment offset while the machine is already running.

The new offset is partially applied:
- UI shows new value
- workflow still uses cached old value
- vision overlay uses new value
- motion subsystem uses old value

Now the system is internally inconsistent.

This is worse than a simple validation error because the system becomes difficult to diagnose.

A third example:

Wrong recipe activated for wafer type.

The machine runs:
- wrong illumination
- wrong inspection thresholds
- wrong die layout
- wrong reject criteria

Production data is generated, but it is tied to the wrong process assumptions.

In industrial systems, recipe/configuration UI must be treated as a controlled machine workflow, not a CRUD screen.

---

PART 2 — Recipe Editing vs Configuration Editing

Recipe editing and configuration editing look similar on the surface because both involve parameters. But they are not the same thing.

Recipe UI

Recipe parameters are usually product-specific or process-specific.

Examples:

- wafer type
- product variant
- inspection thresholds
- scan strategy
- die layout
- camera exposure for this product
- illumination profile for this inspection mode
- measurement tolerances

Recipes change more often because production may run different products, lots, or inspection modes.

Configuration UI

Configuration parameters are machine-specific, site-specific, or device-specific.

Examples:

- camera serial number
- stage travel limits
- IO mapping
- motion controller settings
- calibration constants
- device communication settings
- machine identity
- default directories
- factory network endpoint

Configuration changes less often and usually requires engineering, service, or commissioning knowledge.

Why mixing them is dangerous

A common bad design is a single generic “Settings” screen containing everything:

Settings
 ├─ Product threshold
 ├─ Camera IP address
 ├─ Motion soft limit
 ├─ Lot naming rule
 ├─ Inspection tolerance
 ├─ Vacuum timeout
 ├─ Debug flag
 └─ Calibration offset

This is dangerous because the UI gives all parameters the same visual importance, even though their risk profiles are very different.

A threshold change may affect quality.

A camera IP change may break acquisition.

A motion limit change may cause physical risk.

A calibration offset change may shift all measurements.

A debug flag may disable a behavior that production relies on.

A better mental model is:

+---------------------------+-----------------------------+
| Recipe UI                 | Configuration UI            |
+---------------------------+-----------------------------+
| Product/process-specific  | Machine/site/device-specific|
| Changed more often        | Changed less often          |
| Used for production runs  | Used for setup/service      |
| Tied to product variant   | Tied to installed machine   |
| Needs versioning          | Needs stricter control      |
| Validated against machine | Validated against hardware  |
+---------------------------+-----------------------------+

The UI should make this distinction clear.

Do not let operators feel that changing a scan threshold is the same type of action as changing a motion limit.

---

PART 3 — Editing Lifecycle

A safe recipe/configuration UI has a lifecycle.

It should not be:

Open screen → edit value → save → machine immediately uses it

That is too risky.

A better lifecycle is:

[1] Open existing recipe/config
        |
        v
[2] Edit draft values
        |
        v
[3] Validate locally
        |
        v
[4] Validate against machine constraints
        |
        v
[5] Review changes
        |
        v
[6] Approve / save version
        |
        v
[7] Activate
        |
        v
[8] Confirm machine/subsystems applied correctly

ASCII flow:

+------------------+
| Open Current     |
| Recipe / Config  |
+--------+---------+
         |
         v
+------------------+
| Edit Draft       |
| Values           |
+--------+---------+
         |
         v
+------------------+
| UI Validation    |
| ranges, units    |
+--------+---------+
         |
         v
+------------------+
| Backend / Machine|
| Validation       |
+--------+---------+
         |
         v
+------------------+
| Review Diff      |
| old vs new       |
+--------+---------+
         |
         v
+------------------+
| Save / Approve   |
| new version      |
+--------+---------+
         |
         v
+------------------+
| Activate         |
| controlled apply |
+--------+---------+
         |
         v
+------------------+
| Verify Applied   |
| feedback/audit   |
+------------------+

The important idea:

Save does not always mean active.

Saving means the edited recipe/configuration exists.

Activation means the machine is now allowed to use it.

These must be separated because activation may require:

- machine idle
- no active lot
- workflow stopped
- subsystem reload
- camera reinitialization
- motion controller update
- recalibration
- operator confirmation

In production systems, this separation prevents many subtle bugs.

---

PART 4 — Validation in the UI and Backend

UI validation is helpful, but it is not the authority.

The UI should help users avoid mistakes early:

- required fields
- obvious range errors
- invalid number format
- missing units
- immediate warning messages
- dependency hints

But the backend or domain layer must perform the real validation.

Why?

Because the UI can be bypassed, outdated, duplicated, or inconsistent. Also, some validation requires machine knowledge that the UI should not own.

Validation types

1. Required fields

Simple example:

Recipe name is required.
Inspection threshold is required.
Camera exposure must be specified.

2. Range validation

Exposure must be between 100 µs and 20,000 µs.
Scan speed must be between 1 mm/s and 200 mm/s.
Vacuum timeout must be between 100 ms and 10,000 ms.

3. Unit validation

This is critical.

1 mm != 1 µm
100 ms != 100 s
5 mm/s != 5 µm/s

Unit mistakes can create real production failures.

4. Cross-parameter dependencies

This is where recipe validation becomes industrial, not CRUD.

Example:

If scan speed increases,
then exposure time and trigger spacing must still produce valid image overlap.

Another example:

If high-resolution inspection mode is selected,
then camera binning must be disabled
and illumination profile must support that mode.

5. Hardware capability checks

The recipe may be valid as data but impossible for the installed machine.

Example:

Recipe requires 300 mm travel.
This machine stage supports only 200 mm travel.

6. Recipe/machine compatibility

A recipe created for one machine model may not be valid for another.

Recipe: WaferInspection_V2
Requires:
- camera model A
- illumination controller B
- motion profile version C

Current machine:
- camera model A
- illumination controller D
- motion profile version C

The UI should not allow silent activation.

7. Mode/state constraints

Some changes are valid only when the machine is idle.

Motion offset change:
Allowed when: Idle / Maintenance
Blocked when: Running / Paused / Recovering

This ties recipe UI back to machine state. Industrial systems should be state-driven, not call-driven.

---

PART 5 — Safe Activation Flow

Activation is the dangerous step.

Editing a draft is usually safe.

Saving a version is usually safe.

Activating a recipe/configuration may change live machine behavior.

That means activation must be explicit, controlled, and visible.

What activation should show

Before activation, the UI should clearly show:

- what changed
- previous active value
- new value
- affected subsystem
- impact level
- whether machine must be idle
- whether reload is required
- whether recalibration is required
- whether current production will be affected

Example activation preview:

Recipe: Wafer_A_Inspection_V5

Changed parameters:
+----------------------+-------------+-------------+-------------------+
| Parameter            | Old Value   | New Value   | Impact            |
+----------------------+-------------+-------------+-------------------+
| Scan Speed           | 50 mm/s     | 80 mm/s     | Acquisition timing|
| Exposure             | 1200 µs     | 800 µs      | Image brightness  |
| Defect Threshold     | 0.72        | 0.68        | Yield sensitivity |
| Alignment Offset X   | 0.000 mm    | 0.015 mm    | Motion/vision map |
+----------------------+-------------+-------------+-------------------+

Activation requirement:
- Machine must be Idle
- Vision pipeline reload required
- Existing run will not be modified

Recipe state diagram

        +---------+
        | Draft   |
        +----+----+
             |
             | validate
             v
      +------+------+
      | Validated   |
      +------+------+
             |
             | approve
             v
       +-----+-----+
       | Approved  |
       +-----+-----+
             |
             | activate
             v
        +----+----+
        | Active  |
        +----+----+
             |
             | replace / retire
             v
       +-----+------+
       | Archived   |
       +------------+

Explanation:

Draft:
Editable working copy. Not trusted for production.

Validated:
Passed UI and backend validation, but not yet approved for use.

Approved:
Accepted as a controlled version, but not necessarily active.

Active:
Currently used by the machine for execution.

Archived:
Old version kept for traceability, rollback, diagnostics, or audit.

The most important boundary is between Approved and Active.

A recipe can be approved but not active.

A recipe can be active only after machine-state checks and subsystem application succeed.

---

PART 6 — UI Clarity for Parameters

Parameter clarity is not cosmetic. It is a safety and quality concern.

A weak parameter UI shows this:

Speed: 80
Offset: 15
Threshold: 0.7
Timeout: 5
Mode: 2

This is dangerous.

A strong parameter UI shows this:

Scan Speed
Current active value: 50 mm/s
Draft value:          80 mm/s
Allowed range:        1–120 mm/s
Default value:        50 mm/s
Unit:                 millimeters per second
Impact:               Affects camera trigger timing and image overlap
Dependency:           Exposure time must remain compatible
Activation:           Requires machine idle

For each important parameter, the UI should expose:

- meaningful name
- unit
- allowed range
- default value
- current active value
- draft value
- validation status
- warning/impact message
- dependency information
- affected subsystem

Bad naming causes production errors.

For example:

Offset = 10

Better:

Wafer Alignment X Offset = 10 µm

Even better:

Wafer Alignment X Offset
Unit: µm
Positive direction: stage +X
Used by: alignment correction before inspection scan
Current active: 0 µm
Draft: +10 µm

Industrial HMI clarity must reduce interpretation. Operators and engineers should not need to guess.

---

PART 7 — Real-World Failure Scenarios

1. User edits value, but active machine still uses old cached value

What it looks like

The UI shows the new value.

The machine behaves as if nothing changed.

Operators lose trust because “the system says one thing but does another.”

Why it happens

Usually because:

- UI updates database only
- machine execution uses cached recipe
- subsystem was not reloaded
- activation step was skipped
- no confirmation from subsystem

Prevention

Use explicit activation:

Save draft/version
→ activate recipe
→ send activation command
→ subsystem applies value
→ subsystem confirms applied version
→ UI shows active version

The UI should display:

Active Recipe Version: V12
Draft Version: V13 not active
Vision subsystem applied: V12
Motion subsystem applied: V12

---

2. UI allows invalid combination of parameters

What it looks like

Each field is valid individually, but the machine fails during execution.

Example:

Scan speed is valid.
Exposure is valid.
Trigger distance is valid.

Together, they produce blurred or incomplete images.

Why it happens

Validation is field-based instead of system-based.

Prevention

Add cross-parameter validation.

ValidateRecipe(recipe, machineCapabilities, selectedMode)

Do not only validate:

speed >= min && speed <= max

Also validate:

speed + exposure + trigger interval + camera frame rate + image overlap

---

3. Units unclear: mm vs µm

What it looks like

An engineer enters:

Offset = 20

They meant 20 µm.

The system interprets 20 mm.

Why it happens

The UI stores or displays raw numbers without strong unit labeling.

Prevention

Always show units near the value.

Prefer typed unit models internally where possible.

UI should say:

Alignment Offset X: 20 µm

Not:

Offset X: 20

For high-risk parameters, require confirmation when values are unusually large.

---

4. Hidden advanced parameter affects production unexpectedly

What it looks like

Production behavior changes, but operators cannot understand why.

A hidden advanced flag changed the result:

UseAlternativeDefectClassifier = true

Why it happens

Advanced settings are treated as invisible implementation details.

Prevention

If a parameter affects production output, it must be visible in the recipe summary, diff, and audit trail.

Advanced does not mean unaudited.

---

5. Operator changes recipe during active run

What it looks like

A lot starts with one recipe version and ends with another.

Inspection results become questionable.

Why it happens

The UI allows live recipe changes without binding a recipe version to the active run.

Prevention

At run start, bind a specific recipe version:

Run ID: R2026-0426-001
Recipe: Wafer_A_Inspection
Version: V17

Changes after run start should create a new draft/version, not mutate the active run recipe.

---

6. Wrong recipe version used after edit

What it looks like

Engineer edits recipe V10 and saves V11.

Operator assumes V11 is active.

Machine still runs V10.

Why it happens

The UI does not distinguish saved version from active version.

Prevention

Make status explicit:

Saved latest version: V11
Currently active:     V10
Activation required:  Yes

Use strong visual language:

V11 is saved but NOT active.

---

7. Validation passes in UI but fails during machine execution

What it looks like

Operator clicks Start.

Machine immediately alarms:

Recipe parameter invalid for current machine state.

Why it happens

UI validation was incomplete or stale.

Backend/device validation was not run before activation.

Prevention

Run authoritative validation before activation and again before execution if needed.

UI validation:
- user friendliness

Backend validation:
- correctness authority

Machine preflight:
- current state and subsystem readiness

---

8. No audit trail

What it looks like

Production quality changes.

Nobody knows why.

The team asks:

Who changed the threshold?
When?
From what value to what value?
Was that recipe active during this lot?

No one can answer.

Why it happens

The system only stores current values.

Prevention

Every important change should record:

- who changed it
- when it changed
- old value
- new value
- reason/comment if required
- recipe/config version
- activation time
- affected run/lot if applicable

Auditability is not bureaucracy. It is how engineers debug production history.

---

PART 8 — Software Design Implications

The recipe/configuration UI must be a workflow, not a raw editor.

Bad approach

UI directly edits live values
UI writes directly to database
Machine reads whatever is latest
Validation only exists in UI
No versioning
No activation step
No audit trail
No diff preview
No machine-state checks

This is common in early prototypes and dangerous in production.

Good approach

User edits draft
System validates draft
User reviews changes
System saves controlled version
User explicitly activates version
Backend checks machine state
Subsystems apply version
System confirms activation
Audit log records everything
UI shows active/draft/version status clearly

Component diagram

+----------------------+
| Recipe Editor UI     |
| - edit draft         |
| - show diff          |
| - show validation    |
+----------+-----------+
           |
           v
+----------------------+
| Draft Model          |
| - unsaved changes    |
| - draft values       |
| - local validation   |
+----------+-----------+
           |
           v
+----------------------+
| Validation Service   |
| - ranges             |
| - units              |
| - dependencies       |
| - machine capability |
| - state constraints  |
+----------+-----------+
           |
           v
+----------------------+
| Recipe/Config Manager|
| - versions           |
| - save/approve       |
| - active tracking    |
| - compatibility      |
+----------+-----------+
           |
           v
+----------------------+
| Activation Command   |
| - explicit apply     |
| - state checks       |
| - subsystem reload   |
+----------+-----------+
           |
           v
+----------------------+
| Machine/Subsystems   |
| - motion             |
| - vision             |
| - devices            |
| - workflow engine    |
+----------+-----------+
           |
           v
+----------------------+
| Audit + Feedback     |
| - who/when/what      |
| - applied version    |
| - activation result  |
+----------------------+

Explanation:

The UI owns interaction clarity.

The draft model owns editable values.

The validation service owns correctness checks.

The recipe/config manager owns versioning and active state.

The activation command owns the controlled transition from saved data to machine behavior.

Machine subsystems must confirm what they actually applied.

Audit and feedback close the loop.

---

PART 9 — Interview / Real-World Talking Points

How to explain recipe/configuration UI clearly

You can say:

In industrial HMI systems, recipe and configuration UI is not simple data editing. It is a controlled workflow for changing machine behavior. A safe design separates draft, saved, approved, and active states. It validates parameters in the backend, checks machine compatibility and current machine state, previews the impact of changes, activates explicitly, confirms subsystem application, and records an audit trail.

Why recipe UI is not simple CRUD

Because recipe values can control physical behavior:

- where the machine moves
- how fast it moves
- how images are captured
- how defects are classified
- when subsystems trigger
- what production result is accepted or rejected

A normal CRUD form assumes saving data is the end of the operation.

A machine recipe UI treats saving as only one step before controlled activation.

Common mistakes software engineers make

1. Treating recipes as database records only.
2. Letting UI write directly to live machine values.
3. Putting all settings into one generic grid.
4. Relying on UI-only validation.
5. Ignoring unit clarity.
6. Not separating draft vs active.
7. Allowing recipe mutation during active production.
8. Not showing old vs new values.
9. Not checking machine state before activation.
10. Not recording an audit trail.

What strong engineers understand

Strong industrial software engineers understand that configuration changes are operational events.

They ask:

Is this value valid?
Is it valid with other values?
Is it valid for this machine?
Is it valid in the current machine state?
Who changed it?
What changed?
When did it become active?
Which run used it?
Did every subsystem apply it successfully?
Can we diagnose this later?

That is the difference between a settings screen and a production-grade recipe/configuration workflow.

The best design principle is:

Never let a parameter silently change machine behavior.

Every important recipe/configuration change should be validated, reviewed, activated deliberately, confirmed by the machine, and traceable afterward.