# Process I/O and sensing: current status

> What RosieOS does today with cell digital I/O, why torch outputs are refused everywhere, and the fact that no seam tracking or sensing is implemented.

URL: https://advancedmetalresearch.com/docs/concepts/process-io-and-sensing
Section: RosieOS docs / Concepts
Last updated: 2026-10-10

RosieOS moves the robot. It does not yet run the welding process. This page states exactly what exists, so you do not plan around features that are not there.

| Capability | Status |
|---|---|
| Cell digital inputs and non-torch outputs | Implemented in rt-core. Not qualified on hardware. |
| Torch output (arc on/off) | **Refused** everywhere |
| Weld parameters (wire, gas, arc, travel speed) | Stored as program and preset data. Nothing sends them to a power source. |
| Seam tracking and sensing (laser, vision, touch, through-arc) | **Not implemented** |

## Cell I/O in rt-core

A machine config can declare one digital I/O terminal in its `io` block, selected by `io.profile` from `rt-core/config/drives/`. It has up to eight inputs and eight outputs.

| Field | Values | Meaning |
|---|---|---|
| `io.torch_qualified` | `false` only | Torch outputs are unqualified. The compiler accepts no other value. |
| `io.inputs[].class` | `fast` or `supervisory` | A `fast` input must be satisfied for outputs to stay on. |
| `io.inputs[].polarity` | `active_high` or `active_low` | |
| `io.outputs[].class` | `process` or `torch` | `torch` outputs are always refused. |
| `io.outputs[].safe_state` | `false` only | Every output's safe state is OFF. |
| `io.outputs[].expiry_ns` | 1 to 1,000,000,000 ns | An ON intent lapses after this long unless renewed. |
| `io.outputs[].readback_bit`, `readback_polarity` | input bit 0–7 | Independent physical feedback for the output. |

A process output turns on only when all of these hold:

1. The session holds a current grant and has armed I/O with `io_arm`. `io_arm` requires a fresh I/O exchange, satisfied fast inputs and OFF readback on every output after the last fence.
2. A trajectory point sets the output's bit in `io_mask` and `io_values`, both 8-bit fields in configured output order.
3. The core's final output permit holds for that cycle.

An output goes OFF on its own when its expiry passes. The core drops every output to OFF and disarms I/O when any of these happens:

- Stop or a new generation fences the session
- the permit lapses
- a fast input drops
- the I/O exchange is lost
- readback still disagrees with the commanded value three exchanges after a change

Intent and readback are reported separately in status. A commanded value is never taken as proof that the output switched. Reason codes include `io_not_configured`, `io_not_armed`, `io_fast_input_unsatisfied`, `io_readback_disagreement`, `io_marker_late` and `io_exchange_lost`. See [Error codes](https://advancedmetalresearch.com/docs/reference/error-codes).

> [!WARNING] Cell I/O is a process interlock, not a safety function. A `fast` input is not a safety input. Wire guards and the E-stop into the hardware safety chain. See the [safety model](https://advancedmetalresearch.com/docs/get-started/safety-model#hardware-e-stop).

The channel counts, expiry ceiling and readback window above are marked unverified on hardware in the code (`io_channels_unverified`, `io_readback_cycles_unverified`).

## Torch outputs are refused

Switching the arc is refused at every layer until it is qualified on hardware:

- **rt-core** refuses any intent on a `torch`-class output with `io_torch_unqualified`, and every machine config must declare `torch_qualified: false`.
- **The dense trajectory daemon** refuses a `.rdt` that contains torch samples with `native_torch_unsupported` and the consumer action `remove_torch_samples`.
- **OLP** refuses to load a program that still requires process outputs. Choose the run mode **Dry run · process outputs off**, which strips them before Load. The motion is unchanged.

The OLP STOP button's tooltip mentions dropping the torch. That describes the Stop path, which drives every output OFF. It does not mean the torch output works.

## No seam tracking or sensing

RosieOS has no laser, vision, touch or through-arc sensing, and no runtime path correction. The robot follows the planned trajectory exactly.

The word "tracking" in the weld planner means something else. It is the **tracking certificate**: a geometric bound on how far the planned tool centre point (TCP) may deviate from the seam model. The default tolerance is 0.5 mm, unless the weld's own `tolerance.position_mm` sets another. The verifier checks it before a program is admitted. It says nothing about where the real seam is. See [Weld planning and verification](https://advancedmetalresearch.com/docs/concepts/weld-planning-and-verification).

## Weld parameters are data

Weld presets in `weld_planner/v1/data/presets/weld/` describe a process: method, ISO 4063 number, travel speed, arc, wire, gas, weave, and start and end behaviour. Torch presets are in `data/presets/torch/`. The planner uses travel speed and torch geometry to plan motion. The arc, wire and gas fields are carried with the program, but nothing drives a welding power source from them.

## Sources

Written from these files in the RosieOS repository (https://github.com/advanced-metal-research/RosieOS):

- `rt-core/include/cell_io.hpp:13-24,37-60,134-200`
- `rt-core/config/templates/machine.json (io block and _doc fields)`
- `rt-core/protocol/application-v1.schema.json (rules.cell_io, types Point io_mask/io_values, reasons io_*)`
- `rt-core/engine/cycle_machine.hpp:3540-3545`
- `motion-server/joint-trajectory/v1/src/rt_control_executor.hpp:148-156`
- `offline-programming/v1/internal/denseexec/rt_core.go:772-777,797-800`
- `offline-programming/v1/ui/src/execution/densePanel.ts:79-81,541-544`
- `weld_planner/v1/python/weld_motion_planner/planner/trajectory_optimization/engine/weld_trajopt.py:496-497`
- `weld_planner/v1/data/presets/weld/gmaw-steel-fillet.json`