DAQmx: Numerical indicators go blank intermittently using DAQmx Read

Question

Hello everyone,
I was wondering if anyone else has ever fought this issue and won.  I have a loop (I will attempt to attach an image of the block diagram) which performs a DAQmx Read operation.  The loop employs a 200 millisecond wait.  The loop scales the data, sends all of the values to little indicators in an array, picks out a few critical values to display on duplicate large indicators, and optionally logs the data by streaming it to disk.  The task will usually (99.9% of the time) be run at 100Hz.  So, I was figuring I could do a "Read All", since at 200 ms of wait time due to the millisecond multiple wait function, I should always have around 20 points to read in the buffer the next time around.  This would allow me to have very current readings in my displays.  I could do a partial read, but then I figure I would have a lag between the displayed values and the reality of what's going on in the test.  Having current readings, as current as can be, is highly desirable for this application.
I figured everything was good with what I was doing, especially when I tested it with a simulated device (I know a simulated device behaves much differently than a real device, especially at start up).  Everything seemed to work well.  When I go to the real hardware, though, I intermittently get blank indicators.  Actually, it is more like intermittent numbers in my indicators.  Most of the time, the DAQmx Read operation returns a null, empty array (no data available in the buffer).  I must be missing something, because I figured that a 200 ms wait would allow another 20 samples to be collected.
If someone could please just ease my conscience and let me know that I haven't done something very fundamentally wrong in this code, even if you couldn't help me with a solution, I would very much appreciate it.  I feel that this code should work, keeping data in the indicators at all times, and don't know why it doesn't work.  If you could offer me the solution, even if it is to point out that I did something very wrong, I would much appreciate it.
I am just writing this code, and still have some icons to make, so the sub VI's still have the default icons.  Sorry about that.  Basically all those do is get array subsets, or scale data, or write data to the data files.  If you need to ask questions about the code, I can understand.  I am not the greatest yet at writing self documenting code yet.  And if you need to know what that event structure does, it watches the two boolean button controls to determine what state in the state machine to go to next, and the time out case of the event structure highlights a data value if it goes out of bounds.
Sorry if I am too wordy.  I have been accused of that before.  I just notice a lot of "Help!  DAQ doesn't work.  How do I fix?" posts, and I don't see how I or anyone else could help that person at all.
I am using LV8.2, with DAQmx 8.3.1, on Windows XP, 1GB of RAM, and a fairly healthy Duo core processor.  I have a workaround where I throttle back the read operation, only reading 55% of the available samples, as reported by a DAQmx Read property node (the highest percentage I found that prevents the indicators from going blank).  This introduces a small lag between the real world and the data on display, however.  Also, it seems like a processor dependent solution.  I would have to tweak this percentage for every machine I run this on.
If I have left anything important out, please let me know, and I will do my best to clarify, and thank to anyone who reads this, and a big thank you to anyone who takes the time to reply.  Again, I would be real happy with a "That code looks good to me, and your thinking is correct", if that indeed is the case.
Thanks.
Attachments:
Log Monitor Block.JPG ‏292 KB

Answer 1

Yeah, as you and Erik said, just specifying (Sample Rate / 5) as the '# to read' could do the trick.  Then you can ditch the 'Wait (msec multiple)' function.  I don't think I'd recommend the -1 = infinite timeout though.  I'm pretty leery of stuff that can lead to an infinite wait or an infinite loop.  Even a 1 sec timeout should easily be way more than enough.  Note however that this method depends on all your processing code executing in under 200 msec on average.  Otherwise, your reads will fall behind and you'll eventually get a DAQ buffer overflow error.  My earlier suggestion to first query for # available samples and then read the MAX of (# available, SampleRate/5) will prevent cumulative fall-behind effects.
There's too many unknowns to speculate with any confidence on exactly why the software timing method didn't work.   I can point out some additional things that bear greater scrutiny though.
1. You've got some sort of function dealing with file streaming that takes a path input and produces a path output.  This probably means that every loop iteration you're using the path to open a file, write data, and close the file again.  This actually may consume more than 200 msec, at least some of the time.  Because this runs in parallel with the msec wait function, something like the following could be happening:
A. Iteration 1 proceeds as expected.  The DAQ read collects 20 samples, the file write consumes only 100 msec, and the wait msec function ends after 160 msec in order to end on a 200 msec multiple.  The wait function took longest, so your whole loop ends on a 200 msec multiple.
B. On iteration 2, the wait msec function ends after 200 msec on the next 200 msec multiple.  The DAQ read collects another 20 samples (because it's been pretty much exactly 200 msec since the previous loop iteration started) right away.  However, Windows was busy messing with the file cache so this time your file write consumes 375 msec.  The file function took longest so your whole loop ends 175 msec into the next 200 msec multiple.
C. On iteration 3, the wait msec function ends after 25 msec on the next 200 msec multiple.  The DAQ read collects 37 samples that have come in since the prior call 375 msec ago.  The file function consumes only 50 msec this time, ending the loop 25 msec into the next 200 msec multiple.
D. On iteration 4, the wait msec function ends after 175 msec at the next 200 msec multiple.  The DAQ read collects the 5 samples that have come in since the prior call 50 msec ago.  Uh oh, not enough samples...
One possible fix is to open the file outside the loop and leave it open until after the loop is done.  Opening and closing files has quite a lot of overhead.  Inside the loop, you'd be passing around the file refnum.  Doing this one thing alone might also be a way to fix your timing problem.  Along similar lines, you could write the data to a queue and then do your file writes in an independent loop that reads the data out of the queue.  You can search here for "producer consumer" for more info.
-Kevin P.