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.

[RVallieu]

Yes, don't write to the Boolean text property EVERY single iteration.  Create a User Event to send to the main User Event and push a message once on start of collecting and then not again until it is done and you want to change the text again.  You learn in LabVIEW Performance, Property Node writes for updates like this are one of the most inefficient ways of writing data.

I see what you are doing - so Continuous is fine if that's how you want to set up the acquisition, but I again would remove the BUILD array to keep track of the size of reads, you can get the size of each read and add up the sizes, you don't need to buffer that data unless you are using it later.  If you are using it later, you know the size that you want to buffer - so preallocate your buffer and then replace array subset.

Unless this is the last case where you are only collecting one iteration of data - don't hardwire Last Element = TRUE.  It should be decided by the acquisition logic.  You are killing your consumer on the first write.

[atrinh]

If I wanted to display elapsed time to the user, what would be an alternative to the property node hack I am doing currently? I want to be able to provide the user with real-time display of elapsed time when they press the collect button.

I should mention that build array is just accumulating data for plotting in the next state. The counting was secondary so I could display elapsed time instead of doing a tick count subtraction.

Is all of this contributing to my stream buffering error or just side things that should be done better?

[RVallieu]

Your DAQmx read is not keeping up with the Acquisition running in the background.

All of these could be contributing.

Build Array invokes the memory manager - slows things down.  Preallocate the array - it looks like you know the size you want to accumulate.

Property Node Writes - take time, slows your loop down.

Writer = Last Element hard wired to true, who knows how that is slowing things down (I can't test that this second), could be a large impact because you killed the stream on the first write and are again trying to write to the stream in the next iteration.

To update the user - accumulate the size, send a Dynamic User Event MESSAGE to the Main User Event to update an indicator or use a 0-100% slider indicator and write to the indicator itself, not a property node.  Do not use a property node write in your acquisition loop.  Typically acquisition loops are kept as clean as possible for keeping up with the read and all this ancillary stuff is done in the consumer.

[RVallieu]

Also - it is not a stream buffering error - it is a DAQmx error.

http://digital.ni.com/public.nsf/allkb/AB7D4CA85967804586257380006F0E62