Why are my slave analog input tasks not synchronizing to the master in my PXI chassis?

[TedAnderson]

Hello all,

I'm having trouble getting multiple analog input tasks to synchronize.  I'm not getting errors, but as you can see in the attached front panel, the data are being sample at significantly different times.  In the graph, two channels of 4 samples from each PXI-6255 are displayed.  In this graph, the maximum difference in starting time between tasks is 12 msec.  When the vi is run repeatedly, the master task (shown in the graph with square markers) can fall at any point in time relative to the other tasks, before, after, or between.  There appears to be no synchronization whatsoever.  BTW, the multiplexer skew between the first and 64th channel being sampled can be seen in the graph.  This corresponds to an acceptable interchannel skew of 11 usec.

This vi was intended as one that could work with any number of PXI cards in a single chassis.  An earlier revision (2 years old) of the vi had multiple versions, one for 4 cards, one for 12 cards, and one for 16 cards.  In these older versions of the block diagram, the slave tasks were defined in parallel rather than iteratively in a loop.  The old versions synch properly.

The following reference, along with others, was used to confirm the method selected for use in my vi:

http://zone.ni.com/devzone/cda/tut/p/id/3615

The block diagram from the tutorial is included here for quick reference.

Please have a look at the attached pdf and see if anything appears to be missing or improperly configured....

Thanks in advance for your assistance,
Ted Anderson


Message Edited by Bairoa on 06-12-2008 12:55 PM

[tnek]

Hi Ted,

I took a quick look at the pdf that you attached. One thing I noticed was that you were also calling your DAQmx reads in serial. This will affect the timestamp of the acquired waveform. Since the t0 returned is based on when the function was called, you will see timing differences between different tasks. More information about this effect can be found in this article or in the DAQmx Help under "Waveform Timing Limitations". One way to check for this will be to use parallel DAQmx reads just to see if this is the main source of the error that you are seeing. Let me know if this helps.

Regards,
Kent
Applications Engineer

[TedAnderson]

Thank you for your reply.
So the time stamp t0 is generated from the Read Task rather than the Start Task command....hmmmm.

Sorry to be difficult, but this leads me to ask three questions:

1) Since I can't rely upon the timestamp, what assurance do I have that the data from multiple tasks is actually synchronized?  May I assume that the ai/StartTrigger triggers all started slave tasks within a tiny fraction of a second?  How synchronized will the first sample from each task actually be, i.e. what skew might I expect between triggered tasks and their corresponding PXI multifunction I/O cards?  (I'm working with both PXI-6225 and PXI-6255 cards)

2) If I could be assured that the inter-task skew in (1) above is sufficiently small, in my case less than 0.1 ms, I could Read Task either serially or in "parallel" and get the same answer either by either method.The input buffered data should be exactly the same, right?  I could align the timestamps on my waveforms with t0 from the master task. 

3) Since my For Loop reads are causing timestamp misalignment, what LabVIEW programming structure is best suited to reading an arbitrarily large number of tasks at "the same time"?

Best regards,

Ted

[tnek]

Hi Ted,

These are some good questions.

1. Although the t0 of the timestamp is actually software timed, all tasks begin acquisition from the time the start trigger is received. To test the hardware synchronization, you can send a known reference signal to any of the channels (try to reduce skew by using cables to the same length) and then calculate the phase shift of the actual data points. The Extract Single Tone Information function can be used to quickly get these values. This will allow you test the synchronization of the system and get the time delay by just converting the phase delay in degrees to radians and then dividing by the frequency of the reference signal.

2. The input buffered data should be very, very close and if you are comfortable with the synchronization, you can just take the t0 of the first task and assign it to each subsequent task or you can just use arrays of data rather than arrays of waveform.

3. Any structure should be fine as long as the limitations are understood. If you would like to continue using your serial architecture, you may also want to check out this example to get some more ideas of how parallel reads can be accomplished your application.

Regards,
Kent
Applications Engineer

[TedAnderson]

Kent,

Excellent advice.  If I can round up the necessary hardware to inject the same external signal into multiple PXI cards, I can eliminate my concerns once and for all.

To answer an earlier question of yours:  Even when running the multiple Read Tasks in parallel, I still occasionally see waveforms originating from different PXI cards out of synch by a consistent 16 ms.  Perhaps there is a Windows process that is getting in the middle of things.  But as long as the triggering works as expected, this shouldn't be an issue.

Thanks for the link to DAQmx Multi-Device Streaming. It shows some sophisticated ways to speed up throughput.

It looks like this thread is drawing to an end, thanks to your input.

Regards,
Ted