I need some help regarding synchronizing analog input and counter input on a cDAQ-9178 chassis with NI 9237, NI 9213, NI 9401 and NI 9215 modules installed.
The AI and CI channels are sharing the same clock (NI 9237 ai/sample clock).
When I look at the measurement file, I notice that counter data is lagging behind analog data for about 100 samples. Both AI channels are in sync.
Am I missing some synchronization step or is this a hardware limitation of CI channels.
Is the amount of lag variable from run to run or is it consistent? If the problem is what I suspect it might be,
I'd expect the lag to be a bit variable, and you *might* even see the AI lag the counter sometimes.
I have only a moment for a brief look & comment, so here's are my initial thoughts:
Potential problem areas you seem to have handled correctly:
- while sharing the AI sample clock, you have sequenced the tasks to start the counter task *before* the AI task
- inside the main loop, you are reading the same # of samples from each task
Problem I suspect:
- before the loop, you read and discard all available samples from each task. You are likely discarding different
# samples from each task, so that the subsequent ones you keep are out of sync.
- read and discard the same # samples from both tasks before starting the read loop.
- OR, don't read and discard any samples before entering the read loop.
Thank you for your response. The idea behind reading all available samples before the main read loop was that I would clear the entire buffer before acquiring valid data.
So by "discarding different # of samples from each task" do you mean that there is a different # of samples in the buffer between the execution of the two DAQmx Read vi's in the sequence structure? (for example: CI read vi executes --> AI acquires some more data --> AI read vi executes during which time CI has acquired some more data).
Yes, what you described is exactly what I meant. Admittedly, a 100 sample difference *does* seem like a lot to account for, but it was the only thing I spotted in my once-over. At the moment I'm away from any LV box and am going by memory, but I thought the rest of the sync'ing structure & sequence looked sound.
If you definitely want to discard some samples before entering the loop, I'd sequence it so that the first task reads "all available" (either by wiring a -1 or leaving the # samples unwired), then take an array size of the data you're about to discard, then request that exact # of samples from the second task. That'll help keep the internal read buffer pointers in sync between the tasks so both continue to point at data taken at the same time (due to the successful hardware-sync of the tasks).
It is not important to me to discard data before entering the loop. I just thought it might be more "clean" to do so. But since it seems to cause more problems than it solves, I'll just throw it out.
Unfortunately I won't be able to test the solution for some time as I'm tied up on another project, but I will let you know as soon as I do.
Thank you for your help.
I tried removing discarding data today, but the result stays the same. CI channel still lags behind AI channels for approx. 122 samples (this lag seems to be fairly consistent).
It still looks to me like the DAQmx sampling and reading should be properly sync'ed. It looks like you've set that all up properly to buffer & read sync'ed data. However, I *do* notice an explicit call to left-shift one of your analog waveforms (Strain) but not the other (Torque). Since a left-shift of analog data could look like a lag in the counter data, I figured I should point it out.
(The only time I've done that kind of thing was to compensate for the delay induced by a hardware analog filter on just the one channel. Is something like that the reason you're doing the left-shift?)
I don't know what your system is, but perhaps the "lag" is a true system characteristic? Compliant couplings, gear backlash and other system elements may delay the response seen in some sensors relative to others. Maybe the strain/torque must develop for some time through a compliant component before motion is seen on the other side?
For the sake of troubleshooting the "lag", I'd recommend that you add the raw counter data to the "Strain & Torque" chart prior to doing any of the left-shifting or other post-processing. Use that raw unprocessed data to evaluate your lag situation.
The left-shift on the strain channel is due to NI 9237 module's delta-sigma ADC. It is meant to align data with the torque and counter channel after removal of delayed samples (38,4/fs+4,8us = 39 samples).
I have noticed that that CI lag is equal to 2 * (100 read samples - 39 delayed samples) = 122. Do you think this is something to investigate further?
The test system looks like this: (DRIVE MOTOR) coupling (ROTARY TORQUE TRANSDUCER WITH QUADRATURE ENCODER BUILT IN) coupling (CAR BRAKE ASSEMBLY WITH FORCE SENSOR BETWEEN THE BRAKE PADS).
However for data synchronization testing I applied the encoder signal to both analog channels so all NI modules receive the same signal at the same time.
I will also try your suggestion and write unprocessed data to file. I'll let you know how that goes.
Thank you for your help!
I'm less familiar with cDAQ hardware than the PC boards, but in very general terms, the idea that a digital sensor like your encoder would lag *behind* an analog sensor doesn't pass the smell test. If anything, I'd think it might be the other way around.
How consistent is your ~122 sample lag? Is it dead on (i.e., 122 +-1)? Or does it vary by a handful of samples here and there? Your observation that 122=2*(100-39) sounds intriguing at first glance. Such "coincidental" relationships are generally prime candidates to investigate when troubleshooting. But in this case, I can't work up a theory of how the (100-39) lag would arise, nor why it would always arise twice. Still, I would remain suspicious if the 122 is a very consistent figure because it's likely a strong clue, and it will eventually make sense in retrospect.
I can't look at the code at the moment, and up til now I've mostly focused on the DAQmx stuff. I did see operations like the left-shift and sub-sets though. Those bring in the possibility of introducing apparent lag in post-processing. My rule of thumb for this sort of troubleshooting is to get as close to the metal as possible, i.e., look at the data coming straight out of DAQmx Read.
A final thought/question: how exactly are you detecting and measuring the lag? It seems to me that you'd look for a brake force spike to mark the beginning of a braking action and try to correlate it with an encoder speed decrease. Since you're measuring encoder position, speed would have to be calculated with a numerical derivative. Derivatives add noise, so they are often smoothed through filtering, and filtering often adds lag. Anything here ring a bell?
Perhaps I should elaborate a bit on my test system; it is designed to test efficiency of the electronic handbrake actuator.
The actuator transforms rotary motion from the drive motor into linear motion that pushes the brake pads together. Between the drive motor and actuator we have a rotary torque transducer that outputs an analog signal for torque and a digital quadrature signal from the encoder to measure angle of rotation.
On the other side is a strain gauge that sits between the brake pads and measures force.
For the purpose of testing synchronization I am ignoring the analog output of the sensors and have wired the encoder pulses to all inputs - NI 9237 (strain), NI 9215 (torque) and NI 9401 (encoder). This way any mechanical effects on the measurement is eliminated.
The lag of data is apparent when you look at the measurement file, you see that the analog channels start changing before the counter channel (see attached file).