Hello,
I am not sure if I correctly understand the issue. I can imagine two interpretations:
1) The "trigger" variable in the OPC server is signaled *before* all OPC data items that it covers have their proper values.
In this case, I am afraid, the issue needs to be solved on the server side, or you need to resort to artificial delays, as you have already done.
2) The "trigger" variable in the OPC server is signaled *after* all OPC data items it covers have their proper values, but for some reason, when reading those OPC items, you get values that are older.
In this case, the reason may be in the way OPC (the specification), and also QuickOPC (as a client implementation), handle the Reads. In OPC Data Access 2.0, it is possible (for the client) to specify a read from the (server's) Cache, or from a Device. In OPC Data Access 3.0, in addition to this, the client can also specify a read by MaxAge (of the value). QuickOPC uses possibly all these methods interchangeably, also adds a read from "memory", providing you with a value that it already has in its (client-side) cache, if it is fresh enough. There is default setting in EasyDAClient that specifies that the values you get should not be "older" than 1000 milliseconds; if we don't have such value already for you, we call the server, and use Device, Cache, or MaxAge method, depending on the circumstances.
You can force a Read from Device e.g. like this:
var client = new EasyDAClient();
DAVtq vtq = client.ReadItem("OPCLabs.KitServer.2", "Simulation.Random",
new DAReadParameters(DADataSource.Device));Best regards
