Measuring rpm of a motor.
PeteUK
Posts: 4
Hello
Colud anyone help by pointing me in the direction of code for monitoring the rpm of a motor using a simple proximity switch as the sensor. I have no problems with the electronics but wondered if anyone has done this without tying up the 'stamp' too much.
I will be 'seeing' 10 pulses per revolution and the rev range will be from 0 to 3000.
I have looked at the possibility of using Pulsin 1, XmS·and Pulsin 0, XmS·but I am not happy that there will be problems when we dismantle and re-assemble the rig later.
The reason is that the 'target' will in effect be seen for longer if the sensor is moved forward slightly and converse if moved further back so the on and off times will be different and therefore the rpm reading will be different from the original setting and need calibrating often.
Maybe 'Count' is the better prospect?
The application is to allow monitoring an exact rpm point for gear changing.
We are happy to read 0 to 300 and have jumps of 10 revs per change, this will be easier to read too. Hopefully this will make the maths and times simpler.
Thanks in advance. PeteUK
Colud anyone help by pointing me in the direction of code for monitoring the rpm of a motor using a simple proximity switch as the sensor. I have no problems with the electronics but wondered if anyone has done this without tying up the 'stamp' too much.
I will be 'seeing' 10 pulses per revolution and the rev range will be from 0 to 3000.
I have looked at the possibility of using Pulsin 1, XmS·and Pulsin 0, XmS·but I am not happy that there will be problems when we dismantle and re-assemble the rig later.
The reason is that the 'target' will in effect be seen for longer if the sensor is moved forward slightly and converse if moved further back so the on and off times will be different and therefore the rpm reading will be different from the original setting and need calibrating often.
Maybe 'Count' is the better prospect?
The application is to allow monitoring an exact rpm point for gear changing.
We are happy to read 0 to 300 and have jumps of 10 revs per change, this will be easier to read too. Hopefully this will make the maths and times simpler.
Thanks in advance. PeteUK
Comments
Even if the sensors are moved the SUM of the on-time and the off-time will still be the same for a given RPM.
Using PULSIN 1, Xms and PULSIN 0, Xms should yeild the best results.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never argue with an idiot.· They'll drag you down to their level then beat you with experience.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
I understand what you are saying about the total time on + off but the actual difference between the two will change. i.e if the total time is 100mSecs with 10mS on and 90mS off the rpm will be X. However if the motor speed was the same and the sensor is moved away slightly the times would change to say 9mS and 91mS, what effect would this have?
I am not trying to pick holes in the idea at all, I just need to make sure we have a simple, reliable rpm.
Just thought, maybe the idea would be to 'dump' the inductive proxy and use a photocell on the sprocket teeth as this would not be influenced by distance.
Failing that stick with the proxy and use feeler gauges to set it up!
Kind regards. PeteUK
I do not know if I can state it more clearly than Bean already has but you want to focus on the total time it takes to complete one sensor cycle. You can either look at the sensor on plus sensor off time or the time it takes between each sensor on detection event. They measure the same thing and convey how long it took the shaft to rotate.
Suppose I tell you to place reflective tape on a motor shaft and use a reflective sensor to measure the RPM. How much of the shaft would you cover with reflective tape? 1/16? 1/8? Half? More than half? Would it even matter?
All that really matters in this case is that some signal goes high for a while and then goes low for a while exactly and only once for each revolution of the shaft. The duration of the high signal plus the duration of the low signal equals the total time it took to complete a single revolution.
In short, the sensor can only be high for a while and then low for a while one time for each state during every revolution (or partial revolution if you are measuring gear teeth). If the sensor is closer it might be on longer and off shorter for a given RPM than it would if it were farther away where it would be on for a much shorter duration and off for a much longer one. Still, one on duration plus one off duration equals one total cycle duration and the total cycle duration is what tells you how fast your object is rotating.
I hope that helps explain a little more why on and off time variances will not affect the determination of the total cycle time. If this is still not clear feel free ask some more questions.
- Sparks
For some reason I had made up my mind it was the difference between the two signals on and off and not the total time. It is in effect like a set and reset with the time being monitored between the first event happening again.
So, if we see the first level change go low to high and then count the time till the same event happens again that is the equivalent.
I will try the 'Bean' code and then the COUNT method and compare them, for education sake if nothing else....we never stop learning do we?
Cheers again. PeteUK