Connector

The Connector page: the Communication column, its tree of drivers, lines, folders, devices and tags, the two identities every tag carries, and the permissions and locks that govern editing.

The Connector is where a field device becomes data the rest of the application can read. It is the rail page named Connector, and it opens for any role that holds View connector. The page pairs the Communication column on the left, a tree of everything the embedded server talks to, with a detail panel on the right that edits the selected node in place; as the page's own description says, "Select a node to edit it inline. Changes save automatically."

The Communication column

The column is headed Communication and holds, from top to bottom: the Drivers row, a search box with four state chips, the tree, and a footer with the column's commands.

The Drivers row

The first row is the driver registry, drawn above the tree rather than inside it: the driver groups below are its siblings, not its children. It reads Drivers, then how many drivers are enabled ("3 driver(s)"), then a health dot that rolls up every enabled driver. Selecting it opens the drivers list described on The drivers list and a driver's page.

Search and the state chips

A chip and the search text combine. The selected node always stays visible, so the panel never edits a row you cannot see; a driver with nothing under it shows only under All, or when its own name matches.

The tree

Two shapes, decided per driver:

• Every driver except Modbus RTU: Driver > Folder (up to two levels) > Device > Tag. Folders come first, in name order, then the devices filed at the driver's own level.
• Modbus RTU: Driver > Line > Device > Tag. Devices hang off the physical line they share and take no folder.

Drivers that hold something list flat, alphabetically. Enabled drivers with nothing configured are tucked under a Drivers without devices row with a count, so a fresh install with sixteen enabled drivers is not sixteen empty branches; when nothing at all is configured every driver lists flat. Each row summarizes what is below it:

The dot colors and the texts are explained on Enabling and health. Right-clicking a row selects it and opens a menu that mirrors the command bar for that node; a row with nothing the role may do opens no menu. The splitter between the column and the panel drags to resize.

The footer: New…, Expand all, Collapse all

Everything New… creates lands at a driver's own level. Filing inside a folder is a command on that folder, described on Device folders.

The detail panel

With nothing selected the panel reads "Select a driver, serial line, device or tag in the tree to inspect and edit it. Changes save automatically." Selecting the Drivers without devices row explains itself the same way: "These drivers are enabled but have no devices yet. Expand the folder and select a driver to add its first device." Every other node opens the panel documented on its own page below.

Edits autosave: a text or number field saves when you leave it (or press Enter), a switch or a checkbox when you flip it, a combo when you pick. Rapid edits on one device coalesce into a single save about half a second after the last one. A save the station refuses is rolled back to what the database holds and the reason lands in the action feed at the bottom of the window; an edit that leaves the device unusable (a blank name, an out-of-range unit id) is not saved, and the panel says what is missing. While the page is open, the values in the tree and the panels refresh once a second.

Wire key and address: the two identities of a tag

Every tag carries two names, and the difference decides what a change costs.

The wire key is <Driver>.<Device>:<Tag>, for example ModbusTcp.Furnace:Temperature. It is what the embedded server polls and publishes, what a Process channel binds to, and the name external OPC UA clients see. The device part is the driver kind plus the device name with every character that is not a letter or digit replaced by an underscore. The wire key ignores folders: filing a device somewhere else changes nothing on the wire.

The address is Connector.<Driver>.<Folders…>.<Device>.<Tag>, for example Connector.Simulated.Air.CompressedAir.HeaderPressure. It is the path the tree shows, with each segment sanitized the same way (a leading digit gets an underscore in front), and it is what Logic expressions, scripts, alarm conditions and dashboard bindings type. Renaming a device or a tag, filing a device into a folder, and renaming or removing a folder are all address changes, and the app rewrites every consumer of the old address in the same operation; the name fields preview how many references follow before you commit. The Logic address space reads the same addresses.

Device names only need to be unique inside their driver, case-insensitively: a Modbus TCP device and an OPC UA device may both be called Furnace, because their wire identities are ModbusTcp.Furnace and OpcUa.Furnace. Two enabled devices under one driver whose names normalize to the same technical segment (Line A and Line-A) collide, and both are withheld from polling rather than one winning; their rows read no value until one is renamed or disabled. A technical device identity is limited to 128 characters. Under one driver a folder and a device at the same level may not sanitize to the same segment either, because one address cannot be both a branch to expand and a point to read.

There is no separate import or export of the Connector tree: the configuration travels with the application's backups.

Engineering boundaries

The Connector never stops being a live read surface, but its configuration is refused in two situations, and the page says which:

• A Process run holds the station. A banner titled "Engineering locked" explains that a Unit operation is active and configuration stays read-only until every Unit finishes, while run controls and other operator actions remain available. Every mutating verb stays drawn and greyed with the reason "Configuration is locked while a Unit is running."
• The runtime is stopped. A banner titled "Runtime stopped" says that acquisition, Logic and recording are paused and that every change is refused until the runtime is restarted, with the configuration and the recorded runs intact. The same verbs grey with the reason "Runtime stopped", and the tree's values become gaps as communication stops.

Reading, searching, selecting, the Open row actions and Copy value on a tag remain available in both situations.

Permissions

Three Connector bits, listed in full on Permissions, decide what the page draws:

Every command reads the permission again when it runs, so a verb that was drawn for a role that has since changed is refused with the same message rather than executed.

In this area

The drivers themselves, one page per protocol with its connection fields, addressing, types, discovery and write behavior, are grouped under Drivers.