Velocity calculation from qudrature encoder

[NU-MA]

Hi,

I am using Labview 8 with E series DAQ card, and trying to calculate velocity from the Quadrature encoder. I calculate time difference by using Tick Count, and then divide the change in position to the change in time. The problem is that the time difference should be the same as sampling rate or Wait Until Next ms in the attached file, however the time difference is not always the same, which sometime makes spike in the velocity calculation. I would like to know if I have to use the constant number (sampling rate/wait until next) for velocity calculation, or is there any other solution? I don’t understand why the time difference is not the same for different iterations. I would appreciate if somebody can help.

Thanks,

Azadeh

[Conseils]

As you have this in Rev 8.X I was hoping to test this with hardware under rev 8.X but I dont have hardware installed at the moment... sorry (I intend to try later but I have a hot projet on the go at the moment)


But I do note that you use two seperate reads of the millisecond timer and this could be a cause of problems.

Regards
  Conseils

[Conseils]

I mean the two in the loop by the way..... just to clarify a little...

[NU-MA]

Hi Conseils,

I am using one Tick Count for calculating time difference (delta time), and the second Tick Counts (one inside the loop and one outside the loop) is used for recording the time. So, I don't see why this should make any problem? 

Thanks for looking at the problem,

Azadeh

[Conseils]

You are using two seperate reads inside the loop, and the result of one of the reads is operated on and placed eventually in a shift register. Also in the loop is a seperate read which is used  for a calculation  associated with the first read.

As you can't control when and what order the reads occur, I think that it would be better to read once in the loop so all the calculations are based on a single read of the timer.

This was just my first thoughts on the matter.

[johnsold]

Software timed data acquisition is always subject to timing variations due to OS latencies. Both the DAQ operations and the screen updates (writes to indicators) will occur at times controlled in part by the OS and not necessarily synchronized with the loop timing. In addition the conditional execution (Case ..0 compared to Cases 1 or 2) may take different amounts of time - the differences are probably much smaller than the tick count resolution, but there are differences.

If you cannot do hardware timed DAQ, then try two things: One, put the DAQ in a high priority loop which does nothing but Read the counter and the Tick count and put the data into a queue at the timing rate you prefer. You do not need a separate Tick count function - just take the data from the Wait until next ms Multiple. Be sure to use dataflow so you know whether the tick count was read before or after the DAQ. Put all the calculations and front panel controls and indicators in a separate, parallel loop which reads the data from the queue. It must also have some kind of wait function. A wait of 100-200 ms is reasonable for user interface updates. People cannot respond any faster than that.

Two, do some smoothing of the data. Any differentiation process, such as position -> time, tends to enhance any noise or high frequency variations. A simple moving average filter may clean up your velocity signal. How much filtering and what type may depend on the intended usage of the data.

Lynn

[NU-MA]

Hi Lynn,

Thanks for your suggestions, I would like to try having the counter and the Tick count in a high priority loop. I am not very familiar with queue. Do you have any example that I can look at it? And also, by using this method, does it mean that we get the time difference from the Wait until next ms Multiple (which will be a constant) instead of the time Tick count (that varies)?

Thanks a lot,

Azadeh

[johnsold]

Azadeh,

Yes, get the time difference from the Wait Until Next ms Multiple. It uses the same tick counter internally so it will have the same resolution, but it wits for the multiple specified to provide more nearly uniform timing intervals. It is still possible for some variations tooccur, especially if the OS does something time consuming.

For examples File >> New.. >> VI >> From Template >> Design Patterns >> Queued Message Handler (LV 8). Also search for examples under the help menu.

Lynn

[NU-MA]

Hi Lynn,

Thanks for your help. Do you know about calculating the velocity from the other counter and gating signal?

Azadeh