flywheel counter rate stuck at 0

hi!
we are trying to program a PID flywheel shouter with a one channel encoder (ie counter, ya know).
the hardware is connected well, but when the flywheel speed goes above 10 rotations per second the rate from the getRate() method of the counter just stops and turn to 0, so we can’t track the wheel’s speed.
we want about 25-30 RPS so it is a bit of a problam now. the sensor can sense in this frequency, and i am pretty sure the roborio can handle it as well… what could be the problem?
thanks in advance

What is the number of ticks per revolution?

We had a drive encoder do something similar (though at a lower speed). At some point, the encoder wheel would get caught on something in the enclosure and disengage from the shaft.

Whether it’s that or something else, if you have an oscilloscope or even a multimeter with a frequency counter, you can see if your encoder is actually generating the electrical signal or not, helping zoom in on the problem.

50 ticks per revolution

So you’re running at 1500 ticks/second at the upper end of your desired speed, but the encoder falls to 0 at about 500 ticks/second.

I’m wondering if you’re running up against something in software, or the encoder just isn’t rated for that kind of tick speed.

What encoder are you using? That could help inform recommendations.

Not an actual encoder, but a photo microsensor with a round steel plate with 50 holes in it on the shaft of the wheel. (Not “homemade”, the holes are accurate)
The sensor is from this series:

they are rated for a response frequency of 1khz, but the thing is that on our last robot we have been able to maintain a speed of 29 rotations per second with exactly the same hardware, using the same method in code, but now it wont work above 12 RPS… i will try to measure it with an osiloscope or something as soon as i can, but do you have any idea what could be the problem if it isn’t the sensor’s abillity?

Note that the spec sheet says “repsonse frequency * 2”, which implies counting both rising and falling edges. You’re right at the rated minimum response frequency when you drop out. You may just have a sensor that is down at the min rather than the average of 3 kHz. If so, either get a faster sensor, or use fewer holes.

Thanks everyone for your help!
I will try to find a faster sensor. Its still weird that this sensor worked for so long XD

The ‘average’ sensor of that type will handle 3K … which translates to 30rpm.

It just so happens that this sensor is at the minimum (1K) of the spec.

There is a good lesson here about tolerances and what area of the spec you should be looking at

wait, let me get this straight: the manufacturer wrote 1K as a minimum frequency while the avarage sensor of the same model can reach 3K or more?
we have at least another 3 of those exact sensors lying around, should i try another one?

I would try another, yes.

But in the real world, when choosing a part to put into a product, I would take worst case scenario (in this case 1K) and give a safety margin.