high speed tracking

[Bendito]

I hadn't realized that the 5 for averaging correlated to how many ticks there were per RPM, thought it was just a sort of buffer. The setting used for 1 'tick' is the "CountsPerRev" division after each counter get period (see attachment). We are running a shooter wheel off of a CIM motor between 3800 RPM and 5000 depending on our setpoints (still tweaking what works best). At full throttle, it reads around 5000, which matches up with what I would expect from a CIM motor.
It is currently a photoeye looking at 50% reflective tape, and 50% not, contiguously around the wheel. We are considering getting better resolution by breaking it up into 4 or 8 equally dispersed chunks, in which case "CountsPerRev" would be increased to this number when we read "Period(sec)" from the CounterGet VI.

The other cases shown are just overrides in case of shooter sensor failure to simply pipe a percentage value to the motor (detects a small setpoint, which means a throttle value is desired instead of RPM).

[Ether]

Originally Posted by Bendito

We are considering getting better resolution by breaking it up into 4 or 8 equally dispersed chunks, in which case "CountsPerRev" would be increased to this number when we read "Period(sec)" from the CounterGet VI.

3800 rpm = 63.33 revs/sec = 15.8 ms/ rev.

If you are running your speed control loop at 20ms, you'll get a fresh reading every iteration.

And, there's an advantage of using only one piece of tape: there is no noise due to tape positioning tolerance since you are always reading the same edge.

[Ether]

Originally Posted by Bendito

We are running a shooter wheel off of a CIM motor between 3800 RPM and 5000 depending on our setpoints (still tweaking what works best). At full throttle, it reads around 5000, which matches up with what I would expect from a CIM motor.

If your CIM is geared 1:1 to the flywheel, you will not not able to control the flywheel speed at 5000 rpm. There is no voltage headroom for your control algorithm to work.

[Mark McLeod]

I use the Number of Samples to Average to account for placement error of the reflective strips. One full average always equals the same start/stop rising edge.

# of strips (thought about it some more)

By the way, in the last code example the In Range and Coerce function has it's upper limit disabled (by default).
That's why it's a clear box, rather than a filled box like the lower limit has.
Right-click on the function and choose Include upper limit

[Bendito]

Good advice, we were not planning on running at 5000, closer to 4000 at realistic max. We have had around 30%-40% headroom roughly. I was just testing how fast it would go. It does seem to work with 1 tape segment, I just overheard someone in another thread suggesting more resolution for a similar application.

The averaging of samples to number of ticks in one revolution makes sense now, thanks! Of course, with 1 tick, having a few averages shouldn't hurt, but really shouldn't be necessary now that I think about it.

Now just to properly tune the PID so that it gets to the correct speed quickly without oscillation (hint to anyone with this problem, an additional offset added to the output can help get up to the proper speed range without cranking P too hard into oscillation territory) That's tomorrow's project.

Thanks for the advice.