LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programming FPGA, unable to achieve the desired sampling rate

Solved!
Go to solution

I have the following hardware:

  • sbRIO9267
  • two NI 9205 C-Series Modules connected to the sbRIO via a 2-Slot C-Series RIO Mezzanine Card (RMC)

I want to sample 10 Channels on each of the 9205 modules @ 25 kHz per Channel. This is right on the edge on what the 9205 Module is able to do (250kS aggregate sampling rate). Therefore the 9205 modules are configured with a 4μs conversion time in the project explorer.

 

This is the Vi I use on the FPGA

FPGA viFPGA vi

Since the FPGA executes with 40 Mhz I need to set a execution rate of 1600 ticks for the data acquisition loop of the FPGA vi. However, the measured true execution rate then is only 1601 ticks giving me a frequency slightly below 25 kHz.

Why is this and how can I solve it?

I quickly tested the 9205 in a cDAQ and set of 10 Channels @25 kHz and this was running without problems, so I assume my problem is a programming problem of the FPGA-VI and not a hardware limit. For every sampling frequency below 25 kHz (every execution rate higher than 1600 ticks) I get the expected sampling rate from the FPGA.

edit: corrected typos

 

0 Kudos
Message 1 of 8
(3,772 Views)

Hi tnemitz,

 

have you tried to read each module with its own IO node?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 8
(3,761 Views)

So, you are running the FPGA at 40 MHz and sampling the AI for Mod1 and Mod2 every period defined by 'set rate'? For sample rates up to 25 kHz the system works as expected. When you ask for samples every 25 kHz you see a 1601 rather than the expected 1600 true ticks? I suspect the problem is in the implementation of the wait timer and tick counter rather than the code itself. Do you know if the data is really not sampling at 25 kHz?

 

I prefer to use timed loops rather than waits to control loop timing. I can see a couple of alternative implementations using timed loops:

 

1) Use timed loop and down clock the FPGA

Define a clock derived from the 40 MHz clock and use this to define a timed loop. Operate the timed loop only at the rate you require e.g. 25 kHz. This will require a recompile everytime the loop time needs to change!

 

2) Use timed loop and use logic to send to host

Use the 40 MHz clock to define a timed loop and use a counter and logic to choose when the output is set to the host. The counter threshold that causes output can be controlled by a front panel object from the host. Use a 'greater than' condition on the threshold rather than 'equal to' to account for message timing errors.

CLA - Kudos is how we show our appreciation for comments that helped us!
0 Kudos
Message 3 of 8
(3,750 Views)
Solution
Accepted by tnemitz

@GerdW wrote:

Hi tnemitz,

 

have you tried to read each module with its own IO node?


Thanks for your suggestion, that didn't help though.

@MaxJoseph wrote:

So, you are running the FPGA at 40 MHz and sampling the AI for Mod1 and Mod2 every period defined by 'set rate'? For sample rates up to 25 kHz the system works as expected. When you ask for samples every 25 kHz you see a 1601 rather than the expected 1600 true ticks? I suspect the problem is in the implementation of the wait timer and tick counter rather than the code itself. Do you know if the data is really not sampling at 25 kHz?

 Correct, this is the behaviour described. I knew the data is really not sampling at 25 kHz since i calculate the number of samples to read from the FIFO on the host side with the number of ticks I set for the execution rate. The Number of Elements in the FIFO on the host side is slowly decreasing, meaning that the FPGA writes less elements than expected to that FIFO.

I prefer to use timed loops rather than waits to control loop timing. I can see a couple of alternative implementations using timed loops:

Whats the advantage of the timed loops compared to the loop timer?I

 

I did some changes in the FPGA Vi and the problem seems to be solved. I think the problem was, that the reading from the ADC needed already 1600 ticks (due to the conversion time of the multiplexer) and the loop timer in the extra frame of the structured sequence used one additional tick. Moving the loop timer outside of the sequece solves it. The working Vi is attached for future reference.

 

 

0 Kudos
Message 4 of 8
(3,714 Views)

You can use pipelining to parallelize sampling and execution.

0 Kudos
Message 5 of 8
(3,708 Views)

@christian_w wrote:

You can use pipelining to parallelize sampling and execution.


Yes. Partially thats already implemented with the feedback node between the FPGA I/O node and the FIFO Write. However, I'm not sure, whether the design from the first post can be parallelized regarding the loop timer.

0 Kudos
Message 6 of 8
(3,704 Views)

Yeah, I figured that the problem might be something to do with the timer function. But I'm not familiar with using them so I don't know best practice! I'm glad you fixed your problem!

 

I think the main reason for preferring timed loops to loop timers is just what I started using first. I am not a fan of sequence structures in labview, due to their non-parallel/anti-dataflow nature. So I never liked the LV examples which use them in FPGA to control loop rates. I suspect loop timers add some overheads and hidden complications, like the ones you saw!

 

To control my loop execution rates I used single cycle timed loops instead, which is also useful in ensuring that multiple loops are all operating synchronously. I'll admit that SCTLs probably aren't the best way to for many applications though! The requirements of my applications are pretty high; several SCTLs operating across clock domains where the slowest clock is 62.5 MHz!

CLA - Kudos is how we show our appreciation for comments that helped us!
0 Kudos
Message 7 of 8
(3,700 Views)

Could you please post the same with version 16.0

0 Kudos
Message 8 of 8
(3,549 Views)