how to get time for speed in incremental encoder

[DODI]

I am using NI PCI -6251 and SCB-68 E SERIES DEVICES and LabVIEW 8.6.1 and have got incremental encoder which have A, B  signals.

I want to measure speed with DAQ. I used DAQ assistant (counter for measuring angular position) with 2 inputs

A signal (PFI 8)=37

B signal (PFI 10)=45

I calculate speed w=df/dt in rad/s 

where df=f2-f1 angular difference

for dt=1milisekund

RPM=(w*60)/2*Pi

but get strange results. For example I have motor with 1160 RPM 

and speed which I get in LabVIEW is varying about from 2500 to 3000 and more RPM.

I think this is somehow connected with my dt-time sampling.

Does anybody know how to get dt sampling time correctly?

I attached my program.

Thank you for your answers.

[Stefo]

DODI,

As I told you here, I believe you should not read angular position, but you should read period measurement. Because the precision you can get in the way you implemented is limited by software timing. In comparison, if you have 100kHz clock, or even 20MHz clock or more, than you can measure time between pulses very precisely. If you know that number of pulses per revolution, than you know the angle per pulse. From that you can calculate actual speed way more precisely than with relying on software timing and the angle you will read in certain time.

regads,

Stefo

[DODI]

Thanks.

I tried measuring speed with measuring period, frequency and by counting edges.

But value of speed is always changing to much I think due to counter which counts edges.

I know that counter is 32-bits but I do not know what to do when counter roll over.

Will it be good if I set counter to 0 when it reaches for example some value close to 2^32 -1 -1000 (pulses)?

I read about roll over problem on that page but still do not understand how to solve that problem.

Thank you for your answers.

[Stefo]

DODI,

if counter reaches it's maximum, next active edge on source will cause to reset count to zero and counter will generate a pulse (or toggle) on it's internal output. If you use 100kHz timebase, it will allow to measure 2^32 (4mld) pulses, which means you can take measurement for 4mld/100k second, which means about half of a day. If you use 20MHz timebase, then you can run measurement for more than 3 minutes without counter rolling over. This means, you could measure veeeery slow signals, considering that counter will keep count for just one period 🙂

DODI, I hope you are using LabVIEW 🙂 Could you please post me a code so I can see what you do to be able to help you better?

regards,

stefo

[DODI]

Hello!

If I understand correctly. On gate (PFI9 CTR0 GATE)  of a counter I have my signal which I measure speed.

Internal clock (Source of a counter) for measuring period is 20 MHz or 100kHz so called counter time base rate.

LabVIEW counts rising edges and calculate on 

Period (in seconds) = Count / Counter Timebase Rate

Period is then time between two rising edges.

My incremental encoder  have 512 pulses per revolution so I multiply 512*T /60 to get T in minutes.

Then I f=1/T and I get speed in RPM as is in my program.

My values which I get are very variable for example:

I set on motor 1192 RPM and get values like: 1196, 1190, 1221, 1193, 1182, 1200, 1201...

I do not undesrtand if the motor is rotating with constant speed 1192 RPM and to get such different values ?

On default I have 2o MHz but I must have 100 kHz so that 32 bit  counter rolls up after 12 hours and not after 3 minutes (20 Mhz).

But how can I set 100 kHz in my program?

[Stefo]

DODI,

To understand how accurate you can measure, please see KB Making Accurate Frequency Measurements.

To set 100kHz Timabese as source, you can use DAQmx Channel property node Counter Input -> General Properties -> Counter Timebase -> Source and create terminal constant. To be able to find 100kHz Timebase, you need to right click on the constant and choose IO filtering. You should turn on Include Advanced Terminal. Then you will be able to see 100kHz Timebase.

However, I'm not convinced it is necessary to use it. You need to understand, that with slower timebase you lower accuracy. Moreover, if we speak about count rolling over, then I believe it can happen just in case no pulses are comming for some time. If pulses are comming, then count restarts with each new pulse. With 512 pulses per revolution, you would need to rotate shaft slower than 1/3/512 RPM (whih means les than 1mRPM, if there is anything like miliRPM 🙂 )

regards,

stefo