Synchronized data acquisition of analog inputs, digital inputs and encoder position with digital start/stop trigger using CompactDAQ

[cpschnuffel]

Hi forum,

my goal is to synchronously acquire analog, digital and encoder data using the same sample clock, starting by a rising and stopping by a falling edge of one digital line. Finally I want to have a bunch of samples (one for each sample clock tick), each with analog, digital and (linear) encoder position data.

Hardware: cDAQ-9189 (chassis), 9215 resp. 9220 (AIN), 9411 (Encoder), 2 x 9421 (DIN), 9472 (DOUT, for some static output signals)

There are many examples acquiring analog and digital data using the same sample clock (like this: https://forums.ni.com/t5/Multifunction-DAQ/Rookie-mistake-Synchronisation-and-acquisition-of-multipl..., which of course doesn't exactly match my needs, but the idea behind is clear to me) and I know how to implement a start/stop trigger (using a start and a reference trigger).

I am familiar to LabVIEW, DAQmx and CompactDAQ, but this combination of different input types is new to me.

My question is: Is it generally possible to generate three parallel tasks (like the way shown in the example above), one for "AI Voltage" (for some inputs of the 9215), one for "Digital Input" (for some lines of both 9421) and one for "CI Linear Encoder" (for two lines A and B of the 9411) and to integrate the digital hardware trigger explained above (one line of a 9421) to get my samples as expected? Or is there any fundamental "no-go"?

Regards,

cpschnuffel

[Kevin_Price · Accepted solution]

The method illustrated in the "solution" example from the thread you linked should work out for you when you add another counter input task to measure your encoder. Just be sure to start both DI and CTR tasks *before* starting the (master) AI task.  Also be sure to read the same # samples from all tasks each loop iteration.

I tend to use a shared sample clock for these situations rather than a shared start trigger, but the reason why doesn't apply to your situation.   Not that it wouldn't also work, just that there isn't a clear advantage.   (There *are* advantages when working across multiple desktop DAQ boards that need to be synced, because each has its own independent timebase clock with tolerances on their accuracy specs.  But since all your modules get their sample timing from the same cDAQ chassis timebase, they'll retain their initial trigger sync indefinitely.)

-Kevin P

[cpschnuffel]

Hi Kevin,

thanks for your quick reply and your hints. I'm also a fan of sharing a sample clock across several tasks to synchronize them and will realize it this way.

Just for deeper understanding: What did you mean with "they'll retain their initial trigger sync indefinitely"?

Regards,

cpschnuffel

[Kevin_Price]

---

Just for deeper understanding: What did you mean with "they'll retain their initial trigger sync indefinitely"?

Two tasks on independent devices can have their start times sync'ed effectively with a trigger signal.  To maintain sync indefinitely, they *also* need to derive their sample timing from a common source.  In the case of desktop boards, the default behavior if for each board to supply its own timebase clock.  A typical accuracy spec is 50 ppm which works out to 3 msec per minute worth of timing discrepancy each.

So for example: if sampling at 1000 Hz, after 1 minute of acquisition a sudden spike may show up as sample #60002 on one device and as sample #59999 on the other.  They don't *retain* sync indefinitely, they skew relative to one another.

But in your case, your single cDAQ chassis is the single common source for the timebase used to derive sample clocks for its modules.  So while there's still an *accuracy* spec for the clock, at least you can know that all tasks are "following the same leader" so they retain sync relative to one another.

(Note: This is not universal for *all* cDAQ modules -- some of them have their own independent timebase which again allows the possibility of timing skew.  But I'm pretty sure all the modules you mentioned will get their sample clock from the chassis.)

-Kevin P

[cpschnuffel]

Hi Kevin,

thanks for your detailed explanation!

Regards,

cpschnuffel