A Graphtec GL820 data logger user could not understand why the resolution of the instrument was not better than 60 RPM. He connected the output of a reflective tape sensor to a discrete input programmed for REVOL, which applies an automatic scaling operation as follows:

Clearly from the above equation, RPM resolution can be no better than 60 RPM when only one pulse per revolution is present, which it was in his case. Regardless of how fast the shaft turns, resolution remains the same: 60 RPM. There are two ways around this problem.

The first and best solution is to add more pulses per revolution. If we double them to two, resolution increases to 30 RPM. Configure 60 pulses per resolution and resolution increases to 1 RPM. Of course, in some situations you may not have the luxury to increase pulses per revolution. Maybe the shaft diameter is too small, or maybe you’re simply out of reflective tape. Whatever, your only second option is to increase the sampling period.

Another way to determine RPM is to count pulses over an extended sampling interval (like several or more seconds), divide the count by the interval and multiply by 60. This approach is perhaps the only solution when very low RPM values with a single pulse per revolution are encountered. For example, assume a shaft turning at 113 RPM produces one pulse per revolution. Using the preferred approach above resolution is 60/113, or a horrible 53 percent of the full scale RPM range, and not at all useful. However, if we count revolutions over a 15 second interval we’d accumulate a total of 28 pulses. Dividing by the sampling interval (15) and multiplying by 60 yields 112, very close to the actual RPM value. The penalty of this approach, and in this example, is that RPM is updated only once every 15 seconds. That’s the price you pay for accuracy with only one pulse per revolution.

## One Comment

Qnet

I designed 12000 real time rpm using ladder logic and without help of HSC