12-19-2014 09:40 AM
Hello. I am looking for help increasing the execution speed of the attached VIs. The equipment is a PXIe-8135 controller running LVRT, PXIe-6368 DAQ, and PXIe-7966R FPGA. I am using a hardware timed, single point data acquisition loop that will eventually implement some sort of feedback control, and I need the highest possible rate (ideally above 100 kHz). Leaving out the FPGA, I was able to run the loop at 200 kHz on the real time PXI target. However, incorporating the calls to the FPGA has cut that down to about 60-70 kHz. (The FPGA is needed because multiple channels will be added and the computation might get more involved than the RT processor can handle quickly.) Here are some specific questions.
1. Data conversion. Now I am reading data from the DAQ as a floating point double, but then I need to convert it to send data to the FPGA. I am not sure if converting to fixed point rather than single is more efficient? Or should I try reading raw I16 data from the DAQ? I believe this creates an array of integers, so it might be slower?
2. Data logging. If I turn on data logging, the rate is drastically reduced. Is using the built-in TDMS logging from the DAQmx pallete not the best option? This usually works better for me than a parallel data logging loop with local variables.
3. FPGA polling. Would another method be better? For single point transfers, I didn't think DMA FIFOs are the right approach. I did try the IRQ interrupt method, and it was slightly slower.
I really appreciate any suggestions. Any little tweak will help at this point. Thanks for your help!
Jeff
12-19-2014 10:13 AM
Shouldn't you do the DAQ directly on the FPGA?
12-19-2014
10:31 AM
- last edited on
03-19-2025
02:50 PM
by
Content Cleaner
You are going the expensive route! Are you using any of the IO on that FlexRIO board? If not, you are totally going in the wrong direction with this.
Why not just go with something like the PXI-7854R, which can handle your analog inputs and outputs. And it is cheaper than that DAQ card. Then all of your acquisition and control logic can happen on the FPGA. You just have to use a DMA to send the data to the RT system for logging.
12-19-2014 10:58 AM
altenbach: Here the FPGA and DAQ are different cards on the PXIe chassis. The FPGA cannot directly access the DAQ, unfortuately.
crossrulz: Tell me about it! That's why I'm trying to get this to work without buying anything else... Thanks for the link, though. I will look at that module and keep it in mind. I'm not using the IO on the flexRIO board. I also looked at adaptor modules, but the current DAQ board is so nice (and expensive). I can't change the hardware unless it is the only option.
12-19-2014 11:10 AM
Let me put it this way. If you spend $7k in your time (at $100/hour, that is about 2 weeks) trying to get this to work the way you want, it would have been cheaper to just buy the new card.
You might want to talk to your local NI rep. If you just recently bought those cards, they may let you return them and then buy this new card.
12-19-2014 01:02 PM - edited 12-19-2014 01:07 PM
You're at the edges of performance here. I'm afraid it's a lot of trial and error out here. You might need some system engineering support from NI or a third party. With that said, I have some ideas:
12-19-2014 03:22 PM - edited 12-19-2014 03:23 PM
Is there any reason you serialized the operations in the main loop of your host VI? You could probably increase your loop rate if you parallelize the DAQ to FPGA and the FPGA to DAQ operation. Also, get rid of the 'data ready' and 'read data' coming to and from the FPGA. If its a control operation, it doesn't seem like a problem if you read or write the same value twice so long as it is still the most recent value.
Crossrulz seems on the money though. A FlexRIO is as nice as FPGA co-processors come, but an R-Series card with mixed IO will be the best tool for the job. The 7854R he linked you will get you loop rates approaching 1 MHz and response times in the microseconds. With the DAQ-to-Host-to-FPGA-to-Host-to-DAQ configuration you're looking at, its not just update rates you need to consider, but also latency. Trying to read-analyze-write with this confuguration may get you update rates somewhere between 10-50kHz, but I'm guessing you'll still get millsecond response times.