Sync up Analog Inputs and Outputs from Several Cards

[Gregory]

Hi all,

I am very new to the DAQmx drivers, so please let me know if I'm leaving out any important information. Right now we have a setup that uses a PCI-6733 to provide 6 AOs to the DUT and a PCIe-6259 to read 2 differential AIs from the DUT. I want to expand this to work with many DUTs (16), where each will now require 12 AOs and still 2 differential AIs.

For this station I've purchased 3 of the PXIe-6739 cards (64 AOs each, 192 AOs total), and 2 of the PXIe-6363 cards (16 diff AIs ea, 32 diff AIs total) along with a PXIe-1073 chassis. 

I have some example code I got working with 1 AO card and 1 AI card, but I'm not sure how to expand it to 3 AO cards and 2 AI cards. The research I've done tells me I cannot have multiple AO cards on a single task, is that correct?

Here is my code for creating the tasks:

Will I need a different task for each card?

Here is my code for applying my stimulus on the AO channels, and reading the response on the AI channels:

Will I need to break my stimulus array into 3 parts, and send each one to a different task, corresponding to a different card?

Thank you for any help and comments!

[Kevin_Price · Accepted solution]

You're definitely on the right track.  6733 boards support one hw-timed AO task per board, no sharing across boards.  Can't speak for the newer boards you mentioned.  There *is* a subset of DAQ boards that supports multi-board tasks, though that support may only apply to input tasks, and maybe only AI.

The way you shared a sample clock for AO & AI will extend cleanly to multiple tasks.  Just keep track of whose signal is the master sample clock and start that task last.  To generate the same AO in sync on multiple boards, feed each task a copy of the same AO waveform.

My only other tip is to consider one of the following:

1. Configure your AO to generate on the *leading* (probably rising) edge of the sample clock and your AI to acquire on the *trailing* (probably falling) edge.

2. Same idea, but with more control.  Create your own clock with a counter and configure all tasks to use it as a sample clock.  Configure the duty cycle to place the AI sample clock edge at whatever phase you choose relative to the AO clock edge.  With only 2 AI channels to multiplex, you can probably push this to 80-95% duty cycle to give your system more response time prior to sampling.

-Kevin P

[Gregory]

Hi Kevin,

Thank you very much for your feedback. All of the AO waveforms are in fact different, so I will have to handle that array carefully. Besides that, I think I can handle extending this to multiple cards. 

I do not understand your point (1) of configuring the output and input to use different edges of the clock. Would this give me more accurate signals?

[Kevin_Price]

Using different edges of the sample clock is something I've often found to be appropriate for AO stimulus and AI response.  I like it when the 1st AI is acquired some short time *after* the 1st AO is generated, allowing the UUT at least a little bit of time to react to the AO and perhaps reach a more stable state for the AI measurement.

It isn't always crucial, it's just become a habit and general practice for me.  The times I care most are when the UUT's step response speed is faster than the sample rate.  Then the next goal is to fit all the AI multiplexing into the time window between stable response and next sample.

For example, I have a set of analog-driven electronic loads whose stable response is right around 6-7 msec.  I set up counter-based clock with a constant 10 msec pulse width and a mininum 20 msec period (so that the stim/response timing remains the same over a range of sample rates).  AO occurs on the leading edge at 0 msec, AI starts at 10 msec when the response is stable, multiplexing is set for 4 kHz on 16 channels and occurs over the next ~4 msec.  So all the AI is done before the next AO sample.

If I had used the same edge for AO and AI, I'd risk having my AI channels at varying degrees of response at the time I multiplexed them in.

-Kevin P

[Gregory]

I see, thank you for clarifying!

All of my AOs will be a DC voltage with an AC sine wave of 0.05V amplitude on top. So if the DC is 3V, the actual signal is a sine wave going from 2.95V to 3.05V. The response should have 1f and 2f components of the sine wave in it, and the algorithm will try to minimize one of those components by changing the DC voltage.

I'm not sure if the algorithm cares about the phase of the response, or just which frequency components are present, but it's definitely something to play around with!

[Kevin_Price]

Offhand, it doesn't sound like your analysis is likely affected much by delaying acquisition to start a fraction after generation. Decent sine wave generation probably means a sample rate much higher than the waveform freq.  Looking for frequency components of response probably means analyzing across multiple cycles of your waveforms.

So the crucial response of your UUT (1f and 2f) is slower than the sample rate *and* you aren't analyzing on a pt-by-pt basis.  If intrigued, I'd recommend trying the version where you use a counter to generate the shared sample clock.  Then you can play around a bit to see whether duty cycle changes have any discernible effect on your analysis results.

-Kevin P

[Gregory]

After a little more research, and trial and error with simulated DAQ modules I've changed my code a little bit.

I can simulate the 6363 (AI card) and it looks like it supports "multidevice tasks", so I can read from both AI cards in a single task. The 6739 cards are not available for simulation, but the 6733 cards are (8 channel AO). These do not appear to support multidevice tasks, so I create the tasks in a for loop. I was getting some error when naming the sample clock and start trigger for all the AO cards, so I use the highest numbered AO card as the master and skip the naming in that case.

Then to apply my stimulus I split the signals into an array of clusters, each cluster containing the stimulus array for a single AO card, and keep most of the other stuff the same.

When I run with the simulated DAQ cards I get some error related to "writing data past the last time point available", which does not occur in highlight execution mode. I'm hoping it's some odd behavior with the simulated 6733 cards and will go away when I use my actual 6739 cards.

Are there any obvious oversights on my part?

[Kevin_Price]

Definitely wouldn't say there are any *obvious* oversights, it seems to be coming together pretty well.  The error text *sounds* like your stimulus waveforms might have more samples than the size of the finite sampling buffer (defined in call to DAQmx Timing).  But I don't see why highlight execution mode would make a difference.  I wouldn't rule out your hope that it's a side effect of using simulated devices, and wouldn't be overly concerned until you get on your real hardware.  By and large, you've got things in good shape.

Just one small note on triggering: I can't see how you've set up a trigger for the master AO device.  Are you needing to sync to some external signal?  Or are you just using a trigger because it seems like the right thing to do for syncing multiple tasks across different boards?  If it's the latter, you may be able to get rid of the triggering all together.  I often rely on shared sample clocks alone for task sync, as long as the master task starts last.

Even if you need to trigger off an external signal, you probably only need to configure your master task for it.  

-Kevin P

[Gregory]

Thank you again, your help is very valuable. The odd thing with the number of waveform samples is that I have tested this on an older setup with a 6733 card using only 6 channels not 8. The waveforms always have 1024 elements and I have never seen that error.

I saw the use of triggering in a colleague's code so I thought it was the right thing to do. After disabling it, I cannot see any difference in how the code operates, that's great! As a side note, I also didn't notice a difference when playing with the clock edge for the AI signals, choosing "rising" or "falling" seemed to give the same behavior.

[AgentFox12]

Hi,

 I have a quetion about your AI.vi.Is your DAQ.Sampling an input cluster and which parameters did you use to prepare ?