Skip to main content
Version: 1.0.4

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​

FieldDescription
Enable BindingA disabled binding stops acquiring without being deleted.
ProtocolOPC UA, MQTT, Modbus (TCP / RTU-over-TCP), SNMP (v1 / v2c), TCP / UDP. Sparkplug B is not a protocol of its own: it is an MQTT connection whose payload format is Sparkplug.
ConnectionWhich connection of that protocol to use.
AddressProtocol-specific: a NodeId, a topic, a register, an OID, a generated TCP/UDP tag. See address formats.
Protocol settingsMQTT 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.

ProtocolAcquisitionRate
OPC UASubscription: 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 BSubscription to the topic: the value arrives when the device publishes.Whatever the device publishes.
ModbusPolled.Poll Rate (ms) on the Binding tab, 1000 by default.
SNMPPolled with SNMP GET.Poll Rate (ms) on the Binding tab, 1000 by default.
TCP / UDPPushed: 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 valueReasonable rate
Fast process values driving a live trend250–1000 ms
Normal process values1000 ms
Temperatures, levels, slow analogues2000–5000 ms
Counters, totals, shift data5000–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 wantHow to build it
Read here, write thereTwo tags, one bound to the source and one to the destination, joined by a pipeline.
Protocol bridgeA pipeline: Industrial I/O subscribe on the source tag, then a write to the destination.
Redundant sourceA 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​

ProtocolAddressExample
OPC-UANodeIdns=2;s=Motor1.Speed, ns=3;i=1042
MQTT (classic)Topic, plus an optional JSON Path (dot path) into the payloadplant/line1/motor1/speed, JSON Path data.rpm
MQTT (Sparkplug)Group/edge/device/metricPlant1/Line1/Filler/Speed
ModbusRegister space, protocol (0-based) address, optional bitHR:100, IR:10, HR:100.3
SNMPNumeric OID1.3.6.1.2.1.1.3.0
TCP/UDPOne of the connection's generated tagsfield2, 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.

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​

SymptomCheck
Quality NotFoundThe address does not exist — typo, or the device program changed. Browse to confirm.
Quality Bad, connection healthyData-type mismatch, or the address is out of a readable range.
Quality Bad, connection downFix the connection first; bindings recover automatically.
Value never changesThe 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 expectedThe server is clamping the requested interval, or the device scan is slower.
Some tags on a connection are bad, most fineOPC-UA node quarantine, or an out-of-range Modbus block.

Next​

→ User-defined types