Use the GetPeriod() method in the Counter class. This will give you the elapsed time (in seconds) between the two most recent pulses*. Take that elapsed time (call it T) and use it in the following formula:
RPM = 60/(T*CPR),
… where CPR is the number of counts per rev (in your case, CPR=1).
[size=]*assuming you are not running in semi-period mode
and you haven’t modified the FPGA sample averaging from its default value of 1[/size]
*
*
Not recommended. Has the potential to introduce a lot of noise, which could make speed control more difficult.
If your speeds are so high that an encoder will exceed its mechanical or electrical limits, or will exceed the FPGA’s maximum pulse detection rate, then consider a one-pulse-per-rev solution.
*
*
Nice work. Thanks for posting this. Some questions:
I’m not familiar with that sensor and magnet. How many counts per rev are you getting with that setup?
What size did you have set for the FPGA’s sample averaging1?
What are you going to use for your speed control algorithm, and at what rate will you run it?
1The default in C++ & Java is 1; I don’t know about LabVIEW
*
*
Very Cool, I haven’t seen one of those magnets before. I am going to look into trying these with our Hall Effect board, thanks for the info! Great work sharing your results too!
Ether: we get one count per rev with that magnet. I believe the student had the averaging set to 1, and period length set to 1s (need to double check the Counter class myself, see if we can get something shorter). I am anticipating doing bang-bang, and frankly, I don’t know how fast we’ll run it. One of the students put together a test program just for the shooter; when we implement speed control, we’ll leave the provision to vary parameters in real-time and run some experiments. I am really hoping to do this Saturday, depends on whether or not our Hall-Effect goodies show up. I’m going to get someone coding tonight so we are ready for Saturday.
iambujo: be interesting to see if you get comparable results with your boards. What sensor did you use?
The 6.525 us quantization of the FPGA timing of the period should give you about 38 RPM peak-to-peak jitter at 18,600 RPM with sample size set to 1. That’s about 0.2% p-p. Pretty darn good.
I am anticipating doing bang-bang, and frankly, I don’t know how fast we’ll run it.
Nice thing about bang-bang is it doesn’t care much if your control period has jitter. Since the bang-bang code is so minimal, you can run it fast without chewing up much CPU.
Our board uses the US1881 Hall Latch. I hope to get it tested at higher speeds this weekend, with the ring magnets.
Another issue, if you’d indulge…
We have a variable representing our rate, that we want to plug into the PID constructor(?), but we don’t know how to change the variable into a PIDSource.
The documentation we were able to find said that you should be able to make any sensor a PIDSource, but we can’t find how. Here’s a screen shot of the code and the errors.
Any help would be most appreciated!
FYI - I just tested our Hall Latch sensor with a ring magnet on a Fisher Price 00801-0673 motor shaft. I got the motor up to max free speed (12V from a bench supply), and the sensor read 20220 RPMs, 337 Hz on my logic analyzer. The duty cycle was about 45% regardless of the motor speed so I figure that’s based on the ring magnet’s pole alignment. I feel the US1881 is an excellent device for measuring wheel/shooter/shaft speeds at pretty much any speed we could ever want. 
How were you decoding the sensor signal?
e.g. did you have the FPGA setup to measure rising edges only, or both rising and falling?
The duty cycle was about 45% regardless of the motor speed so I figure that’s based on the ring magnet’s pole alignment.
Most likely. Were you able to measure any jitter using the logic analyzer?
I feel the US1881 is an excellent device for measuring wheel/shooter/shaft speeds at pretty much any speed we could ever want.
Indeed:)
*
*
