Continuously Acquire Analog Input, Internal Clock, Pause Trigger, Multiple Device

[jon_mcbee]

I have a PXI chassis with 6 PXIe-6363 cards.  I want to acquire data on AI channels of each PXIe-6363 card continuously, using the internal clock for timing.  I need to be able to use a pause trigger read from a DI on one of the PXIe-6363 cards to pause and unpause the acquisition.  I came across this example: https://decibel.ni.com/content/docs/DOC-12256/ but keep getting Error -201019 at DAQmx start Task "Pause triggering is not supported in a multi-device task.  To configure pause triggering in a multi-device configuration, you must use no more than one device per task and manually route the clock signals in the application."  

The problem is that the AI setup is done at runtime by the operator.  Sometimes they will want to acquire data on one AI across all 6 PXIe-6363 cards, sometimes they will want to acquire data on every AI channel across all 6 PXIe-6363 cards.  This makes setting the task up to manually route the clock signals between devices for each task rather difficult.

Is there a simpler way to solve this problem?

[Kevin_Price]

Maybe someone's got a better idea, but here are some brute force things I'd be considering:

1. I'd use DAQmx Unflatten Channel String.vi to create a string array of each individual ai channel.  Then sort it to make sure they're all grouped by specific board.

2. Use a little parsing to break those down into subarrays that all refer to the same board

3. Use DAQmx Flatten Channel String.vi to convert those subarrays into the form needed by DAQmx Create Channel.vi

4. Create all those separate tasks, one for each board.

5. Adopt a convention like making the first referenced board be the master and configure all other boards/tasks to use the master's AI Sample Clock as their own Sample Clock

6. I'm not sure what routing options are available for a DIO bit.  I'd be inclined to figure out a way to route the pause trigger signal explicitly onto, say, RTSI 0 so that all AI tasks can be configured identically to use RTSI 0 as their pause trigger.  You might need to generate your pause trigger with a counter rather than a DIO bit because the routing options are generally much more flexible.

There may be simpler ways, but if none of those are forthcoming from others, this is at least an idea that should work in principle.

-Kevin P

[John_P1]

What degree of synchronization is required?

You could use one of the 6363s' counters to generate the sample clock (multi-device tasks can take an external sample clock) and configure the pause trigger on the counter task.  I'd expect to lose a little bit of synchronization (extra 10s of nanoseconds of skew) compared to the default multi-device task, but I wouldn't imagine it being a problem (especially given the use of multiplexed devices).

Best Regards,

[jon_mcbee]

I am not concerned about that level of skew in the synchronization.  How would I use one of the 6363's counters to generate the sample clock?

Thanks for the feedback.

[John_P1 · Accepted solution]

Configure a counter output task--something like this:

Then, configure your analog input task to use the counter's output as its sample clock:

Best Regards,

[jon_mcbee]

Thank you for putting that together, what do you have the"Trigger Source" input pointed at?

[jon_mcbee]

So if I understand this correctly, I am creating a pause trigger for a fake Counter Output task, and then using that fake task to time the acquisition of my multidevice continuous AI task.  The "trigger source" for the pause triggering on my fake task can be driven by PFI0.  That trigger will pause the fake task, which in turn pauses my actual AI DAQ task.  Likewise, un-pausing the fake task will un-pause the real task.  This relationship is created by using the fake counter output to time the real analog input.

Let me know what I am missing.

[John_P1]

Yeah, it sounds like you have the idea down.  The pause trigger will come from the PFI line you have hooked up your external signal to.  Pausing the counter output task will take away the sample clock form the analog input task, and so no new samples will be acquired while it is asserted.  De-asserting the pause trigger will allow the counter to continue issuing pulses and the analog input sampling will resume.

Best Regards,

[jon_mcbee]

Nice.  I am coding up an example now, but am unable to select the clock source you show (Ctr0InteralOutput):

Is this device specific?

[John_P1]

Right-click on the terminal and select I/O Name Filtering.  Then select Include Advanced Terminals.

What makes the internal counter outputs "advanced" I have no idea... but it certainly makes things difficult to explain 🙂

Best Regards,