Question about system.opc.writeValue

Hi All,

We are using a system.opc.writeValue call and in looking at the documentation we can not find if the isGood returned from it means the value has been verified all they way down to the device? Does anyone know if the isGood means the write to just the OPC server was good or was it verified all the way down to the device?



It’s up to the driver, so no definitive answer. I think for all of Ignition’s own drivers, any use of system.opc.{read/write}* generates dedicated traffic to the device to satisfy the call. So, with that caveat, yes, it is all the way to the device.

I’m sure @Kevin.Herron can point out any exceptions.

Yeah, it’s all the way to the device.

The only exception is that sometimes a device will indicate a write succeeded but program logic or whatever else will prevent the value from actually changing.

A read after write is not performed to verify.

1 Like


Thanks for the reply. We are seeing some scenarios where it appears the value is not making it down the PLC even though we get the isGood flag from the function call.


Every time I thought I found a case where a write was lost on the way to the PLC I found it really was an artifact as Kevin described–some other logic changed it back before Ignition’s OPC driver made the next scheduled read for its subscriptions.

This is the number one reason I avoid any design pattern that requires Ignition (or any other HMI or SCADA package) to set a register or boolean and the device to reset the same register/boolean. Race-free handshakes are only possible if any given variable is only ever written from one direction.

You’ll need to submit wireshark captures of such a lost write to prove it.


We have found that scenario you described a response code from a gateway script that is getting set from Ignition and then reset later in the plc. We are revising the code to make ignition own the writing of this tag exclusively. Thanks for the responses guys, always great information from these forums.