Synchronize Encoders

[drewtreb]

Hello,

I am attaching three vi’s.  The main vi is Encoder Vi For NI .  These vi’s are subsets of the actual vi that I am using in my program.  The actual vi has much more logic inside of the while loop, and several concurrent while loops that run outside of the loop.  However, this vi adequately demonstrates the problem that I encounter.

This project needs to read two analog inputs and two encoder inputs at precisely the same time.  The two analog inputs are Shaft Speed and Shaft Torque.  The two encoder inputs are Input Shaft Angle and Output Shaft Angle.  I then subtract the input angle from the output angle to get deflection angle.  This is what the customer needs to see.  During our testing, we kept getting deflection angles when we thought they should be zero.

In order to trouble shoot this, I have set-up in our demo lab a spare encoder that is wired to both counter input 0 and counter input 1.  Therefore, in theory, as this encoder turns, I should never see a deflection angle not equal to 0 (difference between the two counters).  Since both counters are connected to the same encoder, they should always read the same.

However, this is not what I see.  When I spin the encoder from a motor at 1000 RPM, I see deflection angles bouncing around up to 1 or 2 degrees.  I interpret this to mean that the two encoders must not be read at precisely the same time.

What can I do to my code to fix this problem and guarantee that all readings are completely synchronized?  I am using LabView 7.1 and a PCI 6221 card.

Regards, Drew Trebuchon

[Matthew_W]

 Hi Drew,

 I believe the reason you are seeing this is that the DAQmx Read's are happening at slightly different times. What this means is your Counter 1 and Counter 2 Read's occur with slight offsets due to Windows (non deterministic right...) executing the Read's non-simultaneously.

The way to move forward with this is to implement a Buffered Read. This will require a external clock to tell the Counters when to latch the count values into memory. This external clock will be the source to a DAQmx Timing  (Sample Clock) VI placed in CI Angular Encoder task's.

Things to be aware of:
  1. Buffered counting is a intensive operation. This can be seen in the M series benchmarks for buffered counting.
      The reason is the FIFO is 2 samples, this means data must be transfered from the card very frequently or you will
      run into Buffer Overrun errors.
  2. DMA Transfers should definetly be enabled, this will help with the point 1 above.
  3. Avoiding Error -10920 (computer performance problem), related to points 1 & 2.

According to your VI, the encoders are returning 1024 pulses per revolution. The rate of revolution is 1000 revolutions per minute, thats
1.024E6 rev/min or 17,066 rev/sec...

Please do post back and let us know how this performs with your test setup!

Thanks and have a great evening.

Best regards,

MatthewW
Applications Engineer
National Instruments

Message Edited by Matthew W on 08-09-2007 11:08 PM

[tbd]

Hey Matthew,

(I hope you'll forgive me for barging-in, but...)  why isn't measurement synchronization - at least for the counters - guaranteed by their shared start-trigger? ( isn't the trigger accomplished in hardware? - )  Is it OK to trigger counters using the AI-Start trig?  Also, your revolutions/unit-time calc looks funny.  Were you shooting for 1000revs/min => (1000*360)degrees/60sec => 6000 degrees/sec

=> ~1deg / 0.17ms? ... so a delta of 1 or 2 degress => measurement-offset of (roughly) 0.17 to 0.34 ms.

Cheers! 

Message Edited by tbd on 08-10-2007 12:23 AM

[Kevin_Price]

tbd,

Answering in a general way since I don't have LV nearby to look at code.   If 2 counters share an "Arm Start" trigger, then yes, they will start their counting in sync.  However, to keep their READ's in sync it's necessary to perform buffered acquisitions so that those count values will be latched simultaneously and stored in the task buffers.  If the tasks are unbuffered, then READ calls produce an instantaneous snapshot of the count.  2 consecutive calls from software will have some small delta time between them, hence the small and jittery but mostly consistent count difference.

Matthew W already said the same thing but with different words.  Maybe this re-phrasing makes it clearer?

-Kevin P.

[Matthew_W]

 tbd -- 1. Kevin P. very nicely iterated what I was trying to say.
           2. thank you for catching my units mistake! ; ) I was meaning to express this problem in terms of pulses/second, but canceled the wrong units when I was typing and put rev/second instead.
 
Kevin P. -- Thanks, that what I meant exactly.


MatthewW
Applications Engineer
National Instruments

Message Edited by Matthew W on 08-10-2007 02:27 PM