Rotary encoder data acquired simultaneously with analog input data erroneous

[MikeStebbins]

Hello,

I am using LabVIEW 9.0 and a USB-6212 DAQ to measure multiple Analog Inputs and a digital counter simultaneously at the same measurement rate (2500Hz).  I measure the positions of a stepper motor-controlled linear actuator driving the master piston of a hydraulic system and an LVDT attached to the slave piston (please see slide 1 of enclosed .ppts for a crude schematic).

Data figure 1 on slide 1 shows a plot of the data from a test run just a bit ago.  This is zoomed in the beginning of a 1.0 Hz rate triangle wave displacement (similar to that show in the smaller picture, figure 2, slide 1).  In this test, the data says that the LVDT started moving approximately 0.5 seconds before the encoder.  Besides being physically impossible, I can verify that this didn't’t happen because I watched the test happen, and the slave piston being 0.5 out of sync with the master piston would be readily apparent.  I’ve tried to replicate these results multiple times with no success.  Data figure 2 on slide 1 shows one of the more “usual” tests.  The LVDT is supposedly still moving about 0.022 seconds before the encoder. The amount the LVDT leads the encoder is somewhat variable, ranging from near 0 to 0.025 in normal tests, besides the one example shown in figure 1.

Included are the Master VI (simplified to remove all other aspects of the experiment that don’t pertain to this issue), and all of the subVI’s used in the Master.  Slides 2-7 are PNG code captures showing the different states of the Classic State Machines that compose the Producer/Consumer loops for data acquisition and data logging, and the front panel.  Slides 8-13 are PNG code captures of the individual subVIs.

Could this problem have something to do with digital inputs on the 6212 board not being  hardware timed?  Or I have done something incorrectly in my code, specifically in the conversion of counter data to a waveform?  I need the equivalent of a timestamp on my encoder data, which is I why I convert it to a waveform before logging it.  I’ve used the same sample clock for the analog inputs and the encoder count reader, and I use the same initial timestamp when I write all values to one TDMS file.  But, now I’m not sure that that ensures that my encoder counts are being read simultaneously with my analog inputs.

Thank you very much for any assistance you might have, Mike

[Henrik_Volkers]

A simple test for the sync  (and to measure group delay) would be to hook the analog inputs to the quadrature signal. Capture some movement steps and have a look at the data.

[MikeStebbins]

Henrik,

Thank you for your suggestion.  The enclosed slide shows the results from running several different stepper motor movements while acquiring both the standard DAXmx encoder counter signal (as I have been doing) and the analog voltages of the encoder channels A & B.  The DAQmx rotary encoder signal consistently doesn't change until 0.0256 seconds after one or the other channels transitions from high to low or vice versa.  If I was to apply this time-lag correction to my previous results, it would push the encoder signal to showing movement before the LVDT, which agrees with the laws of physics!

At 2500 Hz (my AI and encoder sampling rate), 0.0256 seconds is equal to 64 samples' worth of time.  I'm acquiring 250 samples/channel in my acquisition loop, so it doesn't look I've missed one full sample-set of encoder values.  Any ideas as to why this would be happening?  Can I fix my code so that the DAQmx encoder channel reports correctly, or is this something I have to live with and fix in post-processing? 

Finally, does this give any insight into the one test where the data erroneously showed the LVDT moving ~0.5 seconds before the encoder moved?  I worry most about this behavior, because in actual use, verification testing, the LVDT will not be a part of the system (due to the fact that the slave piston is located inside an MRI).  We will use the position of the encoder to tell us the position of the slave piston, so we need to be able to trust it.

Thanks for your help, Mike

[MikeStebbins]

Does anyone have any ideas as to why the reasoning behind the consistent 0.0256 second delay between the first detected change on one of the encoder channels and the encoder counter DAQmx function detecting a change?  And, more importantly, is this related to the almost 0.5 second delay I saw on my encoder signal (as described in the OP)?  I can adapt to a constant offset, but a varying time offset will require significant changes.

Thank you for your assistance,

Mike

[John_P1 · Accepted solution]

Hi Mike,

I think I've got it.

Take a look at the portion of the code where you are starting your tasks:

The clock is starting first, then the encoder, then the analog task.  The amount of time between the starting of tasks is completely software-defined and thus non-deterministic.  Since the encoder task is starting before the analog task and the clock has already been started, it will pick up more samples during the time you are waiting for the analog task to start.  This will appear as a lag since you are matching the graphs sample-by-sample.

The solution is to start the clock source after starting both the encoder and the waveform task.

Also, I notice you are not arming your encoder.  It won't be a problem if your actuator is inactive during the startup time of the measurement application, but if it is moving this could also cause the two measurements to start out out-of-synch.  The solution in this case would be to use the start trigger from your analog task as the arm start trigger for your encoder task.  In this case, you would want to start your tasks in the following order:  1) Encoder 2) Analog In 3) Clock (Counter Out).

Best Regards,

[MikeStebbins]

John,

Thank you very much for your reply; your suggestion worked with my first test, and makes perfect sense to me. 

I did not try the arm start trigger, as there is no situation where the actuator could be moving as the VI starts up, but I appreciate you giving me that bit of advice, as well.

Mike Stebbins