I can’t be the only one who’s missing this functionality from the standard Encoder blocks. This VI takes an encoder reference, gets the ticks/second, and multiplies it by the configured DistancePerCount property to get the rate of the encoder in feet/second, or inches/second, or whatever else you configured it with.
Honestly, I’m surprised this functionality isn’t included already…
Get Encoder Rate (Engineering Units).vi (22.2 KB)
Get Encoder Rate (Engineering Units).vi (22.2 KB)
While the documentation says that the encoder get returns hz, if you look inside, it gets multiplied by the DistancePerPulse. I think that makes your VI unnecessary, although I haven’t tried it.
Hmm, that’s interesting. My experience has shown that the Rate output of the Get VI does in fact output Hz and not engineering units. At least, it certainly seems to always output integer values, not the decimal values I would expect from a measurement in inches or feet per second.
But looking at the code, it certainly does seem to be multiplying by DistancePerCount…I’m confused.
I can verify both that it returns “distance” per second as computed from the specified distance per count, and that it always seems to be an integer value. Our “distance” is scaled to represent 60 times 1/250th of a revolution, so we get RPM directly from the rate output, and being an integer has never been an issue.
So is the documentation faulty? It would seem that the rate output is not measured in Hz as the documentation states.
We set the DistancePerCount property value to 1. That gave us the rate in Hz.
We only used it to measure the RPM of our shooter, so it works if you don’t actually need the distance.
I actually like Alan’s method better. Let the FPGA do the calculation.
For a 250 pulse encoder 1/250 * 60 = distanceperpusle.
GetRate will then yield RPM’s direclly.
That’s a good idea, I think we will probably do that with our shooter encoder.