Drivers
What a driver is, how drivers are enabled and disabled, the fixed driver of a device, the table of every driver this product knows, what each driver page documents, and the note on drivers a package does not carry.
A driver is the protocol the station uses to talk to a family of equipment: Modbus registers over TCP, an OPC UA server, a Siemens PLC. Every device on the Connector page belongs to exactly one driver, and the driver decides which connection fields the device shows, how its tags are addressed, which data types they may carry, whether they can be written, whether the driver can scan for equipment, and whether the station polls them or the equipment pushes to it. This group holds one page per driver; this page is what they have in common.
The registry
The set of drivers is fixed: it ships with the application and cannot be extended from the page. The Drivers row at the top of the Communication column lists the ones this installation carries, each with its description, its device count, its health and an enable/disable pair; the table and its rules are on The drivers list and a driver's page.
Drivers ship enabled. Disabling one only hides its group from the tree, and it is refused while the driver still has devices (or, for Modbus RTU, serial lines), so a configured device can never disappear from view. Enabling one adds an empty group under the tree's Drivers without devices row. Adding a device to a driver enables that driver on its own. The enabled set is persisted with the configuration and travels with the backups.
The driver of a device is fixed
You choose the driver when you create the device: the column's New… menu names the driver the device lands under, and Add device on a driver's page creates under that driver. From then on the Device card shows the driver as read-only text. To move a device to another protocol, create a new device under the other driver and delete the old one; the address changes, so the references have to be pointed at the new tags through each tag's Used by card.
Every driver
| Driver | Talks to |
|---|---|
| Simulated | Synthetic in-app signals for testing without hardware. |
| Modbus TCP | Modbus registers over TCP/IP. Default port 502. |
| Modbus RTU | Modbus registers over a serial line (RS-485/232). |
| OPC UA | OPC Unified Architecture client over opc.tcp. |
| Siemens S7 | Siemens S7 PLCs over the S7comm driver. |
| Rockwell EtherNet/IP | Allen-Bradley / Rockwell PLCs over EtherNet/IP (CIP). |
| Beckhoff ADS | Beckhoff TwinCAT PLCs over ADS/AMS. |
| Mitsubishi MC | Mitsubishi PLCs over the MELSEC MC driver. |
| BACnet | BACnet/IP building-automation devices. |
| IEC 61850 | IEC 61850 substation IEDs over MMS. Not included in the distributed package (see below). |
| OCPP | EV charge points over OCPP (charge points connect to this station). |
| Redfish | Redfish REST API for server/datacenter hardware. |
| Matter | Matter smart-home devices (Bluetooth commissioning). |
| LoRaWAN | LoRaWAN sensors via the embedded Basics Station network server. |
| AVEVA PI | AVEVA PI System points via PI Web API, over HTTPS by default. |
| HTTP | Generic HTTP/JSON endpoints polled as tags. |
The registry also knows OPC DA (classic OPC Data Access over COM/DCOM), but no driver serves it in this product: it is never listed, never enabled and takes no device.
What the drivers have in common, and where they differ
The Connector renders one editor for every driver and lets the driver decide which parts appear. This table says what to expect before opening a driver's page:
| Driver | Connection fields on the Device page | Tag addressing | Poll interval | Tag writes | Discover |
|---|---|---|---|---|---|
| Simulated | none | the tag name, plus the signal shape | yes | yes | yes (its catalog) |
| Modbus TCP | Host, Port, Unit ID, Minimum transaction interval | typed: register class and number | yes | yes | yes (host or CIDR scan) |
| Modbus RTU | Serial line (fixed), Unit ID | typed: register class and number | yes | yes | yes (unit-id probe on a line) |
| OPC UA | Host, Port, Resource path, Username, Password | free text: Node id | yes | yes | yes (server address) |
| Siemens S7 | Host, Rack / Slot | typed: area, DB, byte, bit | yes | yes | no |
| Rockwell EtherNet/IP | Host, Slot | free text: Controller tag, plus an offset | yes | yes | yes (broadcast) |
| Beckhoff ADS | Host, Port, Local IP (AMS) | free text: Symbol | yes | yes | no |
| Mitsubishi MC | Host, Port | free text: Device address | fixed 1 s | yes | no |
| BACnet | Host, Port, Device Id | typed: object type and instance | fixed 1 s | yes | yes (Who-Is) |
| IEC 61850 | Host, Port | free text: MMS path | fixed 1 s | yes | no |
| OCPP | Identifier | typed: connector number; the tag name ends in Meter or Status | pushed by the charge point | no (read-only) | yes (connected charge points) |
| Redfish | Host, Username, Password | free text: Resource path, plus a JSON pointer | yes | yes | no |
| Matter | Node ID (read-only) | the tag name is the cluster | yes | no (read-only) | yes (commissioned nodes) |
| LoRaWAN | Identifier (DevEUI), Server / Key (app key) | typed: channel or offset, LPP type | pushed by the sensor | no (read-only) | no |
| AVEVA PI | Host, Port, Resource path, Transport, Username, Password, Bearer token | free text: PI path | yes | yes | no |
| HTTP | Host, Port, Resource path | free text: Path | yes | yes | no |
Each driver also narrows the Data type list a tag offers to what it can actually marshal; the exact list is on the driver's page. Where the table says "fixed 1 s" the driver ignores the configured interval, so the Device and Tag pages hide the Poll interval field for it. Where it says "read-only", the Access field offers Read only alone and the write field never appears.
What every driver page documents
Each driver page walks the same sections in the same order: the connection fields the Device card shows and how they assemble the Base URI; how a tag is addressed (the typed fields or the free-text token, and the read-only wire address the panel previews); the data types offered; discovery, when the driver has it; writes, when the driver accepts them; and the driver's particularities (credentials, certificates, timing, a network server the station runs, pairing).
A driver the package does not carry
The IEC 61850 driver builds and runs in a development installation but does not enter the distributed package: its protocol library is licensed under terms that do not allow shipping it inside the installer. The Connector never lists a driver the running package does not carry, and never enables it. A configuration that arrives with such devices anyway (a restored backup, a configuration from another machine) keeps them: the driver's row stays listed as long as those devices exist, its description reads "Driver not included in this package.", and the driver's page and every device under it carry a banner saying the same. Those devices stay offline and keep their settings; they can be deleted, but not copied, and no new device or discovery scan can be started under that driver. Enabling the row is refused with "'IEC 61850' was not enabled: Driver not included in this package."
Which drivers a package carries is read from the embedded server's plugin registry, which exists only once the server has started. Until then every driver counts as present, so the drivers list settles a few seconds after launch and then stays put for the session, even while the server is stopped and started again.
A driver's code is loaded once for as long as the application runs. Stopping and starting the communication rebuilds the running devices and the driver list from that same load, which is what keeps the station's memory flat across a day of restarts. The consequence is that replacing a driver's own files on disk takes effect only after the application itself is restarted.