How to find RPM of an absolute encoder?

[dibesh638]

When I tried to use write to file VI in order to save the data, it didn't let me connect the write VI and the data element coming from the dequeu element in the third loop.

[RavensFan]

Why are you using the Build cluster array function?  Since you are just passing in a double precision value, create the queue with that and pass it into the enqueue function.  When you dequeue that in the 3rd loop, it will wire to the signals input of a Write File Express VI.

If you want to continue with that you have, you will have to use an index array to get the value coming out of the dequeue function, then unbundle the cluster.

[dibesh638]

I still get very bizzarre results...the values seem to be very erratic.

[samantham]

Hello,

I was looking into the data sheet specifications of your absolute encoder (model # 960).  What are you actually inputing into the counter 0 of Device 1?  What line or maybe even lines for the encoder?  I am asking becuase I noticed the encoder outputs in grey code.  I see that you are using the 11 bit (2048) encoder based on your code.  Are you using any external circuitry to convert the grey code into binary?  I am also interested to know what model for a DAQ device you are using.

This is also a good site for explaining grey code for absolute encoders.

Message Edited by samantham on 03-14-2008 01:07 PM

[dibesh638]

In counter 0 for device 1 I am putting in the LSB (11-bit) of the absolute encoder. The ecnoder company told me that I could count the square form waves using the LSB. I do not have a setup to convert gray code to binary code though. The DAQ I am using is the NI-PCI-6251, and the box that I have is SCB-68 E Series.

[samantham]

Hello,

Your encoder has 11 bits of resolution and thus 2048 different positions per revolution.  Since it is an absolute encoder, it outputs angular position data on different bit lines.  You have the LSB wired into input of a channel configured for change detection task.  Thus, the task will only count edges on the LSB.  The encoder you have outputs in a grey code.  Thus, for an 11 bit encoder the LSB will only have 11 edges per revolution.  (If the encoder output in binary, the LSB would have 22 edges per revolution.)  Please refer to the second link in my last post for details about encoder output code types.

In your current VI, 2048 is the constant for the number of pulses per revolution.  Please try changing this value to 11.  The 2048 relates to the number of position and if using an incremental encoder the lines would pulse 2048 times per revolution.  However, since you are dealing with grey code and monitoring the LSB the expected number is 11 for pulses per revolution. 

[dibesh638]

Even with the change wouldn't I still have the problem of the data not being a constant rpm since I am only changing a constant? I will give it a shot tomorrow when I return to the lab. Also, I was just wondering, would I be able to use the program for an incremental encoder with A and B signals and an index? If so, in order to find just the rpm can I only connect either A, B or the index to the ctr source?

[dibesh638]

Also, I was just wondering about the program. If there is a timed loop, and like Ravensfan said, there will be delays. So the number of counts that is processed per loop can vary with time. So I was wondering if the following logic would make sense and is a viable option in labview:

Since I know that for one revolution the LSB count has to be 11, is there a way to make a loop such that it records the length of time it takes for the count to be 11. This way I get 1 revolution in X amount of time. Then I would be able to convert it to revs/min.

I was just wondering if this is suitable and would I be able to graph this with time?

Thank you guys so much.

[samantham]

Hello,

Well changing the constant to the right value will help.  Yes, you are correct the RPM value still might increase over time, because we are just changing a constant.  However, the results will give you better data to troubleshoot with on what is going wrong.  Do you know about what RPM value you expect to see?  How does that compare to what you are getting with the constant now equal to 11?  If you are receiving just a small number of pulses during the 10 ms, then there is bound to be inaccurate results due to misalignment.  Please try increasing the 10 ms to a larger number as a troubleshooting step.

Yes, you can use this type of example with an incremental encoder.  The constant value in software would have to change with the type of encoder.  You also asked if you would be able to only connect either the A, B, or index to the source.  This is possible mattering what type of incremental encoder you have.  Some are X1, X2, X4, or 2 pulse encoders.

I see that you are open to new ideas on how to measure the RPM value without software dependency.  What DAQ hardware do you have?  Are you limited to a certain number of counters for this application?  Please give me some feedback and I will suggest some other methods.

[dibesh638]

The DAQ I am using is the NI-PCI-6251, and the box that I have is SCB-68 E Series. I believe I have three counter sources.