[SOLVED] some questions motor speed monitoring

[bigdogguru]

its normal that the RPM starts at 2000 or approximate value near to it...

there is something called cold start where it starts from 2000 or 3000......
check this discussion
Why does my car start with high rpm's everytime? - SaturnFans Forums

I have to say, one of the pleasures of being a member of this forum is you rarely go a day without learning something new.

For instance, I never realized there was such a close relationship to the electromechanical properties of a BLDC Fan and that of an Gasoline Fueled Internal Combustion Engine!

Thanks for pointing that out ckshivaram.

 

[alexan_e]

You can't use the RPM or RPS as time intervals, you have to use some timer and count the pulses for a specific duration.
In your code you are manually incrementing the RPS for one second and then you show its value, I don't see any measuring of the external pulses.

Alex

 

[romel_emperado]

You can't use the RPM or RPS as time intervals, you have to use some timer and count the pulses for a specific duration.
In your code you are manually incrementing the RPS for one second and then you show its value, I don't see any measuring of the external pulses.

Alex

yeah.. that's I realized that's why I removed it... check my previous post.. already removed.. hehe :-D

 

[alexan_e]

Yes but now my post doesn't make sense :sad:

 

[romel_emperado]

Yes but now my post doesn't make sense :sad:

I will make another code snippet just to check what is in my mind

 

[bigdogguru]

Perhaps implementing a moving average, as Alex mentioned previously in this discussion, would be a viable solution.


Your interrupt routine upon receiving the first pulse increments a counter and starts a timer. After a set number of pulses, say 50 or 100, the timer is stopped. You now have the number of revolutions per a known time period which allows you to calculate RPM.

BigDog

 

[romel_emperado]

Perhaps implementing a moving average, as Alex mentioned previously in this discussion, would be a viable solution.


Your interrupt routine upon receiving the first pulse increments a counter and starts a timer. After a set number of pulses, say 50 or 100, the timer is stopped. You now have the number of revolutions per a known time period which allows you to calculate RPM.

BigDog

accroding to my research I found 2 ways to get the rpm.

1) Wait for pulse.
2) Start timer.
3) Use next pulse to stop timer.

Elapsed time is the period. Invert to get frequency, then multiply
by 60 to get RPMs.

Or, you could have a sample window and count the pulses:

1) Start timer.
2) Count pulses until timer stops.

Frequency is pulses divided by timer interval.

let's try method 1:

pulse1 to pules2 period is 0.1sec

f = 1/0.1
f= 10Hz
to get RPM
10Hz(60sec) = 600RPM


method 2:

let say we want to sample every 1 second and we got 10pulse/sec
so (10 / 1) (60) = 600RPM

Pls let me know if I have mistakes in my poor calculations... hehe

2am here.. Good night in advance guys.. :grin: :grin: :grin:

 

[bigdogguru]

A slightly better variation of the method 1 would be to count a set number of pulses, say 100, instead of just one pulse. Doing so will give you a moving average and a more stable RPM value for display purposes.

 

[alexan_e]

If you have a low RPM motor then it is probably better to use a capture input to count the time it take for the motor to give a rotation, then you can use it to calculate the RPM ( 60/measured_time)
If you measure 0.1sec then a simple 60/0.1 will give you the result

Alex

 

[bigdogguru]

Also on method 2 you may want to use an even fraction of second for the timer duration say, 0.1 or 0.01 seconds.

You should keep in mind your dealing with an 8-bit RISC processor, so you should attempt to keep as many values as possible within the range of a unsigned byte (0,255) and avoid division as a rule.

It may not be an issue with this app, but in real life applications, arithmetic with long and long long variables coupled with multiplication and division can really be MCU cycle consuming.

BigDog

---------- Post added at 18:54 ---------- Previous post was at 18:53 ----------

If you have a low RPM motor then it is probably better to use a capture input to count the time it take for the motor to give a rotation, then you can use it to calculate the RPM ( 60/measured_time)
If you measure 0.1sec then a simple 60/0.1 will give you the result

Alex

Exactly, Alex you beat me to it.

 

[romel_emperado]

A slightly better variation of the method 1 would be to count a set number of pulses, say 100, instead of just one pulse. Doing so will give you a moving average and a more stable RPM value for display purposes.

If I will use method 1 that will be done let say every 2 seconds interval. I will capture 1 pulse as a sample to determine if the motor RPM is increased or decreased.

---------- Post added at 19:58 ---------- Previous post was at 19:55 ----------

If you have a low RPM motor then it is probably better to use a capture input to count the time it take for the motor to give a rotation, then you can use it to calculate the RPM ( 60/measured_time)
If you measure 0.1sec then a simple 60/0.1 will give you the result

Alex

exactly!!! I will use the CCP module to do that.. I will look for smaller PIC package for this application.. I want to make a prototype of this and put it in my table as my toy... hehe

---------- Post added at 20:03 ---------- Previous post was at 19:58 ----------

Also on method 2 you may want to use an even fraction of second for the timer duration say, 0.1 or 0.01 seconds.

You should keep in mind your dealing with an 8-bit RISC processor, so you should attempt to keep as many values as possible within the range of a unsigned byte (0,255) and avoid division as a rule.

It may not be an issue with this app, but in real life applications, arithmetic with long and long long variables coupled with multiplication and division can really be MCU cycle consuming.

BigDog

---------- Post added at 18:54 ---------- Previous post was at 18:53 ----------



Exactly, Alex you beat me to it.

a very good reminder.. I just know about it..

 

[bigdogguru]

If you have a low RPM motor then it is probably better to use a capture input to count the time it take for the motor to give a rotation, then you can use it to calculate the RPM ( 60/measured_time)
If you measure 0.1sec then a simple 60/0.1 will give you the result

Alex

Romel,

Keep in mind if you use a duration of say 0.1 sec as Alex and myself suggested, then X/0.1 is equivalent to 10*X so you can avoid division.

BigDog

 

[romel_emperado]

Romel,

Keep in mind if you use a duration of say 0.1 sec as Alex and myself suggested, then X/0.1 is equivalent to 10*X so you can avoid division.

BigDog

yes but the time mentioned there is not always 0.1 sec it's the time measured between pulse with respect to the motors RPM speed.

---------- Post added at 20:13 ---------- Previous post was at 20:09 ----------

I haven't use before the CCP module of a PIC..
Im afraid if I can measure a very short pulse like 0.001 say if the motor is very fast... ..
or the CCP module can be able to measure time something like this 0.1234

 

[bigdogguru]

yes but the time mentioned there is not always 0.1 sec it's the time measured between pulse with respect to the motors RPM speed.

I believe Alex and I were referring to method 2, number of pulses in a specified duration. So rather than the number of pulses in a second, you could count the number of pulses in a tenth of a second, etc.

BigDog

 

[romel_emperado]

I believe Alex and I were referring to method 2, number of pulses in a specified duration. So rather than the number of pulses in a second, you could count the number of pulses in a tenth of a second, etc.

BigDog

anyway.. thanks so much all of you guys for being here to help me always....

I will take a nap first and get back here ASAP :: -P
3:30am here.. Good night.. G0d Bless guys..

---------- Post added at 20:33 ---------- Previous post was at 20:32 ----------

bigdogguru
alexan_e
ckshivaram


Thanks...

 

[alexan_e]

I believe Alex and I were referring to method 2, number of pulses in a specified duration. So rather than the number of pulses in a second, you could count the number of pulses in a tenth of a second, etc.

BigDog

Actually I was referring to the first method, capture the timer counts for 1 rotation to calculate the period and the RPM mainly because Romel said that the motor is a 50 RPM model so for 1sec the count of rotations will still be 0.
If the motor is a higher speed model that can give a few rotations/sec then a pulse count/sec would be fine.

Im afraid if I can measure a very short pulse like 0.001 say if the motor is very fast... ..
or the CCP module can be able to measure time something like this 0.1234

this will not be a problem, for example a timer with a clock of just 100000Hz can give you a resolution of 10us which can measure a few thousands rounds/sec (which is hundreds of thousand rounds/min)

Alex

 

[bigdogguru]

Actually I was referring to the first method, capture the timer counts for 1 rotation to calculate the period and the RPM mainly because Romel said that the motor is a 50 RPM model so for 1sec the count of rotations will still be 0.
If the motor is a higher speed model that can give a few rotations/sec then a pulse count/sec would be fine.

Ok, well I stand corrected.

Although, I would have to say a 50RPM motor seems unusually slow without special gearing.

BigDog

 

[alexan_e]

The speed was mentioned in post #31 but I have checked it again it was actually a "what if"

I mean if the motor is very slow let say 50RPM only..

but in any case all of the previously described methods can give pretty accurate results.
I would probably go for the capture method for 1 rotation, if it is accurate enough for frequency measurements then it is more that enough to be used for a motor rotation measurement and it has the benefit of the fastest result in the smallest possible measure duration.
It is also very easy to use the result and calculate a 2 or 3 sec moving average.

Alex

 

[romel_emperado]

Actually I was referring to the first method, capture the timer counts for 1 rotation to calculate the period and the RPM mainly because Romel said that the motor is a 50 RPM model so for 1sec the count of rotations will still be 0.
If the motor is a higher speed model that can give a few rotations/sec then a pulse count/sec would be fine.



this will not be a problem, for example a timer with a clock of just 100000Hz can give you a resolution of 10us which can measure a few thousands rounds/sec (which is hundreds of thousand rounds/min)

Alex

Thanks so much.. I will start making code of this after my exam this Wednesday. I will just use the builtin FOsc of PIC.
This would be my first prototype using PIC... hehe

 

[romel_emperado]

hello, My exam today was postponed so I will do the coding in this project instead..

Im using PORTA of PIC16f628A for my LCD and we all know that bit4/RA5 of PORTA is the MCLR Pin. is it okay if I will not use MCLR pin as MCLR function? im using this pin for my LCD..
by the way Im programming my LCD in 4bit mode..

and the CCP1 module is in PortB there would be the output of my hall effect sensor should be feed....

---------- Post added at 09:09 ---------- Previous post was at 09:02 ----------

ah okay Im wrong I only need 6BIT in 4bit programming mode and I can leave the MCLR PIN for MCLR function

RS
EN

and D4 - D7 for data 6Bits all in all...

Hi ckshivaram,

Pls tell me if this is off topic. for me its still on topic because this is part of the project.. thanks so much..