Fixtures #

URLs: /fixtures (list), /fixtures/new, /fixtures/{id}, /fixtures/{id}/edit

A fixture is the wiring between a UUT's pins and a station's instrument channels — which probe goes on which pin, which DMM channel reads which voltage. A fixture is bound to a part (so it gets used in the right runs) and is used at run time by stations whose instruments cover the fixture's connections. The fixture's connection rows themselves carry free-text UUT-pin and channel fields — they're not validated against the part's pin map at edit time.

List — /fixtures #

A table with one row per fixture that is either configured in the project (a YAML file exists) or has been observed in run history (no YAML file, only referenced by past runs). Columns:

ColumnWhat it shows
StatusConfigured chip (grey) — a YAML file exists. Observed chip (amber) — appears in run history but has no YAML file.
IDFixture identifier
NameHuman-readable name
PartPart name (falls back to the bound part ID when the part name isn't resolvable)
RevRevision string (when set)
ConnectionsCount of pin → channel connections defined; for Observed rows
RunsTotal runs that have used this fixture
PassedRun count with outcome passed
FailedRun count with outcome failed
Last RunMost recent run start timestamp, browser-local time

Above the table, a filter card with All / Configured / Observed buttons narrows the view. The active filter is mirrored into the URL so the view is bookmarkable.

A New Fixture button at the top right jumps to /fixtures/new. Clicking a Configured row jumps to the detail view at /fixtures/{id}. Observed rows are not clickable — no YAML exists to display.

When no fixtures are configured or observed, the table is replaced with an empty-state card explaining the entity and offering a Create Fixture button.

Detail — /fixtures/{id} #

A header bar (Back + Edit buttons), one Fixture Information card (Fixture ID, Part Family, Connections count, Description, and a link to the Part), then a tab strip with three tabs:

TabContent
Pin MappingsThe connections table — one row per (UUT pin → instrument channel) mapping. Columns: Connection (the mapping's name), UUT Pin, Net, Instrument, Channel, Description.
Compatible StationsStations whose instruments cover this fixture's required instruments (matched by instrument role).
DiagramA Mermaid-rendered diagram of the pin-to-instrument wiring.

Edit — /fixtures/{id}/edit #

The Edit page carries the fixture's info fields (Fixture ID, Name, Part, Part Revision, Description) plus a Pin Mappings card where you manage connections. The Part is a dropdown. The UUT Pin and Instrument Channel fields on each connection row are free-text inputs, not dropdowns sourced from the part pin map. The Instrument dropdown on each connection row pulls its options from the union of all stations' instruments in the project, so any instrument role declared anywhere is selectable. Connections are managed as rows — Add / Edit / Delete one at a time via per-row buttons and an Add Connection dialog.

Not every YAML field is editable here — instrument_terminal, function, route, station_types, uut_resource, and slots are YAML-only.

New — /fixtures/new #

A short form for just the fixture info (ID, Name, Part, Part Revision, Description) — no connection rows. On create it redirects to the Edit page, where you add the pin mappings.

Underlying data #

Fixtures are stored as YAML in fixtures/*.yaml under the project root.

For the YAML schema, see Configuration reference → Fixtures. For the concept, see Concepts → Fixtures.

Common tasks #

  • Wire a new probe to a pin — open /fixtures/{id}/edit, add a connection row mapping pin → instrument-role + channel.
  • See where a fixture has been used — the List view's Runs + Passed + Failed columns + Last Run; the Results list doesn't filter by fixture today, so use the Runs column here as the quick scoreboard.

See also #