LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tons of "noise" and zeroing out in FPGA data

I'm acquiring RPM data on a cRio 9014 with the 9118 chassis, with an NI 9201. Eventually we will collect 5 pieces of data, RPM, Speed, Torque, Voltage and Current all connected to the NI 9201. Something interesting is happening when we're trying to collect RPM data.

 

 

 

 

 

IMG_20190128_170203.jpgWe have an array of 8 here indexing from 0, responding to analog inputs 0 to 7, with 7 being the RPM sensor. When we try to obtain data with the program like this, our graphs are filled with "noise" and zeroes itself down, etc.  For example, here is a graph where I increased the motor RPM from 0 to 6000rpm and held it still for a solid 5-10 seconds. You can see the graph increase, and then flatten out at the top but still have spikes here and there.

IMG_20190128_170114.jpg

What could be causing this? 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0 Kudos
Message 1 of 8
(2,486 Views)

Here is something odd I see.

 

In your FPGA you have a timeout control that is set to 5, and you write that to the timeout value of the FIFO Write.

 

But in your host code, you have a write to that timeout control, but the value in the control is defaulted to zero.  Are you changing that before you start the VI? So when that is passed to your FPGA before the loop starts, a zero would get written to the FIFO Write timeout. 

 

It seems like that might cause problems.

0 Kudos
Message 2 of 8
(2,465 Views)

Yeah that does cause problems if not set correctly. It's measured in uSec but I've just been lazy and haven't set the default

0 Kudos
Message 3 of 8
(2,444 Views)

Are you sure it's not clock ticks?  1 clock tick is 1 usec on a 1 MHz clock.  But many of my FPGA's are on a 40 MHz clock.

0 Kudos
Message 4 of 8
(2,439 Views)

Wait yeah you're right it is in clock ticks. Our FPGA is also on a 40 MHz clock. So is 1 clock tick still 1 usec here, or is 40 clock ticks 1 usec? 

 

also, something interesting, when I disconnect all the other analog inputs right before the TDMS file write method, the program works a lot better.

 

 

 

 

 

IMG_20190128_170158 (1).jpg

 

 

 

 

IMG_20190128_170244.jpg

 

IMG_20190128_132228.jpg

 

 

 

0 Kudos
Message 5 of 8
(2,430 Views)

Correct.  40 clock ticks would be 1 usec on the 40 MHz clock.

0 Kudos
Message 6 of 8
(2,428 Views)

so for timeout control, for 5 sec, i would have 200000000 clock ticks. Just tried that and while it's a little cleaner, we're still getting ups downs and etc. Did I do the math correctly?  anything else that could be the problem?

 

IMG_20190129_113907.jpg

0 Kudos
Message 7 of 8
(2,425 Views)

Since I wasnt the one who wrote the original program I'm still a little lost as to what the timeout control is supposed to be. It's "5" in the .vi that goes into the FPGA, that's 5 clock ticks and not 5 seconds right? So, isnt the host vi also supposed to be "5"?

 

I also tried compiling no timeout on the FPGA side and, like expected that didnt do much other than stop recording data in 2 seconds. 

0 Kudos
Message 8 of 8
(2,424 Views)