From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization for AI and AO with non-regeneration of output waveforms

nathan7,


You mentioned something about your waveforms (in and out) not appearing sync'd.  I looked at your latest picture and I didn't see a start trigger for the analog input.  Wouldn't you need to trigger both tasks from the same trigger to have them sync'd (started at the same time)?  You have both sampled at the same time, but not started at the same time. 

 

I would put both of your start task VI's in parallel if you want a better chance of them really starting close together.  Unless you don't mind the possibility of losing a few samples depending on the rate of your trigger.

0 Kudos
Message 11 of 13
(701 Views)

Hi JoeWork,

 

Thanks for the reply, I'll have a look at the parallel loop approach. As for the trigger, I'm following this much-cited example https://decibel.ni.com/content/docs/DOC-26326 , where there's only one trigger.

 

To be honest, I'm not even sure a trigger would be necessary, as I'm able to sync input and output by simply sharing their clock in the case where the waveform generation is outside the main loop. My main point being, I think the issue is in having the output generation inside the loop, but, due to my extremely limited knowledge of DAQ systems, I don't know why.

0 Kudos
Message 12 of 13
(692 Views)

You absolutely do NOT want to start the tasks in parallel... you need to start them sequentially (as you are currently) so that the task generating the clock starts after the other task.  This ensures that the task receiving the clock is armed in time for the first clock edge.  You might consider reading/writing in parallel however (see #2 below).

 

Sharing sample clocks is acceptable with the modules you are using (some other modules cannot accept external sample clocks so this isn't always the case).  If you are sharing the sample clocks directly, sharing a start trigger becomes unnecessary--you could trigger the "slave" task immediately and it will not generate/acquire its first sample until the first clock edge anyway.

 

 

Here are the issues you should focus on instead:

 

1.  The program is resetting the phase of the generated waveform on every loop iteration.  For now, set the reset input to FALSE--though you won't be able to change the phase while the task is running, it will be a good starting point.  Once everything else is working, if you do want to change the phase while the task is running you'll need to do something like what is shown here (look at the "update phase" attachment, the screenshot doesn't show it). 

 

2.  Reading the default of -1 samples will give you an unknown amount of data from the DAQmx Read on each loop iteration (whatever happens to be in the buffer at the time).  It will very likely not line up with the analog output waveform that you are intending to compare it to.  However, simply specifying to read "Number of Samples" won't work either, since the read call will then block execution of the loop until all of the requested data is available, at which point the AO buffer will likely have underflowed.  Here are a couple of possibilities that would get around this:

 

i.  Read and write in parallel loops.  The output can run as quickly as necessary to prevent underflows without having to wait for the analog input data.  If you want to compare the input and output data though you'll have to buffer the output waveform somewhere until the read has completed.

 

ii.  You could keep the program single threaded but write extra data to the AO task at the start, as demonstrated here.  You would have to write enough data to ensure that the output buffer has enough samples to generate while you are waiting for the AI read to complete.  It would be easiest to write some multiple of however many samples you intend to write per loop and you could use a shift register to keep track of the output waveform (from N loops prior) for comparing it to the AI input.

 

3.  This one is easy, but you should use the coerced sample rate from the task that is generating the sample clock to specify the timing for your waveform generation.  You should also probably specify the rate on the slave task from the coerced sample rate of the master task.  So for example, if you are using the AI Sample Clock for both tasks, specify the rate of your AO task as the SampClk.Rate from the AI Task, and specify Fs for your waveform timing for the generation to be the same.

 

4.  The block diagram wiring is a bit messy 🙂

 

 

 

Best Regards,

John Passiak
0 Kudos
Message 13 of 13
(673 Views)