Measure frequency and direction of rotation with M series

[JamesDean]

Hello All,

I’m having a difficult time trying to find resources on how to measure frequency (or RPM) of an incremental rotary (quadrature) encoder using an M Series device (USB-6210). I’m currently using the Z phase from the encoder, which generates one pulse per revolution, though, since I need to get direction of revolution, I will likely have to switch to reading Externally Controlled and wiring the A and B phase. I anticipate that my shaft will be spinning at about 7000 RPM or about 120 Hz. It seems that all the examples and resources I find are to measure angular position. The best post I’ve seen so far on measuring encoder frequency is this one: 

http://forums.ni.com/ni/board/message?board.id=170&requireLogin=False&thread.id=153773

Where Tom W has suggested using the installed LV example: "Count Digital Events-Buffered-Continuous-Ext Clk.vi" I’ve modified that example to display a frequency in Hz to the user using the Z output from the encoder but it seems that I have to do a lot of extra work to do so:

As you can see, I’m taking the difference of the value in the last element of the array from the value of the last element in the previous array that was pulled from the buffer. This will tell me how many pulses from my timebase I am getting over the entire time since the last time the buffer was polled. I then divide that by the number of Z pulses (encoder revolutions) which is really just the size of the array since each element in the array corresponds to a Z pulse (1 revolution) from the encoder. Then I’ll finally take that quotient and it becomes the divisor for the rate of my known timebase. The quotient of that final division is my frequency.

It seems to me that if I just wanted to get the rate data of the encoder (without direction of rotation) then it would be easier to use the DAQmx example: “Meas Dig Freq-Buffered-Cont-Large Range 2Ctr.vi”

My main worries are

1)      1) that Tom didn’t mention that as a bettersolution, so there may be something that I’m not accounting for

2)     2)  I will also need to be measuring the direction of rotation, which Tom says I can use do by wiring the A and B phase and choosing Externally Controlled. I haven’t yet incorporated that yet (my example above is done with the Z phase) because I want to know if I’m on the right track or if there’s a way easier way to do this that I’m missing

Has anybody else used an M Series device to measure the frequency of rotation while also being able to measure the direction of rotation?

Thanks!

Message Edited by JamesDean on 02-18-2009 03:31 PM

[aNIta B]

Hey JamesDean,

           I would recommend using the example that you mentioned rather than the VI that you posted for measuring frequency. To measure the direction of the encoder, you'll need to use two counters.  You're definitely on the right track, this link is also a good resource for what you are doing. 

aNIta B

National Instruments

[JamesDean]

Hello, 

I am afraid that is an extremely unhelpful response and does not answer my question.

You said "I would recommend using the example that you mentioned rather than the VI that you posted for measuring frequency"

Which example are you referring to? I mentioned two examples. I modified one of the examples I mentioned, "Count Digital Events-Buffered-Continuous-Ext Clk.vi", to come up with the code I posted because the example by itself does not do what I need to do!

I've seen that link you provided, that was the first thing I looked at, it does not give instructions on how to measure frequency with an encoder which is my fundamental question: How do I measure frequency and direction of rotation of a quadrature encoder with an M Series device?

You said that I need to use two counters to make the measurement. I know this as well, using either example I pointed to will reserve both counters for the operation.

I've worked with NI HW and SW for eight years and I am generally pretty comfortable but there are constantly new areas I am expanding into. I have also worked with NI AEs and found them to be an extremely bright, motivated, and capable group of engineers.

I really need more assistance than this, can you please help?

Thank you! 

Message Edited by JamesDean on 02-19-2009 07:56 PM

Message Edited by JamesDean on 02-19-2009 07:57 PM

[stilly32]

Hey JamesDean,

If you're just looking to measure frequency as well as direction, I would do a buffered sample clocked position measurement and calculate the rate from that. I'd start with the "Meas Angular Position-Buffered-Cont-Ext Clk.vi" example and feed it a clock at a known rate. You'll essentially latch in the position at a known point in time, and your rate would be change in postion/change in time - you could calculate it from sample to sample based on the period. For example, assume you had a encoder (assuming X1) with 10 ppr and you clocked it at 1kz. If you read two points, and it incremented by 2 ticks between samples, your speed over that period would be (2/10) rev/(1/1000)s = 200R/s =  12000 RPM. You could do the same in terms of degrees and so forth. That should work regardless of direction. You could use another counter to generate the sample clock, another timing signal from AI or AO, or (my favorite) freq out - it just needs to be at a known rate.

I would disable the Z-index so that the count doesn't get reset on each rev, you're really only interested in the difference between consecutive clocked points. 

Hope this helps, please post back if I've misunderstood your intent, or you have questions about implementing this. 

Andrew S

Message Edited by stilly32 on 02-20-2009 12:01 PM

Message Edited by stilly32 on 02-20-2009 12:04 PM

[JamesDean]

Hi Andrew,

Thank you so much for your help. Everything you said makes a lot of sense. I just have one question however. I'm trying to work the unit conversion on the example you gave and I actually get it to work out in a different way. I calculate the conversion as the following where ticks are from the timebase and pulses are what the encoder outputs:

 

The difference in value between 2 samples would be the number of ticks in 1 pulse of the encoder, which in the example you gave is 2 ticks. In your equation you start with 2/10 rev but it seems that it should be 1/10 rev since the encoder has only outputted one pulse in which there are 2 timebase ticks. In which case, the final result is different.

Am I thinking incorrectly? Please feel free to correct me if I am and thank you again for your help! 

[stilly32]

Hey James,

I think you're close and using ticks may have been a bad example. Speed will be change in angular position/change in time. Angular position can be measured in degrees, radians or ticks. When I used ticks I was thinking 10 ticks = 1 revolution, so 2 ticks = .2 revolution, so our change in angular position would be .2 and the change in time would be the period of the sample clock - 1/1000. 

You could also do it in terms of degrees, and say the difference between 2 buffered samples would be 72 degrees,  = 72/360 =  .2 rev.

I think most of the confustion is that with sample clocked position measurement, the samples are latched on the clock edge running at a set rate rather than on the angular encoder signals. Even if your angular encoder is not moving, you will still be latching in values on the sample clock edge. 

The M-series user manual has a section on this, check out the timing diagram in figure 7-19. (Ignore the typo on skipping 3... I messed that part up)

I'm close to having a rough example built up, I'll post it when I'm done. 

cheers,

Andrew 

[JamesDean]

Hi Andrew,

Thanks again for all of your help, you're right, I was confused with the fact that the clock edge is latching the count into the buffer and not the encoder pulse edge. Thank you for clearing that up.

I believe I have a solution that works, I just need to test it out by simulating an encoder signal.

If you finished with that example you mentioned, that would be helpful to check my work.

Thanks again for your help! A+! :manhappy: