TwinCAT OPC UA Client Writes: Separate Local Gates from Server Rejection and Restart Replay

A value in a PLC output image can remain unchanged while the remote
OPC UA server has a different value after restart. That does not
necessarily mean a write was transmitted and lost. TwinCAT’s OPC UA I/O
client has local write gates and documented change-driven behavior that
must be checked before blaming the server.

The scope is the TwinCAT OPC UA I/O client described by Beckhoff’s
online documentation, inspected on 19 October 2026. The restart behavior
below applies specifically to its Polling and Subscriptions modes. It is
not a claim about every PLCopen function block, client mode or installed
product build. No client or server was operated.

Establish whether a
request was generated

Beckhoff’s Writing
variables guide identifies two enabling conditions: the variable
must have Enable Write selected, and the I/O client’s global Write
Enable output must be active. The variable setting creates the writable
output element in the process image; the global setting permits
write-command generation.

These are useful diagnostic boundaries. A successful read only
establishes the read path. A mapped output value only establishes local
application state. Neither proves that both gates admitted a write
request.

Record the selected variable, the output mapping and both gate states
alongside the application value change. Use an authorized isolated
fixture to observe whether a request actually leaves the client. Do not
enable all outputs in a live system simply to see whether communication
starts working.

Account for
change-driven behavior after restart

For Polling and Subscriptions modes, the same guide states that
writes occur after a value change within the I/O client. Values already
written are not automatically written again after a server restart.
Beckhoff explains the reason: replaying an old local value could
overwrite a newer value supplied by another client.

Consider a hypothetical setpoint that was written once before the
server restarted. The local output still contains that setpoint, but its
presence is not evidence of a fresh post-restart request. A diagnostic
trace with no new write can be consistent with the documented
behavior.

Do not create a meaningless value toggle merely to force a write. An
intermediate setpoint can have real effects, and another writer may
legitimately own the current value. Define whether the application
should adopt the server’s state, request an explicit authorized restore,
or require an operator decision. That ownership policy belongs to the
product, not to a generic reconnection recipe.

Separate local
gating from server rejection

Once a request is observed, inspect its returned status and target
identity. Beckhoff’s server
ReadOnly documentation describes a TwinCAT 3 TMC-imported symbol
marked read-only with OPC.UA.DA.Access. A client write to that symbol
receives BadNotWriteable.

That is a different failure from a request never generated because
the client gate is closed. Keep the two outcomes distinct in logs and
user-facing diagnostics. Disabling the server’s protection is not an
appropriate automatic response to a missing local request.

The client
error-diagnosis page also directs investigation of missing writes
toward the global gate. It does not establish that every write failure
has that cause. Use the actual observation boundary to choose the next
check.

Qualify a small state matrix

A proposed simulator test should cover a disabled per-variable gate,
a disabled global gate, an enabled path with a deliberate value change,
and a server-side read-only rejection. Then restart the test server
while leaving the local output unchanged and record whether a new
request is generated.

For each case, distinguish local value, gate state, transmitted
request, operation result and remote readback. If the product includes
an explicit restore operation, test its ownership and value-validation
rules separately from ordinary reconnect behavior.

The resulting integration contract explains when the client generates
writes and who may restore remote state. It avoids treating an unchanged
local output as a standing command to overwrite the server whenever
connectivity returns.