Controller Communication

The Consystence edge runtime reads and writes controller data through one driver layer. Two drivers are implemented and in early access: EtherNet/IP CIP, which reads a Rockwell ControlLogix directly, and GDS over gRPC to a Phoenix Contact PLCnext. One edge can connect to both. A site server can also read a ControlLogix directly over the same driver layer, read-only, without an edge (early access: our engineers enable it per controller, with a site engineer’s acknowledgement; direct reads have no edge buffer; it has run at a site trial since 28 October 2026; off by default). The PLCnext driver also serves the PLCnext border-gateway topology, an accepted target design for Consystence-managed equipment that has been demonstrated in our workshop. This page describes both drivers, how a driver is selected, and where the control boundary sits.

Throughout, we use the vendor-neutral term controller rather than “PLC”. Consystence treats ControlLogix and PLCnext controllers uniformly behind the same engineering model: controller → module → channel → tag/register. Modbus TCP is on the roadmap. A pure-.NET Modbus TCP driver (coils, discrete inputs, and holding and input registers, with the data type and word order stated in the tag path) is merged and bench-verified in the shared driver layer, but no edge or site-server acquisition path uses it yet. Choosing Modbus TCP as a controller’s protocol does not start acquisition. A direct OPC UA runtime driver is also on the roadmap. For the edge runtime in general, see the edge overview.

Advisory AI, deterministic control

The edge driver writes tags only for authorised actions: an operator command’s own writes (including, where the command has a paired acknowledge port, resetting the command port once the controller acknowledges) and, while PLC-in-the-loop simulation is active, the simulated input values (see Simulation). The platform’s AI is advisory-only: it reads, explains and recommends, but it never commands equipment. Deterministic control logic runs on the controller (the CSY managed eCLR C# control library on PLCnext, or ladder/ST on a ControlLogix), and hard interlocks live in IO modules and safety relays — never in the edge, and never in AI. The driver layer is plumbing for reads and operator-initiated writes, not an autonomous actuator.

The driver layer

Every controller connection goes through one small, symbolic driver layer: connect, disconnect, and read or write one tag or many by path. Callers never address raw register offsets. Batch reads and writes let a driver coalesce many tags into one wire request (a single batched CIP request, or a single GDS read) rather than issuing one round-trip per tag.

Each value the driver returns carries the tag path, the value, the controller data type, a quality (Good, Uncertain, Bad or ConfigError), a read timestamp and any error. The driver only moves typed values; access mode, physicalRole and the meaning of each tag come from the device type and instance mapping (see Concepts).

The edge wraps each driver with reconnect logic, so callers never touch a raw socket. Poll groups drive reads on independent timers. Changed values (by value or quality) stream upstream as they occur, with a periodic full snapshot so static values stay attested — or buffer to SQLite when the link to the server is down (store-and-forward) and replay on reconnect.

Driver selection

Each controller entry in the edge’s Plcs configuration selects a driver with its Driver value (see Edge deployment):

Driver value	Use
ethernet-ip	EtherNet/IP CIP, direct to a ControlLogix/CompactLogix controller
plcnext-grpc	GDS variables on a PLCnext controller over gRPC
stub	Simulated IO for development, tests and CI (no hardware)

Transport settings sit beside the Driver value: an address, a port and a CIP route for EtherNet/IP; for PLCnext, the edge’s PlcNext block (a socket path, or a gRPC host and port, plus the component path). The rest of the edge stays transport-agnostic. The CIP route is a comma-separated series of port,link hops (for example 1,0 for the local backplane slot 0) and supports multi-hop routes through an EtherNet/IP bridge to a CPU in a remote chassis; a malformed route is rejected outright rather than falling back to a default slot. Note that the cloud-side simulator is a separate mechanism — the server’s Sim Runtime, selected by sim:// endpoint prefixes — not this driver.

flowchart LR
  EDGE["Consystence Edge<br/>(.NET 10 Orleans silo)"]
  CLX["ControlLogix / CompactLogix<br/>(read directly)"]
  subgraph PLCnext["PLCnext controller"]
    GDS["GDS / PORT variables"]
  end
  FIELD["Field devices<br/>(VFDs, relays, IO)"]

  EDGE -- "EtherNet/IP CIP (TCP 44818)" --> CLX
  EDGE -- "gRPC (GDS) over UDS or TCP" --> GDS
  GDS -. "CIP / EtherNet-IP<br/>(border-gateway topology)" .-> FIELD

EtherNet/IP CIP: reading a ControlLogix directly

The ethernet-ip driver is a native EtherNet/IP driver for ControlLogix / CompactLogix controllers, speaking EtherNet/IP CIP over TCP (port 44818) and batching reads where the protocol allows. It needs no native library dependency. It connects the edge straight to a controller’s symbolic tag space, for example Program:Main.Pump1.SpeedSP (illustrative). An edge in our workshop reads a physical ControlLogix this way.

The controller keeps its own program and its authority over outputs, and the edge reads it alongside your existing control system. Further direct drivers (Modbus TCP and OPC UA) are on the roadmap.

PLCnext: GDS over gRPC

The plcnext-grpc driver reads and writes PLCnext GDS (Global Data Space) PORT variables through the controller’s local gRPC API. The default transport is a Unix Domain Socket at /run/plcnext/grpc.sock — lowest latency, no network stack — which suits an edge runtime co-located on the PLCnext device itself, as in the VL3 target installation. A TCP channel (GrpcHost, default port 41100) is used when the socket cannot be shared: a containerised vPLCnext, where the edge and the vPLCnext runtime do not share a filesystem, or a PLCnext on another host. The workshop’s virtual PLCnext is reached this way.

The client splits reads from writes for correctness:

• Reads are designed around the PLCnext subscription service, which delivers task-consistent, buffered samples at the controller scan-cycle rate rather than polling each variable independently.
• Writes use the data-access service for immediate, direct updates.

Subscription reads are not yet wired into the poller

The subscription path activates only after an explicit subscription is created on the driver, and the current poll pipeline never creates one. Today every read — single or batch — goes through the direct data-access service; the task-consistent subscription reads are implemented in the driver but not yet reachable in normal operation.

GDS variables are addressed by a full component path of the shape Arp.Plc.Eclr/{Component}.{Program}.{Port} — dot-joined after the first slash. The driver builds it from a configured ComponentPath prefix plus the PORT name. For example (illustrative only — names vary per project):

ComponentPath : Arp.Plc.Eclr/ExamplePumpComp.PumpStation1
PORT name     : PP01_Running
Full GDS path : Arp.Plc.Eclr/ExamplePumpComp.PumpStation1.PP01_Running

The border-gateway topology

The PLCnext border gateway is an accepted target topology for Consystence-managed equipment, demonstrated in our workshop on a virtual PLCnext. In it, a PLCnext controller sits between an isolated internal field network and the wider OT network. The PLCnext runs the deterministic control logic and speaks CIP / EtherNet-IP to the field devices (VFDs, protection relays, remote IO) on its internal port. The edge connects only to the PLCnext, and only on the external port.

The design gives a clean boundary: the field network is invisible to anything outside the PLCnext, the controller is the single point of control for its field devices, and control continues to run on the controller even if the edge disconnects. The edge sees abstracted device and process variables, not raw IO.

Demonstrated in our workshop

The PLCnext build of the control library is a generated runtime program built from the same source (the C# behavioural master), run on a virtual PLCnext only and checked with live tests, with no conformance replay; per-block vector replay on PLCnext is planned. The gRPC driver is implemented, and a licensed Virtual PLCnext Control instance serves live GDS data in the workshop integration chain. Field validation is pending. Treat throughput, scan-rate and tag-count figures as targets to be confirmed on hardware, not guarantees.

One driver layer across tiers

The edge and the site server share a single pure-.NET driver layer — the EtherNet/IP CIP stack and the PLCnext gRPC driver behind a common abstraction. No third-party PLC client library is used on either tier.

Where each transport fits

Concern	EtherNet/IP CIP (ethernet-ip)	PLCnext GDS over gRPC (plcnext-grpc)
Edge → controller transport	EtherNet/IP CIP over TCP 44818	gRPC over UDS (co-located) or TCP
Controller → field	The controller’s own I/O	In the border-gateway topology, CIP / EtherNet-IP on an isolated internal network
Field network isolation	Set by your site network design	In the border-gateway topology, the field network sits behind the gateway
Control if edge disconnects	Continues on the controller	Continues on the controller
Status	Early access, arranged with our team; reads an existing controller, read-only	Early access; the border-gateway topology is an accepted target topology, demonstrated in our workshop

For where the edge tier sits in the wider system, see cell topology. Tag values surfaced to clients are documented in the API reference.