A connected value can still be the wrong value
A packaging machine reads Ready = TRUE from a palletiser. The cable is unplugged. Five seconds later, the watch window still shows true. Nothing supernatural happened: the program is displaying the last received value. The dangerous assumption is treating it as fresh permission.
A communication interface needs more than addresses. It needs meaning, ownership, validity, timing and failure behaviour. Start with the transaction the machines must accomplish: transfer one identified carton, accept a new recipe, read an energy total, or publish a production result. The protocol carries that agreement; it does not invent it.
For every exchanged item, document its source, type, unit, update expectation and consumer. For a command, also document acknowledgement and duplicate handling. A spreadsheet containing register numbers without those facts is an address list, not an interface specification.
Choose for the conversation you need
Fast cyclic device control, supervisory data access and occasional parameter transfers have different needs. The first may require a tightly integrated industrial network supported by the controller and devices. The second may benefit from named data, quality and timestamp information. The third may work well through a simple request-response interface.
Modbus defines operations on coils and registers and provides specifications for application transactions and transport implementations. OPC UA provides a richer information and service model; its DataValue can carry value, status and timestamps. Those features are useful only when your application interprets them correctly. Modbus specifications, OPC UA DataValue definition.
Do not choose by slogan. List required cycle time, device support, engineering tools, diagnostic needs, network ownership and security requirements. “Ethernet” identifies neither the application protocol nor a guaranteed response time. Two Ethernet ports do not establish interoperability.
Work through a register mapping
Suppose a meter publishes temperature as a signed 16-bit integer in tenths of a degree. The register contains decimal 253. The application should produce 25.3 degrees Celsius, not 253 degrees and not the bit pattern interpreted as an unrelated floating-point format.
Now suppose an energy total occupies two 16-bit registers. You need the manufacturer's word order, signedness and scaling. The byte order inside a protocol field and the order of words forming a larger application value are separate questions. Test a known distinctive value, not zero: zero looks correct under almost every byte swap.
Also resolve address notation. A manual may label its first holding register with a human-facing number while a client library asks for a zero-based protocol offset. Record both forms explicitly. Randomly subtracting one until a plausible number appears is not enough; adjacent registers can contain equally plausible measurements.
Make multi-value updates coherent
A remote recipe contains target weight, mixer speed and recipe revision. If three writes occur separately, the receiving scan can observe a new weight with the old speed. Faster communication reduces the window but does not remove the logical problem.
Use the supported atomic transfer mechanism where available. Otherwise design a staging area and an explicit commit handshake: write all proposed values, publish a new request identifier after the payload is complete, and have the receiver validate and copy the accepted payload into its own active structure. Document ordering guarantees and avoid assuming unrelated network writes arrive as a single transaction.
For a large read that may change during acquisition, a version-before/version-after strategy can detect inconsistent snapshots if the producer implements it correctly. The producer marks changes with a defined version scheme; the consumer accepts only a stable completed version. A version field alone is not magic if it is updated in the wrong order.
Liveness has a deadline
A heartbeat counter that changes periodically gives evidence that the producing application is progressing. A connected socket gives different evidence: a communication path may remain open while the application is stuck.
This ST excerpt monitors change, assuming a cyclic TON and a counter updated by the peer. It is not a full communications driver. Initialisation must establish a starting counter and deliberately mark the peer unproven until a change is observed.
HeartbeatChanged := ReceivedHeartbeat <> PreviousHeartbeat;
PreviousHeartbeat := ReceivedHeartbeat;
IF NOT TransportHealthy THEN
PeerObservedAlive := FALSE;
ELSIF HeartbeatChanged THEN
PeerObservedAlive := TRUE;
END_IF;
PeerTimeout(IN := NOT HeartbeatChanged, PT := T#2s);
PeerHealthy := TransportHealthy
AND PeerObservedAlive
AND NOT PeerTimeout.Q;Choose the two-second allowance from the actual update contract and failure consequences, not from this example. If the counter changes every 500 milliseconds, allow for task and network variation. If it changes once every five seconds, the example will repeatedly declare a healthy peer dead.
Counter wrap does not matter to this simple inequality test unless the counter makes a full cycle between observations. Its range and observation rate must prevent that ambiguity. Reconnection also needs a fresh session policy; an old command must not become new merely because the cable returned.
Acknowledged is not completed
Imagine sending “dispense 100 grams.” The receiver acknowledges the message, performs the dispense, then the reply disappears. The sender retries. Without duplicate protection, 200 grams may be dispensed.
Give a meaningful command an identifier and separate accepted, executing, completed and failed results. A repeated identifier should return the known result rather than execute the physical action again. Define identifier wrap, restart behaviour and how long results remain available. A protocol transaction number may correlate messages without providing this application-level guarantee across reconnections.
For consequential actions, communication uncertainty must produce a reconciliation step. “We did not receive completion” does not prove “nothing happened.” This principle is central to Coordinating a cell.
Try it
A PLC reads ten devices sequentially. Each successful request takes 20 milliseconds. One disconnected device waits for a 500-millisecond timeout. Estimate the loop time, then explain why the healthy devices may appear stale despite a working network.
Work through the answer
Nine successful requests use about 180 milliseconds; the disconnected device adds 500, giving roughly 680 milliseconds before overhead. A freshness limit of 300 milliseconds will expire for healthy devices because the polling schedule cannot revisit them fast enough.
Separate device health from scheduler design. Use an appropriate supported concurrency limit or independent polling groups, and back off failed devices without starving the healthy ones. Retain deadlines derived from actual process needs. Simply increasing all freshness limits conceals the delay and may make a real failure take too long to detect. Test both a completely disconnected peer and a slow peer, because their effects on the queue can differ.