LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT Clock inaccurate?

Hi,

 

I'm running an FPGA/RT application, and I've come across a timing issue. I have a 1MHz counter in the FPGA based on the 40MHz clock (although I've also used the 10MHz PXI clock divided to 40MHz and got the same result). In my RT code, I have a timed loop using either the 1MHz of 1kHz clock, operating at 1kHz. The only code in this loop is to read the MHz counter from the FPGA. The problem is, that the 1kHz timed loop is not actually running at 1kHz. Each loop takes about 1004us (from the FPGA counter). I've confirmed thisby runnig several tests, and cross checking with my digital watch (the high-tech solution) I'm monitoring this over 10-20minutes, so I get a good average.

If I run the timed loop with a period of 996us, I do get as close as makes no difference to 1kHz. If I use the Get Tick Count to time my RT code, this seems to run off the same cloack as the timed loops: ie it doesn't pick up that its all running slow. I need WAY better accuracy than this.

 

Could anyone who knows about this sort of thing help shed some light on this for me?

Hardware is an 8106 PXI controller running RT8.6, and an 7813R FPGA.

 

Thanks,

 

Andrew

0 Kudos
Message 1 of 3
(2,671 Views)

Hi Andrew,

 

In your current design you use 2 different clocks for an accurate measurement. This is always problematic. Since the FPGA clock is (usually) more accurate than the RT clock I would recommend using only the FPGA clock. You could

1) time the RT loop from the FPGA by sending the data after 1 kHz from the FPGA clock has elapsed

or

2) read the elapsed time from the FPGA along with the counter value. This doesn't improve accuracy but you can calculate the correct count frequency.

 

Hope this helps,

Daniel

 

 

 

0 Kudos
Message 2 of 3
(2,648 Views)

Thanks Dan,

 

I'm aware that running two different clocks isn't ideal, and I can cope with a little drift - the problem here is the scale of the innacuracy.

As an update, NI have recreated this issue, and it seems to be worse on the 8106 controller. A 0.4% error is way worse than the clock specifications. We've just got an 8110 controller on loan to see if that fixes our issue. Having a RT controller whose clock can be 0.4% out is pretty terrible in my opinion - its hardly real time is it!

0 Kudos
Message 3 of 3
(2,539 Views)