Sure, but first understand the *reason* for the lag. As far as I can see, it must relate to the time required to execute the Modbus code. I don't have Modbus experience to comment in any further detail, but it's really the only candidate.
Your DAQmx task must be sampling and pushing data into the buffer faster than the loop can iterate. As you fall farther and farther behind, the 1 sample you read per iteration will be a value from the increasingly distant past.
So here are 2 options for getting rid of the lag:
1. Continue to use a buffer and a hardware sample clock, but read multiple samples at a time. If you stick with Finite Sampling, you will need to add a DAQmx Read property node so that each iteration you can first query for the # of available samples. Change your DAQmx Read to "1ChanNSamp" and wire that # in as the # to read.
You'll get an array of data out, but almost everything you have downstream will accept it, other than the one numeric indicator.
(There's a simpler version of this where you change over to Continuous Sampling. Then you can wire the special value -1 as the # samples to read when you call DAQmx Read. That'll return all available samples without having to query for the exact #.)
2. Remove the DAQmx Timing call to leave your task in on-demand (immediate) mode. Then each call to DAQmx Read (1Chan1Samp) will initiate a single sample and return it.
Your time between samples will be prone to high variability due to this software-timed approach. But you won't notice lag or get overflow errors.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
