Am I doing too much while acquiring data on CRIO 9045?

[FlyingSquirrel123]

Hello,

I am trying to acquire data on a CRIO 9045 and process it at the same time. It could be that I am asking too much out of LabVIEW Real-Time, but I would still like to investigate. The code is running on the CRIO 9045. There was more processing going on in the loop, yet I've slimmed it down and it still does the same thing. It acquires data as it should for about 5 seconds, then stops. The code stays in the loop but the DaqMX Read vi stops updating and it defaults to 0.

If I slow down the sample rate it runs fine, however it would be beneficial for me to run at a higher sample speed for my application.

Is there something I am missing or is this too much for the CRIO to handle?

Thank you

[mcduff]

---

@FlyingSquirrel123 wrote:

Is there something I am missing or is this too much for the CRIO to handle?

---

There is overhead with each call to acquire data. If you fetch one point at time, the overhead will start to interfere with acquisition if the rate is too high, as you have observed.

Take 100 ms seconds of data at a time. Analyze it in a separate loop. 

Is there a reason to only acquire 1 point at a time? 

[ZYOng]

It is more efficient to read a larger chunk of data. 

If you are using Continuous Sampling mode for streaming, I would recommend reading data at the rate of100ms. For example, if the sample rate is 10kS/s, call DAQmx Read to return 1kS of samples.

If you want to read only one sample at high speed for control purpose, use Hardware Time Single Point mode.

[crossrulz · Accepted solution]

---

@FlyingSquirrel123 wrote:

I am trying to acquire data on a CRIO 9045 and process it at the same time. It could be that I am asking too much out of LabVIEW Real-Time, but I would still like to investigate. The code is running on the CRIO 9045. There was more processing going on in the loop, yet I've slimmed it down and it still does the same thing. It acquires data as it should for about 5 seconds, then stops. The code stays in the loop but the DaqMX Read vi stops updating and it defaults to 0.

---

It is not the cRIO that is limiting you.  It is software timing trying to keep up with hardware timing.  Generally speaking, whether a high-end PC or a cRIO, anything running at more than 100Hz needs to read multiple samples at a time.  The general rule of thumb for DAQ is to read 100ms worth of data at a time.

Additionally, I recommend using a Producer/Consumer setup.  The idea here is you have one loop getting data from the DAQ and passing the data into a queue.  Another loop then reads the data from the queue for processing it.

[GerdW]

Hi Squirrel,

---

@FlyingSquirrel123 wrote:

It acquires data as it should for about 5 seconds, then stops. The code stays in the loop but the DaqMX Read vi stops updating and it defaults to 0.

Is there something I am missing ?

Yes: you are using a shift register to hold the error wire!

Once an error pops up all the iterations after that will have an error in the wire and so DAQmxRead will do exactly "NOTHING"! Additionally you don't handle the error inside the loop...

[FlyingSquirrel123]

Thank you everyone for the help, I ended up using 100 ms worth of data instead 1 point at a time. I was originally using a producer/consumer loop with the producer loop sending overlapping 2 sec worth of data at a time to a consumer loop. Now I collect 100 ms worth of data in my producer, stich it back together in my consumer with a queue, then process it in another loop with a notifier. Producer->Consumer->Consumer