Maximum rate for encoders hooked to cRio?

What is the maximum pulse rate from an encoder that the cRio can read? Will this drastically affect processor time?

We’re looking at running 2 encoders at a fairly high rate (1400+rpm) which will result in a pulse rate of around 360X28=10080 pulses /second.

See the short discussion here.

The other thread gave rates, but it wasn’t explicitly stated that the encoders are polled by the FPGA and cause no interrupt traffic to the CPU.

Greg McKaskle

Its my understanding that only certain all Digital Side Card DI channels have interrupts handled by the FPGA (something line DI1-4). Anyone confirm this or know where that is documented ?

Looking at the LV API, it appears as though any channels can be used for encoders, and again, no interrupts are used, the digital lines are polled. It is possible to get the FPGA to raise an interrupt based on the state of a digital line, and it appears that all lines are possible.

You may be thinking of the analog resources as only the first two channels ont he first module supports accumulation of gyro.

Greg McKaskle

If the DI lines are all only polled by the CPU, then the I/O rates would be a small fraction of the 35,000 I/0s /sec rate the FPGA can handle. Ouch

What do you mean, Dave? The FPGA “polls” all its inputs simultaneously.

The FPGA supports 4 encoders in 4x mode. These can be any of the DIO pins. It also supports 8 encoders in 1x or 2x mode or counters on any DIO pin.

No. The FPGA handles the polling of the encoder pulses. It is separate from the CPU. The FPGA counts and times the pulses, then provides that info to the CPU (when your software asks for it).

What is the maximum pulse rate from an encoder that the cRio can read?

The FPGA polls the DIO channels at 153257 Hz, so the FPGA can count edges that are no less than 6.525 microseconds apart.

Also, for a quadrature signal, the edges from both channels must be at least that far apart from each other, or the FPGA will not be able to tell which channel’s rising edge occurred first.

So the max rpm depends on how your encoder is configured. For example:

US Digital 360 CPR E4P encoder.

Each encoder channel is connected to a separate DIO channel.

The encoder has 360 rising edges plus 360 falling edges on each channel (total 720 edges per channel)

Assume perfect 90 degrees phase between the 2 encoder channels.

Instantiated from the Encoder class as 4X.

Theoretical maximum encoder speed that the FPGA can process with the encoder in this configuration:

60153257/(4360) = 6386 RPM

However, per the encoder datasheet, the typical installed tolerance for the
quadrature phase is 90 +/- 10 degrees. Assuming it’s 10 degrees off:

60*153257/((180/(90-10))2360) = 5676 RPM

Per the encoder datasheet, the maximum installed tolerance for the
quadrature phase is 90 +/- 60 degrees. Assuming it’s 60 degrees off:

60*153257/((180/(90-60))2360) = 2129 RPM

Since we have gone this far, it sounds like the FPGA and 9403 I/O card are cponservatively capable of say 5000+ rpm per quadrature encoder. Hopefully the encoder and the Digital side car D/I electronics & the cable to the CRio bandwidth are also rated for those rates. Note a grayhill 61R256 encoder is only rated for 300 RPM.

A quad encoder takes 2 of the 14 DI ports so does that mean the system could handle 7 quad encoders each running at 5000 rpm ? (or is there a limit in wpilib but not in the CRio / fpga for example).

It also sounds that if you are not using quadrature encoding (ie only single rising edge detection) and only using a single DI port (ie don’t need to know the rotation direction), 14 channels of 10,000 RPM (at 256 rising edges per revolution: or 2,560,000 rpm at a single rising edge per revolution (as long as the 6.525 microseconds is maintained ? ) ?

perfect conditions example assuming 6.525 us for up pulse, 6.525 for down, single pulse per rotation, 0 phase error max RPM might appear to be 60 / (2 * 0.000006525) = 4.8M rpm. Sounds like I have something wrong here :frowning:

Just trying to understand the envelop of capability of the Crio/FPGA product.
Back to building robots and trying to do pid on a 7200 rpm motor.