Synchronize two DAQmx tasks on different cards with a counter

[cx05]

Hi,

I'm trying to synchronize two DAQmx (PCI-6133 and PCI-6733) cards with a counter. The cards are connected with a RTSI cable. I'm using the 20MHz reference as well as the counter output of one card to synchronize an AI to an AO task. Both tasks are triggering on the counter and use sample clocks based on the common reference.

The synchronization works fine when I run the VI once. However, when I try to put the code in a loop and use it for a synchronized frequency sweep (synchronized sample clocks and common starting time are my requirements), the synchronization works only on the first iteration.

I've routed the counter output to a PFI DO and confirmed with a scope that the counter frequency gets updated within the loop. There is a glitch at the beginning to the signal, but I think this might be related to the routing. As the problem persists when I add lots of delay after starting the counter, I think the problem has to be somewhere else.

I also noticed that the problem does _not_ occur if I do not change the frequency within the loop.

I've attached a minimal version of the VI.


Any help is greatly appreciated.

[reschri]

Hi,

Do you get an error of some kind? What exactly is not working?

Regards

René

[cx05]

Hi Rene,

thank you for your reply.

I do not get any errors. The acquired output signal is simply not synchronized with the acquisition time window after a few iterations. I'm using a simple connection directly from the AO terminal to the AI terminal to check if the synchronization works. The Phase shift is getting > 90° after 5 iterations, so it seems to be related to the trigger because clock drift should be much less in case that the synchronization doesn't work.

The first iteration is always perfectly synchronized (variation < 1°), but it seems I cannot create new tasks that trigger correctly after the first iteration. This is strange because it is exactly the same code that works in the first iteration. It seems to me that something is done internally when the VI stops that does not happen when I stop and clear the task.

What is also strange is that the problem does not occur if I do not change the frequencies of the counter and the DO task in the loop (see the case structure at the end of the sequence).

I'm really not sure how to address this problem because I cannot figure out the cause of the issue. If you have any ideas how to approach this issue, I can gladly do additional measurements. As I have written before, the counter signal seems to be correct and is updated within the loop. The AO frequency is also correct. It's just the trigger that does not work. 

I narrowed it down to the AO task not triggering correctly (see the attachments) as the AI task seems to be aligned perfectly with the trigger event. The strange thing is that the AO task runs on the same card as the counter. Changing the AO from "continuous samples" to "finite samples" has no effect.

Regards

Christian

[cx05]

I updated my example. I attached the updated VI below. I corrected an error that was present in the demonstration but not in my production code. The measurements from the previous post have been made using the VI from this post.

[reschri]

Hi!

The cards are not sychronized with the PC-System Clock, which creates the time stamp. Are you determining the lack of sychronizsation with the time stamps? It could be, tat you measurment are perfectly in sink but you getting the impression of asychronous behavior because of the time stamps

How Accurate is the Timestamp of the Waveform Returned by my NI-DAQmx Device?

http://digital.ni.com/public.nsf/allkb/5D42CCB17A70A06686256DBA007C5EEA?OpenDocument

Regards,

René

[cx05]

Thank you for your reply. I'm pretty sure that the cards are not synchronized, because when I capture a finite sample count of a loop back connection, the acquired signal has no constant phase relative to the start of the acquisition window. The absolute time is never used for the phase calculation.

As I have written before, the trigger signal matches exactly the start of the acquisition window. Therefore the acquisition seems to be triggered correctly but the analog output task seems not to respect the trigger.

Please have a look at 

http://forums.ni.com/ni/attachments/ni/250/77910/4/SweepExample__completep%20iteration6.png

 in contrast to 

http://forums.ni.com/ni/attachments/ni/250/77910/2/SweepExample__completep%20iteration0.png

As you can see, the white signal changes its phase relative to the trigger signal (red) and the start of the acquisition. The trigger signal itself is perfectly aligned with the beginning of the acquisition and does not show any jitter or phase variation.

My card has simultaneous sampling, so the two channels show the same time frame.

Regards

  Christian

[reschri]

Hi!

I deleted all the Hardware-Tasks off you VI and got a Phase shifted output on the Sine Wave.vi - only using the sweep function of your vi. that woul indicate the phase shift comes from the sine wave.vi

Your are not specifying a phase here. Try cabling a zero to the Phase input, then the VI is forced to start at a specific phase. It seems a liitle bit strange as I could reproduce this behavior only once - but it was definitly a 90° phase shift. Try to cable a zero to the phase input of the Sine wave.vi or replace it with a low level funktion.

Compare your output sinus waveforms from the sine wave.vi in each Iteration, for example by writing the output waveform in a 1-D Array which is populating over shift registers and cabling it to a graph. Ckeck if there is a face shift in the software generated output.

Regards

René

[cx05]

Hi,

thanks for your efforts to solve this.

I have now a constant zero at the input of the sine generation vi and have monitored the output on a separate graph: There is no phase shift in the generated waveform.

In the read back data however, the phase shift still appears.

Regards

  Christian

[reschri]

Hi again,

Sorry that it didn´t work out so far.

When I interprete your code correctly, your doing the following:

1. Configure a counter task to Trigger your analog tasks. You route the counter Signal to the RTSI-Bus, and you start this signal right away

2. Then you configure your AO, configure to listen to RTSI for the trigger rising edge

3. The you configure your AI also listening to the RTSI for a trigger

What you doing differently then I would expect: Why do you configure the triggering task first and start it right away? I would propose: configure the analog tasks to wait for a trigger, start them, so you can be sure they are "locked and loaded", then start your counter task, triggering the AO/I

You use timing in between the configuration steps, which is not productive as you have no control over how fast the tasks are created. In Windows, the task creation takes a non-deterministic amount off time.

I would change the order of the task creation or (which is easier to change) put the start task of the counter output at the end of the sequence, after all the task are ready.

Regards

René