Weird RPM Spikes in the Typical (358) Labview RPM Calculator

Technical NI LabVIEW
1

We are using bang-bang control in a labview 10ms metronome loop. We have used this same control and RPM calculation in the past with success, and it is working fine for us this year too. But this year we are seeing huge spikes in the RPM calculation that seem to me to have a harmonic frequency. (No hard data, just watching a chart in the front panel of the vi.)

Our setup is the same we used to shoot Frisbee back in the day.

Our speed sensor is a banner photoeye, that we have 3 pieces of reflector tape on our hex shaft for the shooter wheel. This gives us 3 pulses per revolution.

In Mark McLeod’s awesome Labview tips website, :slight_smile: We have made the these changes to his code attached. In the config timer block we are averaging over 3 pulses, and in the divide by pulses we have changed the 99 to 3.

Like I said before the code is working, but the issue is we will see a RPM calc that is way over what is physically possible by the motor and shaft combination. like 1.9k RPM? These blips seem to last maybe one calculation and are gone, (no data, just looking at chart, which is moving pretty quick) but they don’t last long. :slight_smile:

Seeing we are using bang-bang, this High rpm count just means we turn the motor off, for the 10ms, which about 35% of the time is the correct thing to do, the other 65% of the time, it doesn’t really affect the system response, as they are not long duration.

So am I missing something? It seems to me that the only thing that could cause this error is in the Counter Period output, as I could not create that many pulses on the photoeye to event be close to real.

I am thinking implementing code to check if the RPM is in the physically possible range, and if not, use the last 10ms value for RPM.

Not a problem, just not what we expected?

Capture.PNG
Capture.PNG881×178 86.6 KB



Capture.PNG
Capture.PNG881×178 86.6 KB

2

Have you tried running it very slowly (probably by hand) for 1 revolution and counted the pulses? You may be getting enough light back from the faces without the tape, or other irregularities.

No chance you could be overflowing an integer type, is there?

3

When we were lining up sensors, we watched the photoeye tripped sensor, and adjusted.

We are using polarized sensors, and polarized reflectors, which pretty much eliminates the false trips on shiny surfaces.

The counter code is tough to monitor, so I can replace with a standard DIO and probe that, and report back.

As to the pulses per revolution it would take a 5 times the actual counts to get into the range we were seeing.

I also have two shooting wheels, and both wheels are seeing the same phenomenon. We also tried two other sensors, an non-polarized AB sensor and a polarized AB sensor, and had the same results. That would have been good information to include in the first post.

Oops.

The specific banner sensor we are using is the QS18VN6LP.