Benchmarking PXIe based Data Acquisition

[falcon98]

HI,

pls find the VI snippet of the code for RT acquisition with logging. I found no difference if I disabled the graphs in the code. the cores are almost running at 98-99% load for the code.

Pls let me know if this can be further optimized

[Bob_Schor]

You're kidding me, a 14 MB picture?  It's either HUGE or impossibly tiny.

Not very helpful.

Bob Schor

[falcon98]

I thought the snippet would be helpful...pls find the vi attached ..

regards

[Ben]

Combine all of those DAQmx tasks into a single task with all of the channels.

Consider using TDMS streaming to file.

Do you really use a queue size of "1"?

Ben

[pallen]

You definitely do not want a queue size of only 1.   Your queues would all be full immediately.  This might explain why your CPU is jumping to 100% immediately. 

Try a value of -1 while keeping an eye on your queue sizes.  

[Ben]

more thoughts...

If that code is what you are actually trying to use then the math works out to "3600000" or about 3.6 MS/s. That was possible on old Pentiums.

About 2 years ago I was pulling in 400MS/s continuously using a PXIe chassis.

Go with TDMS streaming and only use the queue to share data with a graph AFTER you get the acquisition running right.

Ben 

[falcon98]

When I tried combining multiple tasks I was getting the error. In earlier posts I concluded that this might not be possible in RT systems.

Queue size of 1 was kept since I believed that larger sizes will lead to memory issues. Keeping -1 is doing dynamic allocation which is generally in efficient.

Correct me if my understanding is wrong. I will run the code and post the results again here with -1 queue size.

[mcduff]

---

@falcon98 wrote:

When I tried combining multiple tasks I was getting the error. In earlier posts I concluded that this might not be possible in RT systems.

Queue size of 1 was kept since I believed that larger sizes will lead to memory issues. Keeping -1 is doing dynamic allocation which is generally in efficient.

Correct me if my understanding is wrong. I will run the code and post the results again here with -1 queue size.

---

Since you have identical boards, combine all the channels from each board into 1 task.

Start from the beginning.

1. Go to the Help - Find Examples
2. Choose Voltage - Continuous Input
3. In the channel settings part of the example, choose channels from separate boards. (See below)
4. Look how the TDMS logging is done in the example, NO producer-consumer.

mcduff

[pallen]

The key concept here is that you're using the queue (memory) as a temporary buffer for your data.  

If you're collecting data points faster than you are processing them, then your queue will grow in size.  This isn't necessarily a "bad thing".   It can be pretty typical for short duration, acquire-analyze-display DAQ applications. 

Where you could run into problems might be a continuous DAQ application where your queue grows until your target runs out of available memory and then throws an error.   

[Kevin_Price]

I've been away from RT a while, but I expect the more memory-safe limited-size RTFIFO might be a viable alternative to a standard queue?

I seem to recall Ben posting about filling (and then emptying) the RTFIFO one time during initialization.  Thereafter, you can be assured that no new memory allocations will need to happen.  (Or maybe he did this with regular queues, and the same assurance is inherently built into RTFIFOs when you create one?).

Offering some breadcrumbs, others with recent RT experience can hopefully expand or correct as needed.

-Kevin P