Angular Encoder Position measuremeant N Samples doesn't start at zero degrees

[HannesD]

Hello Labview Community,

I am trying to implement a measurement setup where I use two ABZ-Counters simultanously to obtain the position error of a DUT (ctr0) vs a reference system (ctr1).

I use a dummy AI-Task to generate a clock for synchronous clocking of both counters and an ARM Start trigger to have both counter task start when the DUT Index pulse is detected.

I use a flat sequence structure to ensure both counter tasks are started before the clock is being provided. At the end the calculated discrepency (i.e. the error) is then plotted against the corresponding position value of the reference system to obtain a dataset 'error vs. position on circumference'.

Now the problem is that when I execute the VI I'll notice that the dataset doesn't start at position 0° degrees but at 60°-100°, depending on how fast the scale is turning when taking the measurement. That makes me think that for some reason the counter registers are being filled up before the 'read N samples' VI gets to execute and the N samples then are not taken from the very beginning. I'm a bit at a loss here, how can I ensure that my measurements starts at 0 degrees while the scale is in movement?

I tried forcing the start task of the dummy AI to perform after the read N samples VI via flat sequence, hoping that providing the clock after the samples have been requested solves the issue, but to no avail.

[HannesD]

I found a work around: if I specify the A-Output of my DUT as sample clock source the data set reliably starts at zero degrees.

[Kevin_Price · Accepted solution]

There's quite a lot of good DAQmx config work in the posted code -- I think you were already really close.  I don't follow *exactly* what you consider to be your workaround, but would suggest that it still may be worth pursuing a better understanding of the problem in your original approach.  Perhaps your workaround is a bit of a compromise with some tradeoffs involved.  But even if it isn't, you may still benefit in the long run from figuring out a root cause for the behavior you saw with the original approach.

Let me walk through what I see and what I can reason out:

1. Two separate encoders, different resolution, with z-index reset to 0 being optional for each (defaulting to disabled via front panel controls)

2. Comments to suggest that both encoder tasks use one of the Z index signals as an Arm Start trigger.

3. Both encoder tasks borrow your AI task's sample clock as their own and both encoder tasks are started before the AI task.

4. Here's a key piece of understanding to grasp:  Upon assertion of the Arm Start trigger, both encoder tasks will start tracking quadrature position internally.  The act of capturing position *samples* is distinct from this.  It requires the subsequent appearance of a sample clock signal *after* the task has received its Arm Start trigger.  If there's a long time between the two, you can end up tracking a lot of position change before you *sample* any of it.

5. In your code, AI is started unconditionally (no triggering) pretty immediately after the the encoder tasks.  Likely within a handful or two of msec.  And you see an initial sample in the range 60-100 deg.  So let's just suppose 6 msec and 60 deg and see if things seem plausible.

    That's 10 deg/msec == 10k deg/sec ~= 28 rev/sec ~= 1675 RPM.  Not knowing your specific system, that strikes me as easily plausible.

6. But there's a caveat.  The previous analysis kinda assumed that the Z-index pulse (used as an Arm Start trigger) asserted immediately after the encoder tasks were started.  But more generally one should expect an average 1/2 rev movement before the Z-index.  Plus the additional 60-100 degrees that are measured.  So is 2/3 - 3/4 rev in 5-10 msec still plausible?   Well, those ranges correspond to 4000-9000 RPM -- significantly greater speed, but not necessarily ridiculously high.  (Again, system dependent...)

Despite all that, there's a pretty simple solution.

A. Disable Z-index reset for both encoders

B. Do not bother with the Arm Start trigger for either encoder (you'll see why later - steps E, F)

C. Continue to use the AI sample clock to perform encoder sampling 

D. Continue to start the encoder tasks before starting the AI task

E. Configure the AI task to use the Z-index pulse as a (regular) Start Trigger

F.  Treat the 1st encoder position as an offset.  Simply subtract each encoder's offset from ALL its measurements before looking at your encoder-to-encoder diffs.

G. Caveat: these measurements aren't carefully referenced to the Z-index pulse used as your trigger.  You can get a pretty good estimate by combining the rotation speed and the device's detailed specs for time from trigger to sample clock.  But it's still just an estimate.

H. There are other ways to approach this where you intentionally enable Z-index reset on the encoder used to trigger AI (or perhaps both of them), but the post-processing of the measurement data becomes a bit more complicated to manage.  Possible, but will require extra care to get it right.

-Kevin P