Automation reference
Structured steps, operators, parameters, datasets, Lua, and run results.
Automation reference
Structured automation is a typed tree over project tags. It does not invent addresses or decoding: every read, comparison, capture, and write resolves through the same tag definition used by the desktop views. A run freezes its project inputs before execution so later editor changes cannot mutate work already in progress.
Structured step catalog
| Step | Operation | Success condition / output |
|---|---|---|
| Read | Reads one tag and optionally captures the decoded value | A compliant response decodes through the tag; the capture enters the current scenario scope |
| Write | Encodes and writes a literal, parameter, or compatible captured value | The device returns the required compliant write response; dry run suppresses the device change |
| Expect | Reads or evaluates a tag/capture and compares it | The selected comparison is true; observed and expected values enter the report |
| Wait | Sleeps for a duration, or polls a condition until timeout | Timed wait elapses, or the condition becomes true before its timeout |
| If / Else | Evaluates one condition and runs exactly one ordered branch | The chosen branch completes; variables continue only when scope rules permit |
| Retry | Runs a non-empty child block for 2–10 attempts with an optional delay | One attempt completes; failed-attempt captures are discarded and writes are never rolled back |
| Scenario | Calls another named scenario with explicit or inherited parameter bindings | The child completes; its local captures do not leak into the caller |
| Complete | Ends the current scenario successfully with a message | The success is consumed at the current scenario-call boundary |
| Fail | Ends the current path as a failure with a message | Normal failure handling applies, including an enclosing Retry |
If and Retry blocks may nest up to four levels. Scenario call graphs must be acyclic, may expand to at most eight call levels, and are bounded to 500 expanded steps. These limits are validated before a run reaches the connection.
Comparison operators
| Operator | Accepted values | Meaning |
|---|---|---|
| = / ≠ | Boolean, numeric, or text of a compatible type | Exact equality or inequality after normal tag decoding |
| < / ≤ / > / ≥ | Numeric | Ordered comparison in engineering units |
| Within tolerance | Numeric nominal value plus tolerance | Observed value lies within expected ± absolute tolerance |
| Within range | Numeric lower and upper bound | Observed value lies inside the inclusive range |
Expected values, tolerances, and range bounds may come from literals, parameters, or earlier compatible captures. When the comparison observes a tag, operands use that tag's engineering representation, so a temperature tolerance is expressed in the displayed temperature unit rather than raw counts.
Inputs and launch configuration
- Parameter
- Named Boolean, number, or text input declared by a scenario or Lua script. A default keeps manual runs repeatable.
- Dataset
- Up to 1,000 ordered named cases for one target. Sparse cells inherit the run-profile override and then the parameter default.
- Run profile
- Saved target, optional compatible dataset, sparse parameter overrides, repeat count from 1–1,000, and continue-on-failure choice.
- Connection selection
- Local launch state. The project run profile deliberately does not bind a physical connection, so the same procedure can run on another bench.
Lua host API
| Call | Purpose | Boundary |
|---|---|---|
| bus.param(nameOrId) | Read a frozen typed launch parameter | Returns Boolean, number, or text |
| bus.read(tag) | Read and decode a project tag | No raw-address escape hatch |
| bus.write(tag, value) | Encode and write through a project tag | Read-only profiles and dry run still apply |
| bus.sleep(milliseconds) | Asynchronous bounded wait | Does not block the UI thread |
| bus.expect(condition, message) | Create an explicit assertion | A false condition fails the script step |
| print(...) | Capture bounded diagnostic output | Output is streamed to the run view and retained in the report |
Run result and reports
The live result is hierarchical: iteration, dataset case, scenario call, control-flow branch, and individual step remain inspectable. Each result can retain status, duration, observed values, captures, logs, errors, and transaction identifiers. JSON is the lossless Busloom report; JUnit maps outcomes into CI test cases; standalone HTML is for human review. Imported JSON reports open as read-only Replay and cannot be rerun without the original project.