LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to find RPM of an absolute encoder?

Hello guys, I am new to the labview programming and I am having a lot of difficulty trying to find the RPM of an absolute encoder. The encoder model is 960 from www.encoder.com. One of the things that I tried was counting edges and then dividing by the pulse per revolution. I believe that this only gives me the revolutions, and I am not sure how to calculate the time elapsed and use that to find the RPM of an absolute encoder. Thanks for the help.
0 Kudos
Message 1 of 31
(4,206 Views)
I was able to find the total number of revolutions, but I need to know the time intervals between when I started and when I am taking the data points in order to get the RPM.
0 Kudos
Message 2 of 31
(4,172 Views)
No need for the I32 conversion.Smiley Wink
 
You know your loop takes 10 msec.  Feed the value coming out of the counter read and send it to a shift register.  Subtract the value from the shift register from the new value and divide by 10 that will be Revs/msec.  Times 60,000 will be revs/min.
 
This may not be perfect since it is essentially software timed, but should get you going.


Message Edited by Ravens Fan on 01-22-2008 05:07 PM
0 Kudos
Message 3 of 31
(4,166 Views)
The Wait Until Next ms Multiple function has an output which give a time in ticks (approximately milliseconds). You can use that output to obtain the timing information. However, because you have no data dependency between the DAQmx Read and the Wait, you do not know which will execute first. Thus you will have some timing uncertainty. I would execute the wait first then immediately afterward do the Read.

Then you can process the time and count data to obtain the speed information.

Lynn
0 Kudos
Message 4 of 31
(4,165 Views)
thank you guys. I'll give it a shot.
0 Kudos
Message 5 of 31
(4,147 Views)
I tried what you guys suggested but now I am kind of stuck again. I need to filter the signals but I am not sure if I am doing it correctly. As of now, I am doing an average, but I am not sure if that is correct since the rpm slowly increases at the beginning. I will gladly appreciate any help. Thank you. This is what I have:
0 Kudos
Message 6 of 31
(4,083 Views)
These are the data that I received; and I am not sure if I am filtering it correctly. One labeled "filter" is the filtered signal using triangular smoothing.
Download All
0 Kudos
Message 7 of 31
(4,080 Views)

Hello,

I feel that the filter will not be needed if you follow the example that Ravens Fan posted.  The RMP2.vi uses the timeout value of the DAQmx Read.vi as an input to the second divide.  Where the posted example is using a value that is wired into a Wait Until Next ms Multiple.vi.  The second divide in the calculation is outputting revolutions per ms.  Please note that is why the posted example ends by multiplying by 60,000.  Once you make these small changes to your code, you RPM output should be more constant and eliminate the need for a filter. If you are still interested in filter, please review the attached documentation.

Smoothing Filter Coefficients

Filter

 

Samantha
National Instruments
Applications Engineer
0 Kudos
Message 8 of 31
(4,033 Views)
Even when I tried as Ravens Fan posted, i still get inconsistency. When i take the average of the RPM it seems to be increasing...but the rpm we are putting out is constant.
Download All
0 Kudos
Message 9 of 31
(4,010 Views)

What the problem may be is that there is file write operations going on inside the loop.  A 10 msec loop is a pretty fast loop rate.  If all you were doing was taking the readings and doing calculations, that is probably okay.  But now you have write to file operations going on (twice!).  Those express VI's open, write, and close the file every iteration of the loop, and that could probably take longer than 10 milliseconds.  You may want to createt a graph where you track the tick timer (tick count on the timing pallete).  Keep feeding it into a shift register and subtract the current timer from the previous iterations timer.  Graph that on a waveform chart and see how consistent the loop rate is.  I bet you'll find the loops take longer than 10 msec.  The reason the apparent RPM is growing in time is that it may take each iteration of the loop a little bit longer to run than the last because the file size is growing.

There are at least 3 things that could be done to help.

1.  Best.  Move the file VI's out of the loop and pass those values to a parallel loop for the file writes by way of a queue.  (See producer/consumer design pattern.)

2.  Okay.  Use lower level file I/O VI's where the files are opened before the loop, written to in the loop, and only closed after the loop ends.  (Doing this type of operation based on the producer/consumer loop is actually the best.)

3.  Track the timer from loop iteration to loop iteration to see the actual loop iteration time.  Use that instead of the hardcoded divide by 10.  That way if the loop still takes longer than 10 mseconds, it will account for the extra ticks in the counter within the calculation.



Message Edited by Ravens Fan on 02-11-2008 10:59 AM
0 Kudos
Message 10 of 31
(4,005 Views)