Access
Sign in as Technician or Engineer. A Debug tab appears in the navigation bar. The tab is invisible to Operator-role sessions.
Layout
The Debug Panel uses a three-column grid with tabs inside each column:
┌────────────────────────────────────────────────────────────────────────────┐
│ Debug Panel [Job selector pills] │
│ [Inject Trigger — Eng only] │
│ [View Sequence] │
├──────────────────────┬──────────────────────────┬─────────────────────────┤
│ Controls | Worker │ Variables | History | │ Events | Log Tail | │
│ │ Timeline │ IPC Trace │
└──────────────────────┴──────────────────────────┴─────────────────────────┘
Every debug control targets exactly one job slot — the one selected in the job selector. All other slots continue running at full speed with no pause overhead. A technician can debug Job 1 while Jobs 2–4 continue producing normally.
If you switch the selected job while another is still paused, a yellow warning banner appears. The paused job stays paused until you switch back and click Resume, or until it is aborted.
Job selector
A row of pill buttons shows every active job slot. Each pill displays:
- A colored dot indicating job state (green = running, amber = waiting, red = failed)
- PAUSED badge when the job is halted at a step boundary
- SBS badge when step-by-step mode is armed
Click a pill to make that job the debug target.
The View Sequence button opens a modal showing the full step list loaded into the engine. The step the selected job is about to execute is highlighted in amber.
Step control
Step-by-step mode
A toggle that enables or disables step-by-step mode for the selected job only.
When ON: the job pauses at every step boundary before executing the next step. The plugin that just finished always completes normally — hardware is never left mid-operation. The job stays paused indefinitely until you act.
When OFF: the job runs freely. Breakpoints still apply.
Step-by-step state persists across DUT cycles.
Controls while paused
When a job is paused, a yellow banner shows the name and ID of the step about to execute, with four controls:
| Control | Behavior |
|---|---|
| ▶ Resume | Release the job to run freely until the next pause point |
| → Next | Execute exactly one step then pause again |
| ↩ Retry: <step> | Jump back to the last completed step and re-execute it |
| ⚗ Inject Result | Open the result injection modal (see below) |
Go To Step
Jump execution directly to any step:
- Click a step chip or type a step ID in the autocomplete input.
- Click Go.
If the job is paused the jump happens immediately. If running, it takes effect after the current step completes.
Breakpoints
A breakpoint pauses the job when a specific step is reached — even if step-by-step mode is off.
Add a breakpoint:
- Type a step ID in the left input (autocompletes from the loaded sequence).
- Optionally type a condition in the right input.
- Press Enter or click + Add.
Remove: click × on the breakpoint card.
Each breakpoint card shows the condition and a live hit count — how many times the breakpoint has been reached this session. Breakpoints persist across DUT cycles.
Condition syntax
| Expression | Pauses when… |
|---|---|
| (empty) | Every time the step is reached |
hit >= N | From the Nth hit onwards |
hit == N | On exactly the Nth hit |
hit > N | From the (N+1)th hit onwards |
Example: hit >= 3 — skip the first two passes, pause from the third.
Result injection
The ⚗ Inject Result button (visible only while paused) opens a modal to supply a fake raw_data JSON object for the pending step. On next execution:
- The engine skips the plugin call entirely.
- Your injected value is used as
raw_data. - Normal validation runs against it.
- The injection is consumed — subsequent executions hit the real worker.
Pending injections appear as chips below the paused banner. Click × on a chip to cancel before it fires.
Use this to test validation logic without physical hardware, or to force a known FAIL condition to verify downstream behavior.
Worker health
Real-time snapshot of the Python worker process backing the selected job.
| Metric | Description |
|---|---|
| Status | running or dead |
| PID | OS process ID |
| Uptime | Time since the worker was last started |
| Restarts | Times the worker has been restarted (amber if > 0) |
| Messages | Total responses since the current worker started |
| Last contact | Time since the last response was received |
Restart Worker hard-kills and respawns the worker process. Disabled while the job is in RUNNING state.
Variable watcher
A live table that resolves dot-separated paths against the selected job's current state.
Quick-add paths
| Path | Description |
|---|---|
state | Current job FSM state |
trigger_data.trigger_type | Trigger type |
trigger_data.data.serial | Serial number from trigger payload |
last_step.result | Result of the most recently completed step |
last_step.step_name | Name of the last completed step |
last_step.duration_ms | Duration of the last completed step |
last_step.raw_data.<key> | Any key from the plugin's raw measurement |
step_count | Total steps executed so far this cycle |
Custom dot-separated paths are also supported. If a key is not found, the cell shows —.
Click + Add Watch to open the modal. Select the job slot, click a Quick add chip or type a custom path, then click Done. Variables from multiple jobs can coexist in the same table.
Value colors
| Color | Meaning |
|---|---|
| Green | PASS, true, or positive boolean |
| Red | FAIL, false, or negative boolean |
| Grey | Null or unresolved path |
Step history and timeline
Step History
A table of all completed steps for the selected job in the current cycle. Each row shows step name, result badge, duration, attempt number, and loop iteration. Click a row to expand:
raw_dataas formatted JSON- Validation detail: operator and threshold for numeric, expected vs. actual for boolean/string, point results for array type
Step Timeline
An SVG bar chart of step durations for the current cycle. Bars are color-coded by result (green = PASS, red = FAIL, amber = ERROR/TIMEOUT). Hover a bar to see step name, duration, and result.
Log tail
A live dark-terminal feed of worker output for the selected job.
Lines are color-coded: ERROR in red, WARN in amber, DEBUG in grey, others in near-white.
| Control | Description |
|---|---|
| Job selector | Filter to a single slot or show all |
| Search | Text filter on line content |
| ↓ Auto / ⏸ Paused | Toggle auto-scroll to the latest line |
| Clear | Remove buffered lines for the current filter scope |
The buffer holds the last 2,000 lines per job. Cleared automatically at the start of each new cycle.
Event log
A chronological feed of debug events emitted during the session:
| Event | Meaning |
|---|---|
| PAUSED | Job halted at a step boundary |
| BREAKPOINT | Job halted by a registered breakpoint |
| RESUMED | Operator clicked Resume |
| SBS ON / OFF | Step-by-step mode toggled |
| TRIGGER | Trigger injected manually (Engineer only) |
Controls: job filter, auto-scroll toggle, Export (download as JSON), Clear. Capped at 1,000 entries.
IPC trace
A raw message-level view of the traffic between the engine and the Python worker. Tracing is disabled by default — click ▶ Start Trace to enable it for the selected job.
Each row shows: timestamp, direction (→ outgoing / ← incoming), command or status, sequence number, and message ID. Click any row with a payload to expand and see the first 200 characters of the JSON content.
IPC tracing adds overhead by capturing and buffering every message. Keep it disabled during normal production runs — it has no effect on validation or reporting, but it does consume memory.
Inject Trigger (Engineer only)
The Inject Trigger button in the header fires a trigger directly into the selected job, bypassing the normal trigger dispatcher. Useful for testing a specific job slot without physical hardware input.
Only visible when signed in as Engineer.
Safety properties
Plugins always complete. Pauses happen between steps, never mid-plugin. Hardware is always in a defined state when a job is paused.
Abort works while paused. Clicking Abort on the Runner screen while a job is paused cleanly terminates the sequence.
Other jobs are unaffected. Pause flags, step-by-step state, and breakpoints are stored per job slot. No global pause exists.
Injections are one-shot. An injected result is consumed on first use. If the cycle resets before the step fires, pending injections are cleared.
The Runner screen shows a DBG⏸ badge on the fixture card of any job currently paused in debug mode, so you can see at a glance which job is stopped without switching to the Debug tab.