AI and CI not synchronized

[Kevin_Price]

I still can't exactly explain the lag, but I *did* look a bit closer at your data file and your post-processing code.  Some things I noticed:

1. It's troubling that the data from the two analog channels isn't more similar.  I don't have time to research all the cDAQ hardware, but I suspect you might have an anti-aliasing filter in front of the A/D on one of the channels?

2. It's similarly troubling that the data from the two AI channels in the same task, using the same clock, receiving the same signal, appear to have a noticeable time shift.   The amount of software left-shift you applied to the strain data appears to be calculated correctly according to NI's docs, but the data does *not* end up aligned.

   Advice for troubleshooting: feed a much lower freq sine wave to both AI channels.  Modify a simple example program to save the data without any software post-processing.  You should be able to confirm the 38-39 sample shift you expect at your sample rate.  Make sure you understand what you need to do (and why!) to get the AI channels aligned in time before moving on to the encoder. 

3. The encoder data shows an odd characteristic that doesn't look like real physical motion.  There appear to be step changes in velocity (the slope of your position data) without any rounding at the corners to account for accel.  Something's wrong there -- that's not how real things move.

4. The general shape of the encoder data doesn't look right either.  It looks much more like a velocity response under constant braking action, but your config suggests that it should be a position response.  Have you changed your code significantly since the version you posted?

These things led me to look a lot closer at your post-processing code.  Some more items of note:

5. You're throwing out a lot of your data before saving it.  Shortly after reading your acq data, you're extracting out only a subset of it.  The rest is being lost.  

   This could explain why the encoder data has those sudden stair-step changes -- the sudden jumps show where all the missing data would have continued on a similar slope.

6. I would do most/all of the post-processing in the file-writing loop instead of in the data acq loop.  Work out a way to do your left-shift without discarding data.

7. You're re-opening and closing your file every time you write.  You should only open it once to get started and not close it until all done writing.

In summary, there are some things you can improve and address, but I still don't have a working theory on how the things I pointed out would result in your time-shifts.   While I'd *want* to be able to point to the subset & discard problem, it looks like all channels discard the same chunks of data.  The right symptom to expect from that is simply *missing* chunks of data, not a relative time-shift among channels. 

   Still, I've often found that taking care of the little details ends up solving the bigger problem for reasons I didn't anticipate ahead of time.

-Kevin P

[DsX]

Hi,

I did some more tests today with removing post-processing (only zeroing remained). The result for the analog channel looks expected ~ 39 sample delay on the strain channel, but the delay for the counter channel increased to ~ 200 samples. Again this looks like it is beeing delayed for two loop iterations. Is it possible that the HW does some averaging before returning values?

The strain module NI 9237 has an anti-aliasing filter.

Matej

[Kevin_Price]

Running out of ideas here.  I'm much less familiar with the cDAQ platform & modules than with PC boards, but I'd be pretty surprised if the counters were delayed or averaged.

I'm also troubled by the shape of the encoder "position" data.  It shows a period of no change, followed by a period of constant negative slope, followed by another period of no change when it reaches the value 0.    It sure *seems* more like a speed measurement than a position measurement, especially considering that you're measuring a braking mechanism.

Other aspects of the config & your description do seem more position-like, but the overall curve shape is much more speed-like.   Can *you* make sense of the encoder data, setting aside the time-alignment for a moment?

Another troubleshooting idea would be to query both Counter and AI tasks to double-check that the sampling is really in sync.  Drop the following DAQmx property node to query each task after reading, and make sure that the values being queried stay nearly equal throughout the acquisition.  

-Kevin P