LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx analog input synchronization with PCI-6132 (S series) and PCIe-6376 (X series) devices

Solved!
Go to solution

Hi, 

I need to acquire data with my two acquisition cards. I'm running an example called  Analog Input - Synchronization.vi from the DAQmx examples. The description of the example is this : '' This example demonstrates how to acquire a continuous amount of data (Waveform) using the DAQ device's internal clock.  It also shows how to synchronize two devices for different device families (E Series, S Series, M Series, X Series, DSA, and SC Express), to simultaneously acquire the data.'' This is exaclty what I want, but I keep getting errors and the example is not working at all. Has anyone ever managed to get this example to work with other types of acquisition cards ? If yes can someone tell me if it's possible to mixed two acquisition card together ?  

Thank you

0 Kudos
Message 1 of 12
(1,006 Views)

@RaphaelHenri wrote:

Hi, 

I need to acquire data with my two acquisition cards. I'm running an example called  Analog Input - Synchronization.vi from the DAQmx examples. The description of the example is this : '' This example demonstrates how to acquire a continuous amount of data (Waveform) using the DAQ device's internal clock.  It also shows how to synchronize two devices for different device families (E Series, S Series, M Series, X Series, DSA, and SC Express), to simultaneously acquire the data.'' This is exaclty what I want, but I keep getting errors and the example is not working at all. Has anyone ever managed to get this example to work with other types of acquisition cards ? If yes can someone tell me if it's possible to mixed two acquisition card together ?  

Thank you


The example should work as both of your devices are listed in two separate lists, which meets the example's requirements.

 

For better help, you should state what error your received and what kind of Synchronization Type did you try. Otherwise, try every sync type in the example and see what works.

 

mcduff

 

EDIT: Thought your hardware was PXI, looks like it is PCI in a computer tower. I believe you need a cable that connects each card internally. I think it is called a RTSI cable.

0 Kudos
Message 2 of 12
(973 Views)

 

As mcduff mentioned, a RTSI cable needs to be attached between the boards to allow the sharing of a timing signal bus.  You would need to configure the RTSI cable in MAX and identify the boards that it's connected to.   *THEN* DAQmx will be able to do various kinds of automatic routing of timing signals to perform sync across different boards.

 

The alternative would be for you to explicitly configure the appropriate signals to be exported and imported from external PFI terminals, while also doing screwdriver & wire work to make physical connections.

 

After all that, my main comment on that particular example is this: I believe that in the very vast majority of cases, the approach shown is overkill, unnecessary, and more trouble than it's worth. 

 

In over 20 years doing DAQ apps, many involving multi-device sync schemes, I have almost never explicitly configured a RefClk or a SyncPulse.  I've rarely found the need to configure the Master Timebase either.

 

My preferred approach for sync when both devices have the *same* sample rate is to share a sample clock.  Designate one device as master, configure the other device to use its sample clock, and then start the master *last*.  And that's all.  No RefClk.  No SyncPulse.  No Master Timebase.  No Trigger even.  Just a shared sample clock.

 

Here's a first snippet to illustrate what to do if you have a RTSI cable attached and configured so that DAQmx can figure out routing for you.

 

Here's a second snippet to illustrate what to do if you have to make your own physical wiring connections between PFI terminals.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 3 of 12
(969 Views)

Hi mcduff, 

Thanks for your reply. I did try every sync type in the example.  I keep getting this error :

Error -200452 occurred at Property Node DAQmx Timing (arg 1) in Analog Input - Synchronization.vi.   

Possible reason(s): Specified property is not supported by the device or is not applicable to the task. Property: RefClk.Src.

 

For the RTSI cable, I looked at it and I think it might work, but i'm not sure that the example we are talking about will work. 

0 Kudos
Message 4 of 12
(934 Views)

As @Kevin_Price said you will definitely need the cable to attach the two devices.

 

I have used a Reference Source to sync two cards together in a PXI chassis; a 6366 (X-device) and a 4499 (DSA device) running at different sample rates. It worked well.

 

If you don't have the cable, I highly suggest you follow @Kevin_Price's suggestion to use alternative methods of syncing the cards. He is a DAQmx savant and his advice carries greater weight than mine.

 

mcduff

0 Kudos
Message 5 of 12
(931 Views)

Hi Kevin P, 

Thanks for your help it is really appreciated. 

I looked at the two examples you sent. I think the RTSI cable is the simplest way to connect my two devices. I'm doing lockin detection and I need the two acquistion cards to be sync very well. Let's say I connect my two devices with a RTSI cable, do i still need to manage a clock and to determine a master and a slave.? Or by connecting the two together with a RTSI cable it is considered by DAQmx in Labview (physical channel) has only one device ? In that case, my guess is that the maximum sample rate will be determine by the acquisition card with the lowest sample rate. 

Thanks again for your help

Raphael

0 Kudos
Message 6 of 12
(926 Views)

How are you setting up Lock-in Detection?

 

Are you inputing two references Sin and Cos and mixing the two input signals? Is the frequency stable? What type of low-pass filtering are you doing?

 

If the frequency you are measuring is stable (within the bandpass of your low pass filter), and the bandwidth of your low pass filter is not too low, you may be able to generate your own sin and cos internally and mix the input yourself. I did this with a myRIO and got I & Q out. That may eliminate the need for a second board.

 

mcduff

0 Kudos
Message 7 of 12
(922 Views)
Solution
Accepted by topic author RaphaelHenri

The RTSI connection is simply a bus for sharing (potentially high speed) digital timing signals across devices in a desktop PC.  Nothing more.

 

When MAX is configured to know about it, it can use its knowledge of those board-to-board connections to automatically route certain timing signals when called for.

 

But there are no further assumptions about treating 2 devices like 1 virtual device or any particular master/slave arrangement.

 

The example I linked will get you started.  But it will only work after you have a RTSI cable installed and configured in MAX.  A RTSI cable just uses 34-pin ribbon cable & connectors.  These were still commonplace for 5.25" floppy drives (!) back when I was getting started with DAQ in LabVIEW.   You can probably source a 2-device connector pretty cheaply.  Not sure if anyone other than NI makes the multi-tap ones available.  (Though ribbon cable connectors are relatively user-friendly to add manually inline along a cable.)

 

The notion of master/slave is just a bit of convenient terminology, nothing more.  The task(s) designated as "slave(s)" depend on timing signals from the "master" task, thus any slave tasks get started first so they're ready and waiting when the master task starts last and starts producing those signals.

 

Yes, you'll have to limit yourself to a sample rate supported by both devices.  That's an A/D hardware limitation, RTSI connections don't change that at all.

 

 

-Kevin P

 

[Edited after posting and seeing mcduff's reply]

 

P.S.  I know nothing about "lock-in detection".  So whereas mcduff deferred to me on DAQmx generally (perhaps a bit too quickly, b/c he's plenty good too), I'd urge you to *definitely* defer to him on anything specifically related to "lock-in detection.".

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 8 of 12
(918 Views)

I did try to generate a ''virtual'' reference signal, but the results were not good enough for our application. We thought about it before buying the second acquisiton card and we tried it with one DAQ. Right now, I'm using a simple function generator at 10 kHz where I read the DLL output with my DAQ. On my system, I have 8 channels, so I need a total of 9 channels (8 + ref). My goal is to read the reference signal with one DAQ (PCI-6132) and to read the signals from my 8 channels with the PCIe-6376. Then I need to multiply these 8 signals with the reference signal for lock-in detection. My lockin in Labview is working well with one DAQ and is not the problem. Now I have trouble with the acquisition of data with both cards. When I bought the PCIe-6376, I had the confirmation from National Instrument that it was possible to acquire data with the two cards simultaneously, but they didn't told me about the RTSI cable. 

0 Kudos
Message 9 of 12
(914 Views)

Thank you Kevin, 

This helps me a lot. I will buy a RTSI cable form National Instrument. I will look for more documentation on how to exactly work with it, because right now I don't understand perfectly everything you told me. Your example will certainly help me. I will post an edit when I receive the cable to share with you if this solution worked. 

Thanks a lot !

Raphael

0 Kudos
Message 10 of 12
(910 Views)