Error 200077

[rolfk]

PXI(e) cards don't have a RTSI connector since the PXI bus provides optional trigger lines already. National Instruments was involved in the specification of the PXI standard and made sure that this functionality was added to the specification, but since it's an additional cost for boards and backplanes it was made an optional part of the specification. Mainstream computer manufacturers don't see much use in implementing additional requirements in a specification that only increases the price but won't benefit a large part of their customers.

The PXIe-1071 supports PXI trigger lines, so you should be able to synchronize multiple PXI cards with each other.

When you setup DAQmx tasks you can specify where the clock needs to be sourced from as well as what trigger to use. Default is to use a dedicated clock circuit on the board with a configurable frequency, but you can define other signals such as a PFI signal or a RTSI or PXI trigger line. The same is true for the trigger which starts the acquisition (or generation).

You do this with the DAQmx Timing and DAQmx Trigger functions where you can select a source from which to get the clock or trigger from. Without an explicit source the timing will use an internal timer to create the necessary clock.

Setting up multi-device acquisition through synchronization and external triggering is always a bit cumbersome because there are so many different options and the order of execution of functions can be quite important to get it to work correctly. If it doesn't work it can be a bit tricky to find out why. NI provides some examples that do a fairly good job in showing how to do these things with specific cards but your task is to understand them for each of your involved cards and combine them in a meaningful way, which can be quite a bit of tinkering.

[Kevin_Price]

rolfk is, as usual, spot-on.

Let me retract my 6363 suggestion.  I didn't go back to re-read earlier msgs in the thread and was focused on finding more analog *input* channels.  Most apps around here with need for lots of channels are dealing with *input* channels rather than outputs.  After skimming back a ways, it looks like you need *output* channels.  So for more outputs, a PXI device that stands out is the 6738.  You'd need to pair that a device (or combo of devices) that handle your DO needs.

I tend to get involved a lot in discussions about sync'ing DAQmx tasks.  The reason so many such threads arise is that there are indeed a lot of options, and then also certain operations must be sequenced just right.  Just as rolfk alluded to.

However, it also doesn't have to be tremendously cumbersome.  Especially when working off the PXI platform which manages a lot of the timing signal routing pretty seamlessly.  A lot of times my advice boils down to these 3 things:

- designate a master task that shares its sample clock with your other tasks

- be sure all the other tasks have been started before starting the master

- read the same # of samples each loop iteration from all the tasks that are sync'ed this way

It's pretty common that you don't need to configure any triggering at all.  The master task's sample clock only starts "clocking" when you start it, and when all tasks share that same clock signal, they're inherently pretty well sync'ed.  Also, the advice to read the same # samples from all the tasks assumes you'll service all tasks in the same loop.  If you service them in independent loops, you're more free with how you break down the # samples per loop vs. loop iteration rate trade off.

I tried looking for prior posts of mine about sync and found fewer examples than I expected.  Here's one with a very partial snippet whose left half illustrates most of my main points.  Over there the AI task is the master, there's a call to DAQmx Control Task to "reserve" resources and thus assign an internal terminal for the sample clock, then that terminal is queried and used as the sample clock source for the other task.  Finally, the error wire is used to force the master task to start last.

-Kevin P

[sujitgarain]

Thank you for the detailed reply. Though I couldn’t understand all the technical thing you talked about as I am very new to use this Labview programming, but I could roughly understand what you want to say. So as you said also we can use PXI 6738 for digital output and PXI 6535 for Analog output. The synchronisation  of 8 lines  of one channel has been done using your great help. So if we face any problem in future with synchronisation of two PXI (basically the output channels of analog and digital PXI  cards) I will let you know. So I am asking your opinion weather we can go for PXI 6738 and PXI 6535 for our expt as you were there from the beginning of this problem. Thank you both of you.

[Kevin_Price]

I don't have experience with the 65xx family of dedicated digital boards so I quickly looked up the datasheet.  It *appears* to me that the combo of a 6535 for digital output and a 6738 for analog output should be able to operate in sync using the fairly straightforward method I mentioned and linked.

Thanks to rolfk's warnings about restrictions for routing timing signals, I looked through the 6535 specs a little closer.  It can only import a sample clock from 1 specific PXI trigger line source.  Using the approach I illustrated in the link, DAQmx would be able to figure out the appropriate routing. 

    However in a busy system with other tasks operating, that PXI trigger line might already be in use for other purposes, preventing the 6535 from using it to get its sample clock.  That'd make me inclined to let the DO task on the 6535 be the master task because it will hopefully have more options for PXI trigger lines to which it can export its sample clock.  The 6738 will have plenty of flexibility for either import or export.

-Kevin P