Status code · Good
GoodClamped
GoodValue clamping
GoodClamped is not an error - but the server changed your value. A write outside a declared limit was applied at the limit instead of being rejected. Your set point is not what you sent, so always read back after writing and compare, rather than trusting a Good status.
Defined behaviour: The operation succeeded but the value written was adjusted to fit within a limit before being applied. (our description of the condition this code reports)
What you actually see
A write returns success, but reading the same node back gives a different number - typically exactly the range limit - and the machine behaves as if a smaller change was made.
Why it happens
- Written value outside the node's declared rangeWhere a Variable declares an EURange or an instrument range, a server can clamp a write to that limit rather than refusing it. Writing 120 to a set point limited at 100 applies 100 and reports success with a clamp indication. Both the acceptance and the adjustment are intentional server behaviour.
- Device or PLC block enforcing its own limitsThe OPC UA server may pass the write straight to a block that has high and low limits of its own. The block applies its limit and the server reports the outcome honestly. Nothing in the OPC UA configuration explains it, which is why the limit is often hunted for in the wrong place.
- Unit or scaling mismatch pushing the value past a limitA value in the wrong unit or with the wrong scaling factor arrives far outside the range, gets clamped to the limit, and produces a number that looks almost reasonable. This is the case most likely to go unnoticed, because a clamped value is inside the range by construction.
- Data type range narrower than the valueWriting a value that exceeds what the node's DataType can represent - a large integer into a smaller integer type, or a value beyond a scaled integer's span - can be clamped to the type's limit rather than refused. The write appears to succeed and the stored number is wrong.
- Rate-of-change or ramp limit appliedWhere a set point is protected by a ramp limit, a large step can be applied as the largest permitted step. The reported outcome is a clamp, and the value will continue moving toward your target over subsequent cycles, which makes an immediate read-back look like a failed write.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Always read back after a write and compareTreat a write as complete only when a read of the same node returns the value you intended. This is the single practice that turns a silent clamp into a detected condition, and it costs one extra service call. Log both the intended and the actual value when they differ.
- Read EURange and the DataType before writingRead the node's EURange, instrument range and DataType once and cache them, then validate client-side before sending. Rejecting the write in your own code with a clear message is more useful than having the server quietly adjust it.
- Check the engineering unit and any scalingRead the EUInformation property and confirm the unit matches what you are sending. A clamped write whose intended value was ten or a hundred times too large is almost always a unit or scaling error rather than an operator entering an impossible number.
- Look for the limit in the device as well as the serverIf the server's declared range is wider than the value you wrote, the limit is downstream. Read the block's own high and low limit parameters where they are exposed, or check the program in the engineering tool. Do not assume the OPC UA node's range is the only limit in the path.
- Surface the clamp to whoever made the requestAn operator or an MES that asked for 120 and got 100 needs to know. Propagate the adjusted value and the fact of the adjustment back through your API rather than reporting a bare success, which is how a production recipe silently runs at the wrong set point.
- Distinguish a clamp from a rampRead the node again a few cycles later. A value still at the limit is a clamp; a value that has moved further toward your target is a ramp limit and the write will eventually complete. The handling is different, so make your code able to tell them apart.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | Writing from the Data Access View and watching the row update is the quickest manual demonstration of a clamp: the write succeeds and the displayed value settles at the limit rather than at what you typed. |
| UA-.NETStandard (C#) | WriteAsync returns a StatusCode per value, so branch on the sub-code rather than only on IsGood. A read-back helper wrapped around every write is the pragmatic pattern for set points. |
| asyncua (Python) | Node.write_value raises only on a bad status, so a clamp passes through silently. Follow every set-point write with read_value and assert equality within a tolerance appropriate to the data type. |
| node-opcua | session.write returns the status code per node. Implement a write-then-read helper for anything a recipe or operator sets, and log the delta when the read does not match. |
| Siemens S7-1500 | Limits enforced in the PLC program apply after the OPC UA write, so the server can accept a value the program then constrains. Check the program's limit logic, not only the node configuration. |
| Ignition | Tag write handling reports success from the server, so a clamp is not visible in the write result alone. Use a bidirectional binding or an explicit read-back on set-point writes. |
What it looks like in the log
Write ns=3;s=Oven.SetPoint value 120.0 returned a clamped result; read-back 100.0
Value adjusted to declared maximum for ns=3;s=Oven.SetPoint (EURange 0 to 100)
Set point write accepted with adjustment; intended 120.0, applied 100.0Confirm the fix
Read the node back and confirm it holds exactly the value you intended; where it does not, confirm the limit that produced the adjustment by reading the node's range and the device block's own limit parameters.
Stop it happening again
Make read-back-after-write mandatory for every set point in your client library, validate against cached EURange and DataType before sending, and propagate any adjustment to the requesting system instead of reporting a plain success.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.