LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using C-series DIO module in SCTL with slower clock than top-level [FPGA]

Solved!
Go to solution

Hey all,

 

I'm running into a problem that I've not had much success searching online.  

 

I've got a 9030 chassis with an FPGA built in, top-level clock 40MHz.  I've got an NI-9401 DIO C-series module plugged into it and set to be managed by the FPGA target.  I need to count some linear encoders at exactly 10MHz, no more, no less.  They are clocked and give an output in such a way that if I oversample or undersample, I get garbage.

 

If I create a SCTL and set it to a derived timing source of 10MHz, I get a code generation error that:

 

"The Read FPGA I/O Node  for DIO3 is used in a clock domain that it does not support.  The supported clock domains include: the top-level clock and any clocks that have a rate that is a multiple of 40 MHz, such as 40 MHz, 80 MHz, 120 MHz, and so on."

 

I tried a few ways to get around this; first I tried just using a while loop with a loop timer set to 4 ticks, but it then takes 9 clock cycles to execute the counting for some reason (though this code can compile in the SCTL with no problems).  I then tried using the SCTL with a "true" constant wired to STOP as a hack for a "timed sequence" frame, and that definitely did not work.

 

Are there any strategies or techniques or settings somewhere to get around this limitation on the DIO  that I need to sample at exactly 10MHz?  I would love to do this quickly in software and get this rolling ASAP.

 

An image of the relevant section of code is attached, I'm happy to provide more stuff upon request.

 

Many thanks!

Maia Bageant

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

Which encoder are you using, out of interest? Most clocked output encoders can be oversampled...for instance, all my encoders are clocked to 20 MHz, and I run at 80 MHz to ensure I don't miss any counts (Nyquist plus HW propagation delays).

 

I would imagine you'll either need a feedback node or shift registers for the previous iteration's quadrature states too 😉

---
CLA
0 Kudos
Message 2 of 3
(2,824 Views)
Solution
Accepted by topic author phototr0pe

Thanks for the reply!  The problem ended up being a hardware problem based on how the encoders were connected.  Now that I've fixed it, they're perfectly happy being oversampled.

 

I guess my question is still legitimate for other applications, but not necessary for the encoders one.

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