The new DNP driver offers an option for read-after-write to help with RTUs that do not generate an event when a value is written.
In using the new driver, both in direct-operate and select-before-operate modes, we see the Read Analog Output command go out to the RTU immediately after the write (microseconds after the write confirm is received). However, at least in our case, it goes out so quickly that the RTU has not had time to process and update its data image, so what we get back is the last value the RTU had, rather than the value recently written.
Is there any way to delay the read-after-write poll? Or any way to issue a Read Analog Output poll specifically (clearly the driver does it, but the exposed scripting functions only expose demand class-level polls)? Or, at least preference, a demand integrity poll (the script function does not accept class 0 as an argument)?
It didn't seem to, but since you asked, seems there is a conflict in the documentation. The documentation says a list for the classes, but the example (and who reads the docs when there is a sample code to copy?) shows:
without the brackets needed for a list entry. It does indeed seem to work (although the docs only show "1,2,3") with
I don't think doing a poll for just class 0 is a good idea. The next time a class poll happens you might get data with past timestamps. You're begging for out of order data.
agreed, just testing to make sure class [0] worked. We need something to read back the AOs, and right now it seems class 0 after a one-second delay is the only tool in our arsenal, so we'll do that and make it a full poll.
I think adding a delay will change the behavior a bit though - right now the write service call in the OPC server does not return until the read-after-write has happened as well. I don't think that will be a good idea if there is an artificial delay added, especially if there were a bunch of outputs being operated.
I would LOVE that, so thank you. I suspect there a fair number of devices out there that will require a little processing time. In the meanwhile, we have a workaround. Thanks.
