Stream with Replicate example - Clarify recommended buffer sizes

[AristosQueue (NI)]

Ben: That kind of parallel work doesn't work for a Stream channel, but it works just fine for a Messenger channel. The Messenger allows multiple writers into the channel or multiple readers from the channel. Therefore, you can use Messenger inside a parallel For Loop. Put a read endpoint inside the parallel For Loop and now you have better throughput.

[Ben]

Thank you!

See, thinking out loud pays off.

Ben

[atrinh]

Hi There,

I think my question might be an appropriate build on the initial poster's question regarding buffers and the stream channels. I am trying to stream data off the DAQmx read in a Producer loop and reading it in a Consumer loop. I am getting an error -200279 which I understand is a buffering issue hence me adding onto this thread. My stream channels I believe have unlimited buffering so I am not sure where my trouble is coming from. Any insight?

Thanks in advance,

Anton

[Blokk]

---

@atrinh wrote:

Hi There,

I think my question might be an appropriate build on the initial poster's question regarding buffers and the stream channels. I am trying to stream data off the DAQmx read in a Producer loop and reading it in a Consumer loop. I am getting an error -200279 which I understand is a buffering issue hence me adding onto this thread. My stream channels I believe have unlimited buffering so I am not sure where my trouble is coming from. Any insight?

Thanks in advance,

Anton

---

I have a bad feeling about that property node in your "Collect case". I also do not really understand the role of that "Stream" case.

Anyway, you should really not do anything else but the DAQmx Read in your data producer loop, and do everything else in the consumer loop!

By the way, if you want to collect finit number of samples, just use finite number DAQmx Init, instead of that Continuous setting!

Edit: and why that "Last element" set to True for the Stream Write node?

[RVallieu]

Last element should not be hardwired to True.

If you are doing FINITE acquisition, why not set up a finite acquisition task?

-200279 is a DAQmx acquisition error.  Your DAQmx Read VI is not keeping up with the DAQmx Acq Task running in the background.  Your read loop has things that are slowing it down (property node, Last Element = True on Write, BUILD ARRAY)

Don't use the property node to updated Collected - send a User Event to the top User Event Structure to update the value of the indicator.

To keep track of the number of reads and samples to know if it is time to stop - create a read of a known size and keep track of number of acquisitions in an accumulator.

[atrinh]

I'll do a quick lowdown of the background of the code. This is just a portion of a larger program where a User would press a button to initiate "stream". In this state, the user can view the signal from the DAQ board but not collect/write to file. The User then might choose to 1) collect/write to file by pressing a button or 2) end the stream by pressing a different button. This is why I have the DAQmx set to continuous because the user might not choose to write anything to file. If they choose to collect/write, the producer loop would run for a specified time and then end the consumer (true constant wired into last sample?) and message handling loop. The program would then precede to doing things like plotting data for a different UI.

I wanted to display elapsed time (calculated off # samples collected) on the "collect button" so I am writing to the Bool.text property.