Our team is currently attempting to calculate the rpm of a wheel by utilizing a proxy switch. We will then use this calculated rpm with a PID loop do acquire a desired rpm; however, I am struggling to calculate the rpm in labVIEW.
I first tried to use the counter VI, a sequence structure, and a timer delay function, but I ran into problems (all these calculations are occurring in the teleop VI)
Here is the program i am using to calculate the rpm
Apparently the wait function I have in there makes the entire robot inactive.
I’d double check the specs on your prox and make sure it’s going to react quick enough to actually give you reliable RPM data. Some of them have a switching frequency down to 25Hz, which might be too slow for you.
Thank you for the reply! I will make sure to try that tomorrow.
I did notice that the timed tasks VI is outside the loop that contains the teleop VI. Does that mean that inside the time tasks VI, I should perform the above calculations in a while loop rather than a sequence structure?
Correct me if I’m wrong, but dosen’t Counter Get return count time, which can be easily converted to speed with nothing more than a Counter Get and 1/x blocks?
This is what I have come up with. I have stored the calculated RPM in a variable so I can call it in the teleop VI. I also started the counter in the Begin VI.
Do you think thats a good approach?
And I will make sure to check the accuracy of the proxy switch!
The Counter VI does have a “period” value, which returns the average time between pulses. I never actually contemplated using that. Do you think that would be a better idea?
You dont actually need the reset. and using the period value would be a much better idea. with your method you would only get 1 reading per second. for the period, run it in a 1/x function then multiply it by 60 to get rpm’s
If you’re trying to use this value for closed loop control, then yes you probably want to use the period value instead, and update your value quicker. You’ll also get vastly more useful data out of the period with much higher resolution. Counts only come in integer values, so the smallest change in RPM you can detect is 60 RPM. The period is going to be measured in rather smaller increments, so you should get much higher resolution data out of it. Also, you might be able to use the period measurement straight in your teleop loop instead, as long as the function block returns a good value even if it doesn’t have a new period value yet.
Okay, I’ll give the period strategy a shot! Thank you!
Also, i thought I should use the reset function because I wanted to find a relatively instantaneous rpm, which is also the reason I wanted to calculated the rpm every second using the time tasks VI. I thought if i didn’t reset the counter, it would give me an average rpm, which would not be very useful. Am I interpreting it wrong?
The period does not look at the number of counts. It looks at the time it takes between 2 pulses, and thats what it outputs. the number of the counter doesnt matter.
You are interpreting it correctly. You need the reset* if you’re doing your way. You don’t need the reset if you do it the other way (get the elapsed time between counts).
or instead of reset you could use a feedback node to subtract the previous reading