In "regular" OPC Data Access, there is no guarantee that the client will get all changes. The client is only updated once per period of "update rate", with a single value. If the value changes and then reverts back, the server may send nothing to the client (or may send just the original value with an updated timestamp). This behavior is normal;, although it may hot be want you wanted to achieve. You can use faster update rates will reduce the likeliness of this happening, but will not eliminate it altogether, plus it may put higher load on the system.
It should be possible to design a different handshaking mechanism between the PLC and the OPC server/client which is resistant to this kind of behavior.
Note 1: OPC Data Access 3.0 has a concept of "buffered" updates which can help. Only limited set of OPC Servers (and clients) support this part of the spec (it is optional), so you will need to check with the vendor. QuickOPC does not support it, though.
Note 2: When I wrote that OPC Data Access does not guarantee that you will get all the changes, still the latest value you receive should reflect the current value in the underlying system. If the PLC value goes e.g. 1 -> 2 -> 1, you may receive just 1 -> 2 -> 1, or just 1, but not only 1 -> 2.
I have a scenario where I read a register on a GE PacSystems PLC, then write the negated value back to the same register. This triggers a PLC action that writes a new value back to that register. In some cases it may be the same value as the originally read value (prior to writing the negated value). The problem is that the ItemChanged event is not being fired when the negated value is written back to the register. Can anyone explain why I am seeing this behaviour?