Coustom Quadrature Encoder VI
 

I've been working on a VI to read counts from an encoder and get direction. I was looking for general feedback on it. Also, what would be a good way to get the period between pulses for a speed calculation?

Re: Coustom Quadrature Encoder VI
 

Every time you see a rising edge, take the difference between the current time and the previously stored time. Then store the current time over the previous to be used at the next rising edge. This difference is the period between rising edges. Then you can take a rolling average over a user-defined sample size to smooth out noise.

But how fast do you expect this loop to be running? Are you compiling this vi as part of an FPGA image, or will it run in software? Make a rough calculation of what the period of your encoder will be in your particular application, and make sure the loop containing this VI can keep up.

Re: Coustom Quadrature Encoder VI
 

Why?

Your reasons for ignoring the FPGA-supported quadrature decoder and rolling your own will shape the advice I can give you.

Re: Coustom Quadrature Encoder VI
 

I wanted to learn how/practice. I'd rather output raw encoder counts for my distance. I can modify it to my parameters and understand what it's doing. It is easier to teach others how this works at its core. Understanding the algorithm means I can export it to another language and devise.

That said I would really like to know of better ways to implement this in LV on the C-Rio & RoboRIO.

No idea, I intend to test how it will work with different setups in the coming weeks and, didn't know about "compiling this vi as part of an FPGA image" can you elaborate?

Re: Coustom Quadrature Encoder VI
 

As Alan said, if this is running on FRC hardware, you should really use the FPGA-packaged solution provided, with the interface given in WPILib.

If you need to access raw counts, the Encoder VIs should expose this (the Java and C++ libs do), though I don't have an FRC copy of Labview in front of me to confirm. If not, you can always divide distance by the distance per count you gave the Encoder Open block, though this is not ideal.

The FPGA is a large reconfigurable logic circuit (Field Programmable Gate Array). This means we can design (just about) any network of logic gates in a language like Verilog, VHDL, or even LabView (or just about any hardware description language), and then compile this "code" into an image for the FPGA. Imaging the FPGA reconfigures it to match this circuit design. This means that the operation of your "code," i.e. your circuit, is just as fast as hardware (or almost as fast), but you can still reprogram it without manufacturing an entirely new chip. However, in FRC, we are required to use the FPGA image provided by NI and FIRST, which already does a lot of useful stuff, like count encoder counts. Everything we do has to be in software on the CPU.

Encoder counts go by pretty fast. Even at FPGA processing speeds, we can't have shafts spinning anywhere upwards of 15,000 rpm for the typical US Digital encoders. Depending on a number of things, that limit is probably substantially lower, between 5,000 and 10,000. If instead of "looping" at 6 microseconds in the FPGA you want to loop at 6 milliseconds in software, your limit drops by a factor of a thousand, so now you can't spin the encoder shaft faster than about 5 or 10 rpm. And that's just not very exciting.

Re: Coustom Quadrature Encoder VI
 

Before you set out to write your own encoder library, why not take a look at the source code to the WPILib one first?

If you drop the Encoder Get, you will find code implementing the math pretty much the way you described. If you go a level deeper into the read of the encoder counts or the times, you'll see some purple nodes that are register reads from the FPGA into the the CPU.

So the FPGA's job is to compare edges on the digital lines and increment or decrement accumulators. It records the direction and time of the last edge. The FPGA doesn't do the final math since that involves floating point and doesn't need to happen at the same rate as the comparisons.

On the roboRIO, the digital will not be limited by the module that was in the cRIO, and the digital portion of the FPGA will run much faster. The math to scale, filter, and make the counts meaningful will still happen on the CPU.

So, please look through the VI and see if the math makes sense to you. Btw, the FPGA is clocked at 40MHz, so that may help decode some contestants in the code.

Greg McKaskle