So the image is of a Counter get VI calculating the rpm of an encoder. The implementation I based this off of required that the loop execute precisely every 10 milliseconds (or however often you want) and that requires a timed loop. But what if you used the tick count and a shift register to calculate the rpm based off of how long the loop took to execute instead on relying on a timed loop? I will test this on the robot soon so if it seems like a sound implementation feel free to use it.
Forgot Photo…
Have you tried the rate output from the counter?
I’ve used the rate and counter value successfully on the C-RIO with an encoder.
On the rate counter I used the encoder index and for the counter I used the rising edges of a 1024 count encoder. I measured the output of a drill going 1,500 max. I double checked the speed via a non-contact tachometer and reflective tape while measuring the speed on the RIO.
I chose the counter this time because I was interested in getting my driven distance in encoder ticks for auto mode.
I’m confused. Are you saying that on the cRIO, in this same setup, the rate of the counter is correct, and on the roboRIO, the rate is incorrect? If so, you should report a bug.
I meant to say that I haven’t tested any counter stuff on the roboRIO only the C-RIO and for the application I want to use the counter value output. To get velocity using the counter value output you have to know how often your loop runs. To do that you would have to use a timed loop which I did on the C-RIO. The question is would the VI in post #2 replace the method that uses a timed loop and do so successfully on the roboRIO.
I still don’t understand why you want to differentiate the counter value output, rather then use the counter rate output.
I see. I thought you needed to open the counter in semi-period mode to get a rate output. Right now I am using external direction mode.
Rate also works in external direction mode. This is what the encoder uses internally when you choose 1x or 2x decoding.