Using cDAQ internal line as trigger for DAQmx task

[vgravel]

Hello,

I have a cDAQ-9178 and I would like to send a trigger to two differents tasks (DO and AI) to be sure that they start at the very same moment.

I would like to fire the trigger using software instead of and external trigger on PFI lines for exemple. For exemple, I would like to fire the trigger when a user press a control on the front panel.

I tried to use the cDAQ internal counter (_ctr0) by generating a pulse on it. The problem is that I can't see those line when i'm configuring the trigger for the 2 previously mentionned task. There is a lots of different line that seems to be possible to take but I don't know how to fire a trigger on theses...

Help would be appreciated!

Thanks!

[MarkGrot]

Hi vgravel,

As you mentioned, there are many different ways to implement this behavior.  Probably the easiest is having one task use the other's start trigger and call start as your user specified action.

For example,  DO start trigger source = /cDAQx/ai/startTrigger.  Start your DO task so it is waiting for a start trigger.  When your user wants to fire the trigger, call start on your AI task.  With a little preconfiguration, you can make it faster.

The counter option you mentioned should also work.  Set the start trigger source for both the AI and DO task to be /cDAQx/_ctr0InternalOutput (fill in whatever counter number you are using).  What do you mean when you say you couldn't see the trigger?  Were you using the internal output as your source?

[vgravel]

Hello,

Thanks for your help.

I figured out the "_ctr0InternalOutput" few minutes before you replied me. I was excpecting something like "_ctr0" instead, so that's why I wasn't finding it.

Can you give me an example of "preconfiguration" that you are talking about. What do you mean by "faster"? What would be the delay using the "/cDAQx/ai/startTrigger"?

Thanks again for the help!

[MarkGrot · Accepted solution]

There is some setup work you can do before generating a start trigger.  For example, creating a task, creating channels, configuring timing, and calling start on it might take a few hundred milliseconds.  There are intermediate steps you can take to frontload some of the configuration time. 

A DAQmx task has a number of states.  When you call start on a task it transitions through verified, reserved, and committed to started.  So if you explicitly commit your task your start call will be faster because your hardware has already been configured.  If you had already created the task, created channels, configured timing, and committed the task (through the DAQmx Control Task interface), the start task might only take 10ms or so.  Those numbers are off the top of my head.  This will not reduce the overall time it takes to start your task, just the specific step of issuing your software start trigger.

That said, if you are going the counter route, you don't need to do that for your AI and DO tasks.  Just make sure you start them before your counter task.  You could do what I described above for yoru counter task if you feel that it was taking too long to generate your start trigger.

*Edit*

I should mention that the delay time I was talking about only refers to the time from when your user requests a start trigger to the chassis generating one.  The time from your start trigger to the first sample clock in your task is essentially nothing--around 12.5 ns or so depending on your configuration.

[vgravel]

Thanks Mark for the fast and detailled answer!

I will take that into account to try the make the best design possible.

Have a good day and thanks again!