delayed synchronized AO from AI

[whitsy]

Hello,

I am trying to run a re-triggered finite acquisition and then with some delay output that captured data on an analog output channel.  I have the analog input using a reference trigger, using pre-trigger signals, and use an external digital edge trigger to start the output.  The length of my signal is ~40 msecs and will be transmitting sometime after the whole signal is captured.

The vi appears to be working, I can capture multiple triggers of the analog input signal, and output the AO signal.  My problem is that on the first trigger of AI data there is no AO.  On subsequent triggers the AO will output the data captured in the previous trigger.  I am not sure how to resolve this.  Any help is appreciated.  Thanks, whits

I am using a PXIe-6363.   

[patrick.o]

Whits,

Thank you for uploading your code - it was very helpful in looking into your issue. I wasn't able to go through all of it in detail as it is very complex, but something that stood out to me is that you have no way of ensuring the analog input task starts before the analog output in the first iteration. 

I suggest you incorporate a master-slave coding architecture in your code to force the analog input task to run before the output task on the first iteration. Your output task should be the slave (start first) and the input the master task. Please see the attached picture.

Please let me know if this helps!

[whitsy]

Patrick,

Thank you for looking into my issue.  You are correct about the AO and AI are running asynchronously.  I had previously tried to use the AI start trigger to trigger the AO.  It would work at low sample rates < 100kHz.  This application will be running at 2 MHz and the AO was not right.  Also I was having trouble changing the delay between AI and AO, so I changed to an externally supplied AO trigger that the user can change on there own.  For my test setup I am ensuring that the input waveform is coming before the trigger.  For testing now I am using a separate PC with DAQ card and gps timing card to present the AI and trigger to my vi.  I am transmitting a 40 msec sine wave with a trigger 75 msecs from the start of the AI.

I was able to get the vi to work, but still have some questions/issues about initiating the AO.  The AO and AI are at 2 Mhz on my X series card.  I have the number of samples per trigger set to 110,000 samples with 10,000 samples saved on the pre-trigger, so I am sampling on the AO/AI 55 msecs, with 50 msecs after the AI reference trigger.  The AO start trigger then coms ~25msecs after that.  It appears that I need that 25 msecs to write the data to the daqMx write buffer and start the analog output.  If I take a longer amount of samples the 1st AO when I start the vi is missed and from then on the current retriggered AO will be from the previous AI and not the current one.

I guess my question is, when you are starting a finite AO, can you just write a subset of the data to the daqMx buffer, start the task, and then write the rest of the samples while the task is running, like a continuous task?  Thanks, Scott

[patrick.o]

Scott,

It's not clear to me what you're trying to do, what your overall goal with all this is. Could you maybe provide me with a diagram of the signals you're working with (input, trigger, output) and how they should be in relation to each other?

Also, when you say you previously tried to use the AI start trigger as a trigger for the AO and the AO 'was not right' what do you mean by not right?

We have good examples on finite analog output, but you may not need that for your application.

[whitsy]

Patrick,

I am posting a screen capture of what my vi is doing.  The yellow channel is the input analog signal.   The blue channel is a trigger when the analog input is generated.  The green channel is the analog output trigger, and the purple channel is the delayed AO of the input signal.

[Kevin_Price]

I don't understand your usage of the For loops in the posted vi from msg #1.  It's at odds with your description there of wanting to do an AI finite acquisition then send the same data out AO some fixed interval later.  You should simply read all samples from the finite task, enqueue them all at once in the AI code, then dequeue them all at once in the AO code, write them to the AO task, and start the AO task.

In msg #3, many of the timing parameters are described quite a bit differently and you're beginning to query about retrieving from and feeding into buffers on-the-fly as the tasks are already running and triggered.  Such things are conceivably possible, but overall you're venturing into dicey territory.  Any little timing hiccup in Windows is liable to lead to a buffer underflow for your AO.  And if you run this enough times, Windows *will* give you those hiccups.

I'd recommend you think about ways to structure this to get better defined behavior in the presence of such hiccups, even if it isn't your ideal behavior.  Here's a couple options:

1. Continue with fixed trigger timing.  Read all AI, enqueue, write all AO at once, start AO task and let it wait for trigger signal.  If you can't get AO started before the trigger signal arrives, tough luck.  No AO.

2. Drop the fixed trigger timing and go the "ASAP" route.  Config AO for no triggering.  Read all AI, enqueue, write all AO at once, start AO task.  You'll always get your AO on delay after the AI, but the relative timing will be variable.

-Kevin P