Protocol Bindings
A protocol binding is the link between a tag and its data source: which connection, which address, how to acquire it.
Tag Site1/Line1/Filler/Motor1/Speed (float · RPM · scaled 0–3000)
Binding PLC1 · opcua · ns=2;s=Motor1.Speed · subscribed · 1000 ms
The tag is the contract; the binding is the wiring. Swapping the wiring never changes the contract.
A binding is edited on the tag's Binding tab: switch on Enable Binding, pick the Protocol, then the Connection, then the address. The fields that follow depend on the protocol.
Binding fields
| Field | Description |
|---|---|
| Enable Binding | A disabled binding stops acquiring without being deleted. |
| Protocol | OPC UA, MQTT, Modbus (TCP / RTU-over-TCP), Allen-Bradley (EtherNet/IP), Siemens S7, SNMP (v1 / v2c), TCP / UDP. Sparkplug B is not a protocol of its own: it is an MQTT connection whose payload format is Sparkplug. |
| Connection | Which connection of that protocol to use. |
| Address | Protocol-specific: a NodeId, a topic, a register, a symbolic tag, an absolute S7 address, an OID, a generated TCP/UDP tag. See address formats. |
| Protocol settings | MQTT QoS, JSON path and retain; Modbus byte/word order and poll rate; SNMP poll rate. |
The deadband is not a binding setting: it belongs to the tag, on its History tab, because it decides what is stored and sent to brokers, not what is read.
How each protocol acquires its value
The protocol decides how a value arrives. There is no mode to choose on the Binding tab.
| Protocol | Acquisition | Rate |
|---|---|---|
| OPC UA | Subscription: the server sends a value when it changes. | 1000 ms publishing interval. A binding imported with a rate of its own keeps it; anything below 100 ms is raised to 1000 ms. |
| MQTT, Sparkplug B | Subscription to the topic: the value arrives when the device publishes. | Whatever the device publishes. |
| Modbus | Polled. | Poll Rate (ms) on the Binding tab, 1000 by default. |
| SNMP | Polled with SNMP GET. | Poll Rate (ms) on the Binding tab, 1000 by default. |
| Siemens S7, Allen-Bradley | Polled in scan groups, one per rate. | 1000 ms, unless the import that created the tag set another. |
| TCP / UDP | Pushed: every message the device sends updates the tag. | Whatever the device sends. |
A subscription moves change detection to the device, cuts network traffic and carries the source's own timestamps. A polled protocol reads on its own schedule whether or not anything changed.
Choosing a poll rate
The most common performance mistake is polling everything at 100 ms because it is possible.
| Kind of value | Reasonable rate |
|---|---|
| Fast process values driving a live trend | 250–1000 ms |
| Normal process values | 1000 ms |
| Temperatures, levels, slow analogues | 2000–5000 ms |
| Counters, totals, shift data | 5000–30000 ms |
| Infrastructure (SNMP) | 30000–60000 ms |
The value on screen is only as fresh as the slowest link in the chain — the device's own scan time. Polling a PLC with a 500 ms scan every 100 ms yields four identical reads.
One binding per tag
A tag has at most one protocol binding. There is no precedence to reason about and no "which source won" to debug, because there is only ever one.
That shapes how you build the patterns people usually reach for:
| What you want | How to build it |
|---|---|
| Read here, write there | Two tags, one bound to the source and one to the destination, joined by a pipeline. |
| Protocol bridge | A pipeline: Industrial I/O subscribe on the source tag, then a write to the destination. |
| Redundant source | A tag per source, plus an expression tag that picks the first with Good quality. |
The pipeline is not a workaround here — it is where the logic belongs. "Republish Modbus to MQTT" is a decision with failure modes and ordering, and a pipeline makes both visible.
Address formats by protocol
| Protocol | Address | Example |
|---|---|---|
| OPC-UA | NodeId | ns=2;s=Motor1.Speed, ns=3;i=1042 |
| MQTT (classic) | Topic, plus an optional JSON Path (dot path) into the payload | plant/line1/motor1/speed, JSON Path data.rpm |
| MQTT (Sparkplug) | Group/edge/device/metric | Plant1/Line1/Filler/Speed |
| Modbus | Register space, protocol (0-based) address, optional bit | HR:100, IR:10, HR:100.3 |
| Allen-Bradley | The controller's symbolic tag reference | PartsMade, Program:MainProgram.Step |
| Siemens S7 | Absolute address, built by the address fields | DB10.DBD20, M0.1, DB1.STRING0.32 |
| SNMP | Numeric OID | 1.3.6.1.2.1.1.3.0 |
| TCP/UDP | One of the connection's generated tags | field2, message, writeable |
Use each connection's Browse rather than typing addresses — it eliminates typos and pre-fills data types. → Connections
Enabling and disabling
Creating, editing, enabling, disabling and deleting a binding all require Bind a tag to a protocol. Reading bindings and their statistics requires View the namespace.
Disabling is the right way to take equipment out of service: the tag stays, its history stays, its screens stay, and acquisition stops. Deleting the binding leaves the tag unbound, which is what happens automatically if the connection is deleted.
Unbound tags
A tag with no binding is not an error:
- Internal tags never have one by design.
- Tags whose connection was deleted are left unbound deliberately, so you can re-point them at a replacement instead of losing the model.
- Tags created ahead of the equipment during commissioning are unbound until the device arrives.
The namespace panel's binding statistics list them, which is worth a look before a commissioning review.
Reading an unbound device tag says so: quality Unknown, with the reason no enabled protocol
binding — not NotFound, which is kept for a path that names no tag.
1.0.7 → A tag with no value yet
Rebinding after an equipment change
Old: PLC1 · ns=2;s=Motor1.Speed
New: PLC2 · ns=4;s=Drive_M1.ActualSpeed
Edit the binding. Nothing else changes — not the tag path, not the screens, not the alarms, not the history. The historian keeps the same tag identity, so trends span the changeover.
This is the whole reason the namespace layer exists.
Diagnosing a binding
| Symptom | Check |
|---|---|
Quality NotFound | The address does not exist — typo, or the device program changed. Browse to confirm. |
Quality Unknown, no value 1.0.7 | The tag exists and has not reported yet. Read the reason that comes with it: not yet reported means wait for the next poll or update; no enabled protocol binding means the binding is missing or disabled. |
Quality Bad, connection healthy | Data-type mismatch, or the address is out of a readable range. |
Quality Bad, connection down | Fix the connection first; bindings recover automatically. |
| Value never changes | The source really is constant, or the device is not publishing. A tag's deadband affects what is stored and sent to brokers, not the live value. |
| Value updates far slower than expected | The server is clamping the requested interval, or the device scan is slower. |
| Some tags on a connection are bad, most fine | OPC-UA node quarantine, or an out-of-range Modbus block. |