LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Measuring RPM for encoder 11 bits

Hi,

 

I am working out in this project to measure RPM from encoder 11 bits. I believe I had filtered out the data/ value which give me 0 - 2048 for a one complete cycle. At the moment, I'm having trouble to convert this data to rpm. 

 

What data i have :

(i)  0-2048 value (one complete cycle)

(i) time taken measure in micro second. 

 

Thanks.

 

0 Kudos
Message 1 of 17
(4,148 Views)

Hi fendy,

I'm not sure to understand your problem. Are you asking us how to calculate the speed in rpm while you have a distance vs. time data ?

CLAMaxime -- Kudos are a great way to say thank you
0 Kudos
Message 2 of 17
(4,135 Views)

Yes, it is. 

0 Kudos
Message 3 of 17
(4,125 Views)

Well, either I really don't get it, either it a really basic mathematics questions...

 

https://en.wikipedia.org/wiki/Speed (see definition)

 

You just need to convert your distance in an angle value which will give you how much of a round you have achieve in the given time. 

CLAMaxime -- Kudos are a great way to say thank you
0 Kudos
Message 4 of 17
(4,118 Views)

Hi Fendy90

Do you need to determine direction? How often are you reading values?

Speed in RPM is calculated as a distance over time. For your encoder signals, (change in encoder position/2048)/(change in time) x 60 seconds = RPM.

Your VI is using VISA serial reads of encoder position (0-2047) at 9600 baud which will greatly affect the RPM resolution because you have no accurate way of determining if the encoder count has rolled over since the last serial read. Reading too slowly will lead to missed cycles.

Could you capture data and repost your example VI so we can see the Encoder1 and Time values for XY Graph3? Run the VI, Right Click on XY Graph3 select Data Operations and make current value default. This should save the data to the graph when you save the VI.

Todd

CLD

0 Kudos
Message 5 of 17
(4,025 Views)

I can't open your VI so my comment may not be relevant.

 

One observation: Your VI is named: Encoder_Accelerometer_Final_Sync_V2.vi.  Accelerometers are not used for measuring RPM (based on my experience). The filename is Not important unless you are actually trying to use an accelerometer for this task. 

 

What is the 0-2048 value?  Is this the number of revolutions during the time period? Your previous comments are not clear on this.  Most of the time with RPM sensors, you will be counting edges for a certain amount of time.  Once you have the number of revolutions and the amount of time, it's simply a matter of converting it to the right units (microseconds -> minutes). 

 

 

 

 

 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 6 of 17
(4,022 Views)

I assume that an 11-bit encoder means that one revolution "counts" up to 2^11, or values between 0 .. 2047.  Thus 2048 "counts" = 1 revolution.  RPM is "revolutions per minute", so you measure the number of counts occurring over some period of time, then say RPM = counts * (1 revolution/2048 counts) / (time interval * (1 minute / N intervals)).  Suppose you measure 256 counts in 15 seconds.  RPM = 256 * (1/2048) /(15 * (1 / 60)) = 0.5 RPM.  Note that if you examine the "word formula" and look at the units, you will see that the units on the right mostly cancel leaving units of revolution / minute.

 

Bob Schor

0 Kudos
Message 7 of 17
(4,005 Views)

I made some changes to your original VI that should calculate RPM from your signals.

 

Try running the attached updated VI and report your findings.

 

Todd

0 Kudos
Message 8 of 17
(3,981 Views)

I believe you need to divide by 2048, not 2047.  An 11-bit encoder can take on values from 0 to 2047, or 2048 different values.  You can also use modular arithmetic to do "encoder math", using 2048 as the modulus.  If we assume (and it is an assumption) that we measure fast enough so that the encoder turns less than 1/2 a turn, we can "sign" the result as well -- if the difference (mod 2048) is less than 1024, the count was increasing, while if it was greater (or equal to) 1024, it was decreasing, so we should subtract 2048 from the difference to get a signed count.

 

Illustration -- start at 0, go a 1/4 turn "positive" to 512.  Delta = 512 - 0, positive, report 512/2048 = 0.25 turn.  Now start at 0, go a 1/4 "negative", i.e. to 2047, 2046, ... 1536.  Delta = 1536 - 0, > 1024, report (1536-2048)/2048 = -0.25 turn.

 

BS

    

0 Kudos
Message 9 of 17
(3,971 Views)

Hi Toddk,

 

Answering to your question,

1. Do you need to determine direction? NO

2.How often are you reading values? 500ms if possible. I am trying tp ramp my motor up to 3 seconds and give a free rotation 1 seconds and brake the motor at afer 4 seconds. Im trying to measure the rpm at all these phenomena.

 

3. Speed in RPM is calculated as a distance over time. For your encoder signals, (change in encoder position/2048)/(change in time) x 60 seconds = RPM.

Your VI is using VISA serial reads of encoder position (0-2047) at 9600 baud which will greatly affect the RPM resolution because you have no accurate way of determining if the encoder count has rolled over since the last serial read. Reading too slowly will lead to missed cycles.

I did try using 115200 baud rate and the communication is too fast until my "scan from string" cant capture it,  lead to format error everytime i try to run VI. That is why im using a read button to read it once the "indicator" substring shows data format that i want.

Capture1.PNG

 

 

 

 

Could you capture data and repost your example VI so we can see the Encoder1 and Time values for XY Graph3? Run the VI, Right Click on XY Graph3 select Data Operations and make current value default. This should save the data to the graph when you save the VI.

Capture2.PNGCapture3.PNG

 

 

Thanks.

0 Kudos
Message 10 of 17
(3,928 Views)