We are planning on using an encoder on our shooter design to determine actual RPMs. Do I need to worry about interrupt load on the processor if I have the combination of a fast (~5000RPM) shaft and a high resolution encoder. I was thinking of trying to get a reduction gear in there to reduce the RPM and then go with a low res (32 ticks/rev) encoder.
Are the considerations the same if I connect the encoder to the Talon SRX instead of the Rio??
I believe that the FPGA hardware takes care of processing the encoder pulses which minimizes the need for interrupt processing on the main processor.
I don’t remember what the limit on the number of pulses the FPGA can handle is but it’s in the tens and maybe even hundreds of thousand pulses per second. Try it for yourselves.
Did you look at the specs in the Talon SRX User’s Guide?
http://www.ctr-electronics.com/talon-srx.html#product_tabs_technical_resources
I see nothing in the talon SRX documentation that indicates if I need to worry about throttling the encoder pulses, but it’s good to know that the RIO can handle it.
I’m still going to try to mitigate the volume of data through mechanical design.
More specifically, look at the max quadrature CPR and RPM in the Talon SRX user guide.
FYI, we ran the new Versaplanetary CTRE Mag encoder in relative mode, with 1:1 and the new 755Pro motor last Saturday.
Gave motor %Vbuss mode, and a motor output of 1, and the encoder reported 15,0000+ rpm which matched our optical handheld tach.
The roboRIO FPGA can track encoder edges at 25 ns from edge to edge. It will also calculate and report rates at the same resolution. I suspect this is more capability than any team needs, but I’m always interested to hear about teams pushing the boundaries.
There was a very lengthy discussion about jitter, sampling, and RPM calculation in 2012. To make a long discussion short, if you are using the period function in LabVIEW, you may actually be better off with a 1 count per rotation encoder to maximize the period and make your RPM calculation more accurate. We used it very successfully in 2012, and 2013. This will also eliminate any worries you may have about loading the roborio.
This is somewhat counter-intuitive if you are thinking about calculating RPM using “number of ticks” divided by time.
While much of that discussion still holds to some extent, much of it is not all that applicable given the roboRIO’s vastly faster DIO, unless you have a blindingly fast encoder signal.
The roboRIO and the cRIO does / did all quadrature decoding in the FPGA. It incurs no more or less load on the system sitting unswitched vs. switching quickly.
Joe, do you know exactly what the pulses per second rating for encoders/counters in the FPGA is? I remember that the cRIO was right around 40,000, and I remember hearing that the RoboRIO was in the realm of 100,000, but I would like to know for sure. It would also be nice to have this documented somewhere if possible.
EDIT: Nevermind. I didn’t see the 25ns number above. Does that mean that that the RoboRIO can take 40,000,000 edge to edge pulses per second, or am I screwing my math up somewhere. That number just seems incredibly high, but I could see it being that high.
It means the roboRIO samples the edges at 40MHz, and timestamps them with a 40MHz clock (25ns resolution) when detected.
So no, you wouldn’t get a usable reading at 40M edges per second.
Note: back in 2012, the cRIO FPGA took samples at only 153KHz, and timestamped them with a 1MHz clock. That’s why we had all the discussions back then.
If you look at “roboRIO Specifications” linked from here, in the Digital I/O section on page 4, it references “minimum pulse width”. That’s the hardware limit. The FPGA implementation uses a 40 MHz clock as the timebase to run the decoder logic and the I/O logic. That means the FPGA is the limiting factor by a small margin. There are complications (discussed earlier) with respect to the sampling and ensuring no two edges are detected in the same sample period. To ensure that is avoided, divide the rate by 2. That means 20,000,000 edges per second should be guaranteed to decode. That edge rate would mean 5,000,000 rising edges on the A encoder output per second (assuming very small phase error in your encoder both A to B and rising to falling).
It is incredibly high… by comparison to the previous system anyway.
Hello My team is trying to use the VersaPlanetary Integrated Encoder to reach about 12000 rpm. The documentation on vex pro says 15000 rpm max but looking at the talon SRX software documentation says 10000 rpm max and we seem to be maxing out the rpm.
The mag encoder spec says 15000rpm, not 10000rpm. Section 1.4 in Mag Encoder User’s Guide.
The 10000RPM in section 7.5.4 in SRX Software Reference Manual is a typo. I’ll fix it soon.
And also…
Thanks, still can’t seem to get it work are current using java and have set the feedback device to ctre mag relative and are unable to read an rpm above 5000 we are using java any suggestions
Edit.
We updated the firmware and it worked. facepalm