A WriteItemValue() call can write the requested value and still fail about 30 seconds later with Exception from HRESULT: 0xC004D004. In the documented case, the OPC client could also read the item normally. The decisive evidence came from Wonderware FSGateway 1.5, whose log reported that it timed out waiting for a poke acknowledgement.
Identify the Failure Pattern
| Observation | Diagnostic meaning |
|---|---|
| The item value changes | The write reaches at least part of the data path; the exception does not prove that the value remained unchanged. |
ReadItem() succeeds |
Basic item access remains available, but a successful read does not validate the write acknowledgement path. |
| The exception appears after about 30 seconds | The delay is consistent with the gateway log's acknowledgement timeout. |
0xC004D004 is returned |
In this case, the error originated downstream in FSGateway rather than in the QuickOPC.NET component. |
Confirm the Server-Side Timeout
Inspect the FSGateway log for the affected item. The recorded failure was:
Timed out waiting for CAL to return Poke acknowledgement for item
Item 'ai_H_LTE_SP_7' poke failed [hr=c004d004]This message separates data delivery from acknowledgement completion: the value may change before FSGateway reports that it did not receive the required poke acknowledgement. Use the exact item named in the log to correlate the gateway event with the client exception.
Apply the Verified Correction
- Confirm that the installed gateway is Wonderware FSGateway 1.5 and that its log contains the poke-acknowledgement timeout with
hr=c004d004. - Update FSGateway from version 1.5 to version 1.5 SP1.
- Repeat the same
WriteItemValue()operation against the affected item.
The documented installation stopped throwing write exceptions after the update to 1.5 SP1. The evidence establishes this correction for the reported installation; it does not establish that every occurrence of 0xC004D004 has the same cause.
Verify the Result
Confirm both layers of success: the item reaches the commanded value and WriteItemValue() returns without the delayed exception. Then check that the FSGateway log no longer records the CAL poke-acknowledgement timeout for that write. A changed item value alone is insufficient because the original fault changed the value before reporting failure.
FAQ
Why does WriteItemValue write the value but return 0xC004D004?
In the documented FSGateway 1.5 case, the value changed but the gateway timed out waiting for CAL to return a poke acknowledgement. The incomplete acknowledgement caused the exception even though the write was visible.
Is HRESULT 0xC004D004 a QuickOPC.NET error?
The evidence for this case points to Wonderware FSGateway: its log recorded hr=c004d004 with a failed poke acknowledgement. Inspect the OPC server or gateway log before attributing the error to the client component.
How do I fix FSGateway error 0xC004D004?
For the reported FSGateway 1.5 installation, updating to version 1.5 SP1 eliminated the write exceptions. Verify the fix by repeating the write and confirming that no acknowledgement-timeout entry appears in the gateway log.