Mark,
I'll comment on your points one at a time. Two of my own question first. 1) What are you using for buffer size? 2) What operating system are you running this on?
"- Removing the consumer loop made me able to change samples to read to 20 with a Fs = 1000 Hz. (opposed to a 100 at 1000 Hz with the consumer loop)"
This corresponds to a 20 ms loop time, which makes sense given that you're reading 20 samples at 1 kHz. If there is any operation in your loop that takes longer than this (either enqueing data or calculating your output waveform), then you will slowly back data up into the buffer until it overflows.
"- Changing the charts to graph didn't make any difference"
Shot in the dark on my part, and apparently not the issue.
"- Adding a time-out time to the Enqueue VI didn't make any difference either. It still stops with the same error message (E-200279)."
What value did you use for timeout? This goes back to the first point... If it takes longer than 20 ms for this operation, or any other operation then you're going to build up data in the buffer. If this goes on for long enough, you'll see error -200279. This brings up another interesting point... If data is collecting in the buffer, you're feedback is going to be based on older and older data (in the case of a 10 kS buffer, data could be up to 10 seconds old). It sounds like this is not desirable for your application. More on this later.
"- The program doesn't show in increasing memory consumption when running before it stops on the E-200279 error"
I just wanted to check this, because increasing memory consumption is often the cause of loop slowdown. It sounds like this is not your issue.
"I didn't really get your comment about calling the Write VI before the Start VI."
I'm not referring to the flat sequenced part of your code, I'm referring to the 'main' loop. Here is brief description of the mode you will end up being in by virtue of not calling write before start on your finite analog output task. If you don't explicitly set a buffer size, DAQmx will use data written a pre-start call to DAQmx Write to infer the buffer size it should use. Since you don't do this, DAQmx puts your output in the mode mentioned above. If I remember correctly (I will check this when I have a little time), DAQmx does not write to the FIFO in this mode. As such, if you write more than one sample between sample clocks, only the last sample written gets output. Since you use the NSamp version of write, it is highly likely this will happen.
Is data backing up in your buffer bad for your application (I would guess yes, based on what you've told me about the application)? Do you necessarily need to read every sample? Depending on the answer to these questions, there are several approaches we can take. If you can stand to miss data, then you can use the DAQmx Read Property node to set the 'relativeTo' property, and set this to 'Most Recent Sample'. This will cause DAQmx to always read the newest data available in the buffer. You can use the 'offset' property to tell DAQmx which data to read from this point. For example, you can specify an offset of negative 'Samples Per Read' to ensure that you don't have to wait for hardware to produce new samples. The tough part of doing this is that if your loop is slower than hardware, you will simply drop and data between reads. If your loop is faster than hardware, you can get into a situation where you re-read some data from one iteration of the loop to the next.
Because of this, hardware-timed single point is probably a better way to go, however you'll need some other mechanism to detect stop (perhaps use a counter task to count edges on your 'stop' signal). If you get a count, you'd know that you need to shut things down. If you are running on a windows system, I suspect that you'll never reliably be able to run at 5 kHz without missing some samples.
That was verbose, but hopefully helpful.
Dan
