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.

What a binding holds

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.
Stale after (ms) 1.0.8	Optional. How long the value may go without a reading before it is marked Uncertain. See stale after.
Protocol settings	MQTT QoS, JSON path, retain and the device-read settings; 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, 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. OIDs sharing a rate are batched into one request.	Poll Rate (ms) on the Binding tab, 1000 by default, at least 100.
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.

The reverse does hold: several tags may bind to the same address. Two tags reading different JSON fields of one MQTT payload is the normal case, and each gets its own field. 1.0.8 Before 1.0.8 only the tag subscribed last received data from a shared topic. → MQTT

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 B)	Group/edge node/device/metric — the device segment is omitted for a node-level metric	Plant1/Edge1/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 the browse button beside the address rather than typing it. It removes typos and fills in the data type the source reports.

Protocol	Beside the address
OPC UA	Browse the server's address space
Allen-Bradley	Browse the controller's tags, and Read now to confirm a value
Siemens S7	Read now, showing the decoded value and the raw bytes
SNMP 1.0.8	Walk the agent from a start OID (prefilled from the address) and pick an OID; the walk runs only when you ask for it
Sparkplug B 1.0.8	The metric tree observed from birth certificates, rooted at the real group id
Classic MQTT	Nothing to browse — no broker lists its topics. Type the topic.
Modbus	A live preview of the register as the tag will decode it

The Sparkplug picker writes group/node/device/metric — the key data is routed by, which is not always the name shown in the tree. It leaves the data type alone when the edge node announced one QUBIQ cannot map, so you choose it rather than inherit a guess.

Stale after New in 1.0.8

Stale after (ms) on the Binding tab is the longest the value may go without a reading. When a tag whose last reading was Good stays silent past it, the gateway re-publishes its last value as Uncertain, with a status such as Stale: no update for 45s (limit 30s). The next reading restores the tag with its own quality.

Everything downstream sees it: the historian stores the change of quality, so history shows when the signal went quiet; alarms and broker publishers receive it; screens stop presenting the value as current.

• It works for every protocol, and is off when blank or 0.
• The shortest window is 1000 ms; the watchdog checks once a second and a shorter value is refused when you save.
• A tag that is already Bad — connection down, quarantined — stays Bad. Stale never upgrades it.
• A tag that has never had a reading is left alone.

Only for a source that sends periodically

An OPC UA subscription, and an MQTT device that publishes on change, send nothing while the value holds steady. A setpoint that does not move would be marked stale while it is perfectly fine. Use stale after on a device that reports on a cycle — a heartbeat topic, a polled register — and set it to a few times that cycle.

This is the tag's own check. It is separate from a connection's health, and from the age shading a screen draws from when a value last arrived.

Enabling and disabling

Creating, editing, enabling, disabling and deleting a binding all require Bind Protocol. Reading bindings and their statistics requires View 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.

When a connection comes back Changed in 1.0.8

A reconnect no longer writes values nobody measured:

• A tag waiting for its first reading is Bad, with the status waiting for initial data. It used to be a Good 0, written to history and handed to alarms on every subscribe and every reconnect of a PLC tag.
• A polled connection that reconnects leaves its live tags alone. Each one used to be reloaded and stamped Bad while it waited, so a 50,000-tag PLC wrote 50,000 Bad rows on every reconnect, though its driver never stopped polling. Only bindings that are genuinely missing are subscribed again.
• A tag is not announced offline when it is only being re-subscribed. It is announced offline only if it does not come back: disabled, unbound, deleted, or its subscribe failed.
• Only a Good reading proves a link is up. A placeholder, or a server's own comm-failure status, no longer flips a disconnected connection back to connected.

A connection's recovery also no longer waits on another's: subscriptions are queued per connection, so a dead OPC UA server delays only its own tags, and a tag write, read or unsubscribe never waits behind a different connection.

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, waiting for initial data 1.0.8	Subscribed, first value not here yet. If it persists, the address is not being served.
Quality Uncertain, Stale: no update for … 1.0.8	Stale after expired. The device stopped sending — or the window is set on an on-change source.
Quality Bad, Device offline (…) 1.0.8	An MQTT device's own status topic reported it offline.
Quality Uncertain, retained message; original time unknown 1.0.8	An MQTT broker replayed an old retained value. See retained messages.
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.

Next

→ User-defined types