quadrature encoder index reseting the counter

[P. Horn]

Using NI-USB 6259 two quadrature encoders have been wired to the same quadrature signals A, B and Z.

One encoder is reseted by incomming Z-Index ( Ahigh, Bhigh).

The other encoder count the increment continuously without reseting.

Measurement has been done over 360 degrees during one hour.

Velocity was about 291 increments per second.

2^20 increments are available on 360 degrees angle.

256 Z-Indexes are comming over 360 degrees run, each 1.40625 degrees.

We have encountered that about 362 increments have been lost in the quadrature encoder which has been reseted against the  continuously running encoder.

How could be this behaviour explained?

Is their a possibility to read the position out at which z-index ocurs without reseting the encoder?

[JB]

If I'm correct, 1 quadrature encoder is wired to 2 counters. The Z index is active for one counter. Therefore, after exactly one revolution, this counter should indicate 4096 (reset on every index) and the other 1048576.

• What are the values of both counters after one revolution ? You say that 362 increments were lost...
• Are these values repetitive ?
  
• How are the counters configured ?

• angular or position up/down counters with direction set through hardware (A = pulses and B = direction)
• edge counter (A = pulses and B = ignored)
  

• In other words, will the counters decrement if the encoder rotates in the reverse direction ?

• Have you set filters on the counter inputs ?

PS : 2^20 CPR (counts per revolution) and 256 Z pulses per revolution ! I have never heard about such a beast !



 

[Kevin_Price]

Adding to JB's comments, I'd echo some suspicion about the 256 "Z-index" pulses per rev.

What is the timing relationship between these Z-index pulses and the A,B square waves?  Are they synchronized or independent?  If independent, there's a very good chance for reset problems.

You describe a config where your counter board will reset count when the following conditions are ALL simultaneously true:  A and B signals are High, Z index signal is High.   If the Z isn't sync'ed to the A,B there are two kinds of problems you can get. 

1. The Z-index pulse may be too short and not overlap an interval where both A & B are high.  Your counter won't reset its count on any such Z-pulses.

2. The Z-index pulse may be too long and overlap more than one interval where both A & B are high.  Your counter will reset its count 2 (or more) times on any such Z-pulses.

-Kevin P.

[P. Horn]

Thanks for prompt responses.

I do now have little bit more insight to what is happening by writing to file only after zero setting of the second encoder.

LabView is running as fast as it becomes resource time from windows.

In most cases it catches following values correctly as it can be seen from the EXCEL file attached

1. Time ( normaly incremented by 14.0625 seconds, one segment is 1.40625 degrees, velocity 0.1 degree/sec)

2. Angle 2 before the reset

3. Angle 1 before reset at angle 2

4. Angle 2 last measured after reset ( normaly 0, if OK)

5. Angle 1 after reset at angle 2

If labView runs each 3 miliseconds, we get sometimes the same position at angle 1 or only one increment between the "before" and "last" position.

But at angle 2 the expected 4096th increment is newer reached, because at this increment we get allready 0 value.

This explaines our loss of 255 increments and the rest to the problems of our former interpretation, when LabView was writing too much to the file.

My last question would be, if the LabView will run in EXE mode, would it run under "real" mode and does it get the maximal real time in the windows environment?

[Kevin_Price]

Sorry, data doesn't do much for me because I don't know enough about your system, your code, your intentions, etc.

Can you describe the physical setup and your intentions?  Can you post the code that reads the data and stores to file?  Sometimes the best solution comes by answering the question that hasn't been asked yet...

Meanwhile, you asked: 

...if the LabView will run in EXE mode, would it run under "real" mode and does it get the maximal real time in the windows environment?

Dunno about "real" mode.  I recognize the term but haven't found the need to know the significance since back around Windows 3.1.  

As to maximum real time, generally the answer is no, but it's possible to increase the priority of a LabVIEW vi.  However, I suspect that the better answer to the question you didn't quite ask is that there are probably alternative ways to code your app that don't depend on such high priority.

-Kevin P.

[P. Horn]

Application description (short):

There is first serial communication to a Stepper Motor Controller to drive a Stepper Motor with Gear. Behind the Gear an Angular positioning system is mounted, which give us the angular position through the quadrature encoder signals A, B and Z.

The purpose of the LabView program is to check whether no impulses (at the angular position measurement) are lost during one cycle over 360 degrees.

We are here testing the whole environment setup.

Therefore we have wired the same A, B and Z signals to two quadrature encoders, one of which is reseted at Z signal and the other one not.

I have attached 2 programs, one original with temperatures and motor current measuremens and the second one which is so simplified that only angle measurement are provided (Cases: READ, PROCESS, >READ...) and written to the file, when one quadrature encoder in LabView is zeroed by the occuring Z-index signal (Cases: READ, OUTPUT, CHECK,>READ...).

The angle measurement itself should be as fast as possible in order to not miss any A, B, Z pulses.

Thats all for your information.

Finaly the fact has been proved, that zeroing by Z-Index of the quadrature encoder, one impuls (0, 1, 2, ..., 4095, 4096 > 0) will be missed.

The second fact is that even with the velocity of 291 increments per second, which is very low, sometimes the LabView is not running for about 6 milliseconds (Windows does not give this real processing time to LabView) and we are not able to catch exactly the positions before and actual (last) on the occurence of the Z-Index.

I do not know how the quadrature encoder is realized to run as stated up to 80 MHz, but one of the most importand features of such a realization shoud be possible to make zero index supervision sharp and to be able later to read the position from a register at which the occurence of the zero index has been encountered even without zeroing the position counter.

[JB]

Finaly the fact has been proved, that zeroing by Z-Index of the quadrature encoder, one impuls (0, 1, 2, ..., 4095, 4096 > 0) will be missed.

I disagree with above statement. 0 to 4095 represents 4096 values. 4096 is not an expected value of the counter.
Let's take the example of a basic encoder with 5 CPR. With an enabled reset on the index, the counter will return ...0, 1, 2, 3, 4, 0, 1... -> five values from 0 to 4.

The counter will indeed be able to measure signals up to 80MHz. The problem is not related to the counters themselves but to the way you use them. You should use buffered position measurements with an external trigger signal (the counters read the positions on every increment of the encoder and save it to a buffer) instead of a point by point measurement. In last case, the measurement is dependent on the overall timing and latencies of the application and the operating system and it is not surprising that some positions are missing. Just imagine the case when the operating system needs a little bit more time than usual to save the point in the file.

[Kevin_Price]

I second JB's comments.  Additionally:

The angle measurement itself should be as fast as possible in order to not miss any A, B, Z pulses.

There's a subtle point to make here.  There is a hardware stage, in which the A,B,Z pulses cause the value of the count register to change, and there is a software stage, in which query the instantaneous count value.  You can count on the hardware stage to reliably change the count value even if you aren't querying that value very often.  When you *do* happen to query the value, it will be an accurate position count at that instant.

The second fact is that even with the velocity of 291 increments per second, which is very low, sometimes the LabView is not running for about 6 milliseconds (Windows does not give this real processing time to LabView) and we are not able to catch exactly the positions before and actual (last) on the occurence of the Z-Index.

This is why you should consider using a hardware sampling clock.  Then the board and PC hardware do the heavy lifting for you and you don't need to run a fast software loop.  You can just let the buffer fill with measurements and then pull them out at the end.

-Kevin P.

[P. Horn]

I am including the part of my report to the customer.

May be it will be accepted to correct the FPGA error, if not it could help at least to other users.

[Zardin]

I have the same problem. What was your solution or alternative?

Thanks!