Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Start trigger selection for Analog In and Thermocouple task sync start

Solved!
Go to solution

What is the appropriate start trigger to use if I have an analog in task for a NI 9201 cDAQ module and a thermocouple task for an NI 9211 module that I want to synchronize the start of acq? I'm using two tasks because the 9211 can't operate at the sampling rate required for the voltage measurements.

 

I tried the code in the screenshot below but I get an error saying:

 

Error Code: -89131

An attempt has been made to perform a route when the source and the destination are the same terminal.

In many cases, such as when configuring an external clock or a counter source, you must select a PFI, PXI Trigger, or RTSI line as the source terminal.

Property: Start.DigEdge.Src
Property: Start.DigEdge.Edge
Source Device: cDAQ9188
Source Terminal: ai/StartTrigger

 

Testr00_0-1579811714454.png

 

 

0 Kudos
Message 1 of 6
(3,594 Views)

There are nice things about the cDAQ's flexibility for assigning its timing engines, but I think you're bumping into one of the possible side effects when it comes to signal routing.

 

It *appears* that DAQmx decided that your TC task would use the "ai" timing engine while your AI task would use "te0" or similar.  This is (seemingly) why the error suggests that you're trying to route your trigger signal back to itself.

 

I would try the following: 

- drop down a DAQmx Trigger property node and pick the StartTrig.Terminal property.  Make sure it's set to be a "Read" property rather than a "Write" property

- wire your AI task refnum into and out of this before the task is started

- wire the terminal output parameter into the 'source' input of your TC task's call to DAQmx Trigger.

 

This way, regardless of how the cDAQ chassis timing engines get distributed, you'll know you're referring to the correct one.

 

The rest of the dataflow sequencing looks correct -- the TC task is started first, but must wait to be triggered.  That triggering happens as soon as you start the the AI task because it immediately asserts its "Start Trigger" internal signal that you've tapped into.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 6
(3,570 Views)
Solution
Accepted by Testr00

Thanks for the information Kevin. I had to add a Control Task call before using the property node because the start terminal property can only be read after reserving, committing, or starting a task:

 

Testr00_0-1580158530619.png

 

 

 

Message 3 of 6
(3,049 Views)

Thanks for reposting the corrected, working code.  That's gonna help some folks who come across the thread in the future.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 6
(3,041 Views)

I've come across this thread.

 

I'm trying to synchronize an AO and a DO on from the same PCIe-6353.  Basically, I want to transition one DO high at the same time I transition the AO.  150ms later I want to transition that AO and DO back.


If I understand the above, I can set up the DO task as a bit of a slave to the AO by wiring as shown and the idea is that once the AO task starts it will send a trigger to the DO task and they'll be in sync?

 

Essentially, I'm hoping that I can do both tasks at the same time without having to add additional wiring to a PFI line or similar.

0 Kudos
Message 5 of 6
(2,870 Views)

You could, but I would opt to share a sample clock in your situation.  Let AO be master, configure its sample clock the normal way.  Then query a DAQmx Timing property node for its sample clock terminal and rate (after doing a "reserve" as shown in the earlier msg).  Feed these into the DO task's config call to DAQmx Timing.  Then start DO before AO.

 

The same internal sample clock signal will then drive both tasks.  Just define the data buffers you write to keep your output signals in sync.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 6
(2,866 Views)