How do I synchronize multiple devices with DAQmx?

[RGA]

I'm finally getting around to updating some VI's to DAQmx and I'm having trouble getting the devices to synch up.

Here's what I need to do: I have a PXI chassis with four AI cards (6133) and three counter cards (6602 and 6608) that need to all start at the same time.  The AI cards are doing AI and the counters are configured to read three quadrature encoders each.  So I need to take an analog start trigger from one of the AI cards and use it to start the AI operations on the other AI cards as well as the buffered encoder read on the counter cards.

Back in the good ol' days, I just used RouteSignal.VI to dump AI start trigger onto RTSI1.  I then had all the other boards start their operations on RTSI1.

When I use the "DAQmx Connect Terminals" VI, I get an error when I try to send a signal onto RTSI1 ("Terminal Invalid").  It seems like that VI only connects specific terminals; i.e., it seems I have to specify the source/destination terminals for every combination of terminals among my several boards (!).  Furthermore, the choice of trigger channel is set at run time, so I can't just have all of the operations look to a single terminal.  Sometimes it's slot 3 channel 1, sometimes it's slot 6 channel 4, etc.  Using RouteSignal.VI, I used to be able to tell everything to look to RTSI1 for a trigger, then whichever channel is the trigger channel sends its AI start to RTSI1.

So, using DAQmx, how do you do the equivalent of sending a single trigger on a single line and have all of the other boards wait for that signal by watching that line?

Thanks,

rgames

[Kevin_Price]

On a desktop PC, you would first define a "RTSI cable" device using MAX and then identify which boards are attached to it.  Only then will you be allowed to share timing signals between boards. 

It seems a bit silly to have to do that on a PXI system, but perhaps you have to define a pseudo-RTSI cable there as well?

-Kevin P.

[RGA]

I don't think the physical connections are the problem - it's the software.  Everything works fine under traditional NI-DAQ: I can drive signals onto the RTSI bus all day long!  I can't figure out how to do it via DAQmx, I can only connect individual terminals on specific boards.  It's almost like there is no common bus...

rgames

[TedAnderson]

I went to a lot of trouble nearly two years ago to figure this one out.  You don't need to mess with RTSI with a PXI chassis.  The only time you would need to use some hardware for synchronizing would be with multiple chassis.
Assuming a single chassis and M-series hardware, the vi that I am attaching sets up all of the PXI-6225 cards as slaves, except for the first one, the master, with its task called "Slot_2". The tasks are defined ahead of time in MAX.  In this case, they are called Slot_2, Slot_3, etc and consist of AI Channels 16 through 79. When the Slot_2 StartTask vi begins in the middle frame of the flat sequence, it triggers the slaves with the digital edge of the 10MHz ref clock.  The slaves have already been set up with PXI1Slot2/ai/StartTrigger as the Trigger Source (see violet-colored constant at the left side under Error In).
Someone at NI can probably explain better at this point the details, as my recollection is a bit hazy since so much time has elapsed.
Good luck!

[TedAnderson]

Here is the attachment referred to in my earlier reply...

[Nick_CH]

Hello rgames and all the new user of DAQmx,

Since last year, National Instruments offer a web page called www.ni.com/gettingstarted where you can find the entier information you need about the driver NI-DAQmx such Synchronization in NI-DAQmx

Best regards
Nick_CH

[RGA]

Thanks for the replies - the DAQmx page looks like it might be a good resource.

The only problem with these solutions is that they are not configurable at run time - you have to pre-define the master and slave devices in the VI block diagram.  This app requires the trigger device to be picked at run time: sometimes it's in slot 2, sometimes its in slot 4, and sometimes it's an external digital trigger going to one of the counter boards.  That's why I use the RTSI bus - the user picks his triggering mode/channel and the software routes that device's start to RTSI1, then all of the other devices look to RTSI1 for their triggers.

It used to be a piece of cake with RouteSignal.vi - it turns out there IS, in fact, a similar VI in DAQmx: DAQmxExportSignal.vi.  Once I found that, everything else was cake!  The reason it took so long to find is that it is not, for some reason, listed among the "Signal Routing" VI's.  ???  Makes sense to somebody, I guess...

At any rate, DAQmxExportSignal.vi seems to be functionally the same as RouteSignal.vi, so I've managed to get everything synch'ed in the manner I described above.

Thanks again,

rgames

Message Edited by RGA on 07-19-2007 06:53 AM

[Jonathan_Brumley]

Hi rgames,

Because DAQmx allows you to pull signals from another device, most applications will want to use the Timing or Triggering property nodes to import a signal that is being generated by a task running on a different device.  First, I'll explain how to get this case to work, then I'll explain some additional scenarios where you might want to use Export Signal VI or Connect Terminals VI.

1. Make sure in MAX you "identify" your PXI chassis, if you haven't already.  First, to identify the system open MAX > My System > Devices and Interfaces and identify the controller (e.g. PXI-8176).  Second, richt click on the Chassis and identify the chassis type (e.g. PXI-1000).  When you identify your PXI chassis, you are telling the DAQmx driver which terminal names are available and how to program them.  Otherwise, DAQmx treats the PXI chassis like a PCI bus without trigger lines.

2. The terminal names on the PXI trigger bus are "PXI_Trig0", "PXI_Trig1", etc.  Not "RTSI1".  If you have identified the PXI chassis correctly, then the available terminal names will show up in the terminal name control (e.g. "Dev1/PXI_Trig0").

3. In your program, start the task that generates the signals (e.g. on Dev1)

4. Next, in your program, configure the task that is to receive the signal on Dev2, but configure that task's Sample Clock Source to come from "Dev1/ai/SampleClock". 

If, at run-time, you want to switch between tasks that receive the same signal, that's fine, you can still use the Timing, and Triggering property nodes to do this.  Each task can be configured to "pull" the same signal. When each task is complete, it will disconnect itself from the device generating the signal, and now you can start a new task using the same signal. 


OK, now you know how the basic scenario works.  However, you were asking: how do you export a task signal to the PXI bus without routing it to another device?  For this case, you should use the Export Signal VI.  If you just want to export the signal to PXI_Trig5 on Dev1 that is running a task, then just select the signal you want to export and select a destination terminal of "Dev1/PXI_Trig5". 

If the signal you want to export is NOT generated by a task (for instance, the 20 MHz timebase on a device), and you just want to export this signal to the PXI trigger bus, that is a good case for using the Connect Terminals VI like you are trying to do.  Connect Terminals VI is a low-level VI that works a lot like Route Signal VI in Traditional DAQ.  For instance, to export a device's timebase, just select a source terminal of "Dev1/20MHzTimebase" and select a destination terminal of "Dev1/PXI_Trig5".

If the terminal I/O control isn't showing you the terminal that you want, try right clicking on the Terminal Name control, select I/O Filtering, and select "Include Advanced Terminals".  Now you will see all the terminals in your system.


Hope this helps you get your signals where they need to go!

-- Jonathan

[Jonathan_Brumley]

One more comment:

It is a confusing that Export Signal VI isn't in the Signal Routing palette.  I guess the motivation for this was that Export Signal is a task-based function,  but not as common as the Timing and Triggering property node.  Therefore it was put in Advanced Task Options. 

Here's a quick guide:

a) Do you want to route a terminal to a task?  Use the Timing or Triggering property node.
b) Do you want to route a task signal to a terminal?  Use the Export Signal VI
c) Do you want to route a terminal to another terminal?  Use the Connect Terminals VI

[RGA]

Hi Jonathan - good info there.  Thanks!