During the preperations for our off season competition I encounterd a problem with our shooter encoder.
At the competition we worked with the E4P optic encoder but when I checked the data after the competition I discoverd it isn’t right, the encoder was mounted directly on the miniCIM’s shaft that was connected directly to the wheel that spins the shooting belt, at low RPM (to measure RPM I enterd at the BEGIN.vi 1/6 to the distance) the data was good but as we got into bigger range (3000+) the input from the encoder went crazy, sometimes there was a 1000+ differnce between two continous readings.
I decided to change the encoder because I was sure that the problem is hardware, we changed it into a AS5145B Magnetic Encoder, we connected the encoder just like the manual and WPI (http://wpilib.screenstepslive.com/s/3120/m/8559/l/91404-using-the-as5145b-magnetic-encoder-with-the-frc-control-system) said. I changed the BEGIN again to match it to the example (encoding with 4X mode) but the same problem reacured.
I placed the reading from the encoder in the Timedtasks.vi at a different loop with a 100ms delay.
Added here is the graph of the rate that I got from the encoder when I gave the motor full power.
There are two calculations you should be making when matching an encoder to a task:
- Calculate the maximum samples per second that an encoder will support. e.g.,
- Encoders have a maximum rpm that they will support, differing on the model.
- For example, if an encoder supports 10,000 samples per second.
- and the encoder produces 256 samples per revolution
- 10,000/256=39 revs per second maximum
- Calculate the revolutions per second that the cRIO will support for that model encoder. e.g.,
- The cRIO input has a limit of ~39,000 pulses per second
- So, if an encoder produces 256 samples per revolution
- And you use 4x sampling = 256*4=1024
- 39,000/1024=38 revs per second maximum
When you exceed either of these you will see odd results like the ones you are getting.
3000rpm/60 = 50 revs per second
Thank you for the explanation and information, but, is there a way to read RPM around the range of 4000-6000?
There are a few simple ways to extend the rpm range of your encoder.
- Use an encoder that produces fewer counts per revolution, e.g., pick a 64 count encoder rather than a 256 count encoder.
- Use 1x sampling in your code rather than 2x or 4x sampling.
- For measuring a shooter wheel that only goes in one direction, you can also leave disconnected the encoder B channel. Since you won’t care about determining direction the A channel is all you really need.
- Gear down the encoder shaft so it revolves more slowly than the shaft you are measuring.
So do the math:
- Calculate the maximum samples per second that the encoders must support.
- For example, an encoder that supports 10,000 samples per second
- 6000rpm/60 = 100 revs per second
- 10,000/100=100 counts per revolution maximum (so an encoder that produces 64 counts per revolution (cpr) would work at that speed, but a 128 cpr would not)
- It’s also worth noting that the encoder must be mechanically rated for the 6000 rpm you are proposing, too.
- Calculate the number of pulses per second that the cRIO will support.
- The cRIO input limit of ~39,000 pulses per second
- 39,000/100 revs per second at 6000rpm =390 samples per rev maximum
- So a 256 encoder at 1x sampling would work (< 390 samples per rev)
]A 64cpr encoder would work at 4x sampling (644=256 < 390 samples per rev)
For (3), if you disconnect the encoder B channel, you will also need to change the LabVIEW code from the encoder library to the counter library.
Thank you both very much.
I’ll try to change it to a counter and let you know if it worked as soon as i can 
*The FPGA has a 40 MHz clock.
The digital inputs are sampled every 261 cycles of the 40 MHz clock:
40MHz/261 = 153,256.705 samples per second per digital input.
If edge transitions (rising and falling) occur faster than this on any given input channel, the FPGA sampling will not be able to detect and count them properly.
Furthermore, for quadrature decoding, cross-channel edge transitions must be greater than 1/153,256.705 = 6.525 microseconds apart or the FPGA will not be able to determine which edge came first.
Example:
A US Digital 360 CPR E4P encoder outputs 2*360 = 720 total edges (360 rising + 360 falling) per rotation on each channel. So for each channel, an edge transition occurs every 1/720 of a rotation, if the symmetry is perfect (see attached excerpt from datasheet).
When using just a single channel of this encoder as a counter, and assuming perfect phase symmetry, speeds greater than (1/720)/(6.525e-6) = 212.9 rotations/sec = 12,771 RPM would cause a problem for the FPGA1.
But the symmetry is not perfect. According to the datasheet, the symmetry across the range of recommended mounting tolerance can be off by as much as 75 electrical degrees. So instead of being (1/720) of a rotation apart, some of the edges in a channel could be as close as (1/720)((180-75)/180) of a rotation apart. So speeds greater than (1/720)((180-75)/180)/(6.525e-6) = 124.2 rotations/sec = 7,450 RPM would cause a problem for the FPGA.
Assuming perfect phase alignment between channels A and B, the cross-channel edges are (1/720)/2 of a rotation apart. So for quadrature decoding, speeds greater than ((1/720)/2)/(6.525e-6) = 106.4 rotations/sec = 6,386 RPM would cause a problem.
However, for this model encoder, the phase tolerance of the the 2 channels is rather sloppy. According to the datasheet, the quadrature delay across the range of recommended mounting tolerance can be off by as much as 60 electrical degrees. So instead of being (1/720)/2 of a rotation apart, some of the edges across 2 channels could be as close as ((1/720)/2)((90-60)/90) of a rotation apart. So speeds greater than ((1/720)/2)((90-60)/90)/(6.525e-6) = 35.48 rotations/sec = 2,129 RPM would cause a problem for the FPGA.
So as Mark and Joe mentioned in earlier posts, for measuring shooter wheel speed it may better to use just only one channel of the encoder (depending on the encoder and its tolerances).
To reduce the signal noise, you should also consider setting the FPGA sample averaging as discussed here.
1the electronics in the 360 CPR E4P are limited to 10,000 RPM
*
*
I Changed our counter so it will now work with a counter instead of the encoder and I’m taking 20 samples now.
Thank you all
In case you missed this (tl;dr):
I actually read it but I wasn’t sure what to do with that because up until now when changing the average value to around that area helped getting more accurate readings (we compared the data to a Tachometer).
Could you please elaborate a little on what the bolded phrase means in this context?
Also, could you post a PNG screenshot of the LabVIEW code you use to set up and read the counter?
about the bolded: when we worked with the E4P encoder one of our team graduated member checked with me the parameters in the config timer, when we set the number 21 to Number of samples to average we got the best readings, so I thought it will be the same here.
There is another option you can consider. I did this with a different team than my own and it worked rather well.
We used the closed loop functions of the Jaguar via CAN. We used E4P’s in 4x mode spinning at 5K & 6K RPM connected directly to the Jaguar without an issue. The Jaguar is capable of 1M pulses per second.
The hardest part was tuning the PID values for the JAG.
They opted to do this because they had Jaguars, & extra E4P’s on hand so they didn’t require any additional purchases in their tiny budget for this season
Why are you multiplying the Counter.get value by 60?
Why did you choose the semi-period mode?
I want to get the RPM, according to the help from the get it is only seconds.
I wasn’t sure what to chose that was the one that seemed suited for my needs, I know that I will test it soon to see which one is the right one, but if you could help me it would be amazing
Phalanx, to do that do you need 2CAN or any other thing more than the encoder and Jaguar?
If you multiply seconds by 60 you don’t get RPM. See below for proper computation.
if you could help me it would be amazing
Try this:
The LabVIEW example linked below shows how to do that, and how to convert Counter.get to RPM:
You need to know the cycles per rev per channel for your encoder. Use that value instead of “99” in the above LabVIEW example.
Use your desired FPGA sample averaging value instead of “5”.
All has been changed.
Thank you very much!
Does anybody know what the default Cycles Per Rev per channel is for the AS5145B in incremental mode?
*
*
According to WPI (http://wpilib.screenstepslive.com/s/3120/m/8559/l/91404-using-the-as5145b-magnetic-encoder-with-the-frc-control-system) it is 1024
