I/O Controller System

A register-based state machine bridging the SCADA layer to your physical I/O.

The I/O controller system is the bridge between the Robot SCADA & IOT Server and the physical world — relay outputs, contact inputs, analogue channels, and Modbus devices on the packhouse floor. Logic runs either centrally on the server or directly on edge hardware, and every controller exposes the same register-based interface so the rest of the platform — dashboards, alarms, audit log — can read and drive I/O without caring where it lives.

Central controllers

Python-scripted controller logic runs server-side in a dedicated worker process (`scada_io_worker`). Useful for orchestration logic that touches multiple devices, complex sequencing, or anything that benefits from the full Python ecosystem.

Edge controllers

A compact bytecode VM runs the same controller programs directly on Robot hardware — keeping latency low for real-time loops and continuing to operate even if the network or server is briefly unavailable.

Register-based state machine

Every controller exposes a flat register space of digital and analogue values. State transitions are driven by register changes, making the model easy to inspect, log, and reason about — and trivial to expose to dashboards or external systems.

Modbus RTU & TCP

First-class Modbus support over RTU (RS-485) and TCP. Drop-in integration with standard industrial PLCs, scale heads, VFDs, and relay modules — read coils, write holding registers, and map them into the unified register space.

MQTT & HTTP adapters

Push and pull controller registers over MQTT topics or HTTP endpoints. Lets external systems — line software, BI tooling, or third-party PLCs — observe or drive I/O without learning a bespoke protocol.

Digital & analogue I/O

Read and write discrete signals (contacts, relays, indicators) and analogue channels (4-20 mA, 0-10 V, scale weights, temperature probes) in the same model. Conversion, scaling, and engineering-units mapping are part of the controller definition.

Where logic runs

            ┌────────────────────────┐
            │  Robot SCADA & IOT     │
            │      Server            │
            │                        │
            │   scada_io_worker      │ ← Central controllers (Python)
            └──────────┬─────────────┘
                       │  Modbus / MQTT / HTTP
        ┌──────────────┼──────────────────┐
        │              │                  │
   Robot terminal   Modbus PLC      Remote I/O module
   (edge VM)       (3rd party)      (relays, analogue)

Central controllers are best for orchestration that spans multiple devices, complex business logic, or anything that calls back into the database. Edge controllers are best for low-latency local loops, fail-safe behaviour during network outages, and offloading repetitive work from the server.

Integration patterns

Scale weighing — Modbus scale head reports a continuously-updating weight register; the controller debounces, applies tare, and posts a stable measurement back to the container record.
Conveyor and diverter control — relay outputs driven by central controller logic that sequences barcode scans, weigh events, and downstream gating.
Environmental control — analogue temperature input drives a relay output for a fan or heater, with the central controller enforcing setpoint policy and logging excursions.
Third-party PLC bridging — expose a slice of an existing PLC’s register map over MQTT so dashboards and alarms can observe it without touching the PLC programming.

Operational model

Hot-reload — controller scripts can be reloaded without restarting the worker, so logic changes don’t require downtime.
Per-controller telemetry — register reads, writes, and protocol errors are exposed as Prometheus metrics for dashboarding and alerting.
Tracing — each register operation is captured as an OpenTelemetry span, end-to-end visible in Zipkin alongside the rest of the request flow.
Audit trail — significant state transitions and operator-initiated overrides land in the central event log alongside container and robot events.

Why it matters

Most packhouses end up with a patchwork of PLCs, scale heads, and ad-hoc relay logic accumulated over the years. The I/O controller system gives you a single, observable, scriptable layer over all of it — without forcing a forklift upgrade. Existing equipment keeps doing its job, the SCADA server gains visibility and control, and new automations can be written once and run wherever they make most sense.

Back to Software · Contact us for a deployment discussion.