synchronizing AI task with counter task

[ARBaker]

I have written a standalone script to try troubleshooting why I can't get a counter synchronized with an analog input task. After searching NI discussion boards and white papers I can't find much discussion on this, which is surprising.

So, how do I get a counter input synchronized in a general way to an analog input task? I say "in a general way" because it seems like many of the other discussion board posts are very specific to some hardware or measurement application and they usually are able to get by with some way of doing it that's specific to their setup. I want a labview/daqmx algorithm/implementation that I can utilize across multiple hardware systems, cdaq chassis with modules, PXI chassis, PXIe. We have a general purpose data acquisition script that will ^we want^ to run with all of the above technologies. So before I try to tackle a more general case, I just want to understand a specific case of Cdaq-9178 with 9402, 9234 cards.

I have two Daqmx tasks that will run in MAX fine, an analog input task with 1 voltage on the 9234 card. A 1 counter input measurement frequency on the 9402 digital card setup for implicitly sampled.

My frequency measurement could be slower than the sampling rate of the analog input or faster than the AI sample rate. It may be measuring anything from 10 Hz up to 50 kHz. I don't want to average out the speed either, I want to catch every incoming pulse. So, more or less, I cannot use sample clock based setup for the counter. I have to use an implicitly timed counter input.

This seems to indicate that if I use a trigger pulse to the start trigger of the AI task and the same trigger to the armed start trigger of the Counter task then they are in sync? Maybe I'm not understanding the hardware right but they are not sync'd up when I record data.

I test this out by connecting a frequency generator square wave to the 9234 AI task and the same square wave to the 9402 counter task. I then say (in labview) that the AI start trigger is cdaq PFI0 and the armed start trigger of the counter task is PFI0 as well (I’ve also used ai/start trigger as the terminal too). I start both tasks and both tasks work as expected; they don't begin acquiring data until I connect the start trigger to the PFI0 line, but when I plot the data the two tasks are not synchronized. The frequency channel is always delayed by different times, but .3 seconds seems to come up a lot as the delay on the frequency channel measurement. I change the frequency on the generator while recording data so the counter frequency channel should match up to when the pulses change on the voltage channel. See my attached diagram from Diadem showing what I get.

I plot the data in Diadem. The AI voltage is a waveform so has built in timestamps. I compute the time stamps for each sample of the frequency by timestamp = sum(1/freq samples). When I plot, they just aren't in sync.

Is the triggering not working the way I expect? Am I not thinking about the plotting the right way?

I can't imagine someone hasn't tried this before. This just seems like a common thing that test engineers would want to do - synchronize frequency data with AI data. I see this commonly done on other data acquisition systems from other manufacturers.

Thanks for any help. 

Adam

Cummins Inc.

[Kevin_Price · Accepted solution]

It's a little tricky, but far from impossible to sync your constant-rate AI data with your variable rate frequency data.  I'm much less familiar with the cDAQ platform than with desktop and PXI boards so I can't say which specific chassis and boards do or don't support the things I'll describe.  I'm pretty sure some of them will, but am also pretty sure some of them won't.

I don't have time to lay out an exhaustive step by step recipe, just some general info that will help you find further things to investigate and research in detail.

Contrary to popular belief, a trigger is not the beginning and end of a conversation about syncing tasks.  What's often more important and is frequently overlooked is the need to sync or share a timebase.  With desktop boards, tasks running on one board will derive their timing info from a common timebase.  Tasks running on separate boards will each use their own board's timebase by default, and they will vary slightly from board to board.

Much of the task sync I do is based on a shared sample clock and nothing else.  Triggering is often not needed to get tasks into hardware-level sync.

Your case is an exception.  You *cannot* share a sample clock so you *must* bring in triggering as part of your sync scheme.  You'll also need to make sure that your explicit AI sample clock and your implicit CTR sample clock are derived from the same timebase.  If they are on the same desktop board, this is automatically true.  Other situations will require you to address this in specific ways.  Part of it is task config settings, part of it may be physical connections. 

Using 2 desktop boards would require physical connections, either internal RTSI cable or external wire and screwdriver to span PFI pins.  2 PXI slots already share RTSI signals across their common backplane.  I can't speak with authority about what's involved with cDAQ.

Running short on time, can only do some further bullet list stuff for now:

• do not believe the t0 timestamp on a triggered AI task.  It's lying
• you must make sure the trigger signal *cannot* happen after the AI task starts but before the CTR task gets a chance to start
• depending on your specific CTR hardware, you may be a victim of an ill-considered DAQmx change for freq & period measurement.  There's a clunky possible way to deal with the issue by consuming another counter with a 2-edge separation task.
• when you configure your Arm Start trigger, you should also identfy the trigger type as a digital edge and identify the polarity as Rising (like the AI task)
• I'd recommend dataflow sequencing in your loop so that you read "all available" samples from the CTR task *after* reading the specific # from your AI task
• some folks who struggle with sync get all the hardware parts right, but then aren't careful with the data streams from their tasks.  I see no obvious problem with your data handling (aside from believing the "t0" waveform value from the AI task), just figured I'd mention it as something to keep in mind, especially for others who come across the thread

-Kevin P

[ARBaker]

Thanks for the advice Kevin.

The trick was making sure the property "trigger type" was setup as digital edge. Setting this property seems to be what actually "turns on" the arm start trigger to make it work. I didn't have this property and only looked like the arm start triggering was working because the counter sample read did not have a time out so the loop just sat there and didn't go on to the next loop iteration until the AI task was triggered. In the mean time the Counter task was gathering data, but not displaying on the front panel causing the delay I was seeing and also confusing me.

Thanks again.