Set inputs by hand

For a run

1. In Runs, choose New run and pick the system. The Inputs card lists every input of every part, in its unit, with the range the part can read, for example Bus voltage, V: the part reads 0 to 81.9188 V.
2. Type a value. It holds for the whole run. Leave a field empty to keep the part’s reset value.
3. Start the run. The run page lists the inputs you set, and Run again fills them in for you.

A value outside the range is clamped to the nearest one the part can report. An input that has no unit takes the part’s raw code, a whole number in its range.

If the run’s scenario already drives an input, the card says The scenario sets this one instead of showing a field: the scenario’s next sample would replace your value, so it could not hold. Run without the scenario to set it yourself.

Live in the Proving Ground

In a running session, pick a part in the world outliner. The Inspector shows its Inputs: type a value and choose Set. The value applies from the next sync point, the Inspector says when, and it is recorded with the session, so Save as test replays it. Inputs that take only raw codes are set in a run, not live. See Proving Ground.

Check what the firmware read

Under Values at stop, add a Device register check named device.0xOFFSET with the value you expect. It is read when the run stops, and the result shows the value found. For example, an INA226 named u5 with its bus voltage set to 12.6 V reads 0x2760 at u5.0x02 (12.6 V at 1.25 mV per bit); with nothing set it reads 0x0.

From the API

POST /api/v1/runs takes the same inputs as stimulus, one stream per input, with the value in the input’s unit (si) or as a raw code (raw):

{
  "boardId": "my-board",
  "firmwareId": "<firmware id>",
  "assertions": [
    { "kind": "oracle" },
    { "kind": "device_register", "device": "u5", "offset": 2, "expected": 10080 }
  ],
  "stimulus": [
    {
      "target": { "device": "u5", "port": "voltage.bus_voltage" },
      "interpolation": "hold",
      "samples": [{ "tNs": 0, "value": { "si": 12.6 } }]
    }
  ]
}

A run whose scenario drives the same input is refused with 422 input_set_by_scenario.

Test failures

Error handling is hard to test on a bench. With twinConfig on the same request you can take a part off the bus, or force a register after reset, such as a wrong chip ID, and check that your firmware notices:

"twinConfig": {
  "overrides": [
    { "device": "imu", "disconnected": true },
    { "device": "u5", "registers": { "0xFE": 4660 } }
  ]
}

Registers are named by offset ("0xFE") or by name ("MANUFACTURER_ID").