How to synchronise PXI 4472 and PXI 6733

[schi]

Hello,

I have an application where I need to synchronise the input by two PXI 4472 and the output by two PXI 6733.

I had it running with RT 7.1 and NI-DAQ (traditional) and I managed to port to RT 7.1.1 and NI-DAQmx 7.x. The PXI system was made of a 8176 controller and an 1000B mainframe.

Now I am porting the system to RT 8, NI-DAQmx 8, still using an 8176 controller but a 1042Q mainframe. I do not get the IO running, it seems as if there are some timing issues or clock/triggering signals not routed correctly or so.

As the 4472 is a DSA card and the 6733 is an AO card, the examples are not directly applicable.

Any hint on what changed or might be the cause? Any example vi for such an IO combination available?

Thanks in advance,

schi

[Nick_CH]

Hello Schi,

I suggest you to have a look at the two following documents.

How Do I Use LabVIEW to Synchronize Multiple NI 4472s in Traditional DAQ?
Synchronization with Dynamic Signal Acquisition (DSA) Products with DAQmx

Best regards,
Nick_CH

[schi]

Hello Nick_CH and everybody else who might have a hint for me,

my problem really seems to be quite hard and although we tried to find a solution, we did not find any (despite of all the information, examples, etc. that can be found on the NI web site, documentation, etc.)

So, what do I want to do? I want to use 2 PXI 4472 cards to input data and in parallel 2 PXI 6733 to output data. My target sample rate is about 1 kHz for the output, so it is not really high, but I do not get anything working for much lower rates currently. Yes, that sounds like a control application, yes, I know that the 4472 are not really tailored for this task. They are in another respect: They include signal conditioning, and someone once decided to take them - I have to use them now.

The software environment I am using is LV-RT 8.0 and NI-DAQmx 8.0, the controller is an PXI 8176 (but I do not think the computational load is the issue here...).

Since NI-DAQmx 8.0, it is possible (and really works!) to combine 2 PXI 4472 in one task. This simplifies the overall task and so I would like to use this feature.

As is often discussed and common knowledge, the sigma-delta-converter within the 4472 cause a long delay to the signal, which is fixed in samples to the 4472 sample rate. As there is an interesting example vi which shows how to synchronise mulitrate inputs from DSA and MIO (see http://sine.ni.com/apps/utf8/niepd_web_display.display_epd4?p_guid=E7893A91C20B0BCAE034080020E74861), I would like to run the input channels at a higher sample rate than the outputs and do some internal downsampling. Therefore, I would like to use 2 sample rates, one input sample rate (4472, DSA) and one output sample rate (6733, AO). The downsampling itself is not the important issue currently (let's assume a pure decimation for example).

Setting up the system as in the mentioned example does NOT work for me. What worked to a certain degree is an approach shown in the attached vi Synchronised 2 rates.

The Read-property WaitMode does not make any difference, neither does the Real-Time property WaitForNextSampleClkWaitMode. Both nodes can be deleted.

Connecting the 6733 sample clocks to the ai/SampleClock of the 4472 task works - the approach described in the mentioned example does not work. If you take out the Wait For Next Sample Clock vi from the while loop, everything works, but the cycle time shows an extreme jitter, resulting in an extreme jitter at the output. This is not a problem of the high sample rates (1 kHz and 10 kHz), it also occures at much lower sample rates.

Applying the Real-Time Property Report Missed Samples does not work for the continuous sampling DSA device 4472, it is not applicable.

Using the Wait for Next Sample Clock vi reduces the jitter as the minimum time for the while loop is about the expected cycle time, but the jitter towards longer times is still coming up and so the loop stops virtually immediately after the grace period of Wait for Next Sample Clock. This also occures for very low sampling rates (e.g. 1 kHz for the input and 50 Hz for the output). This is the current state of the vi as attached.

So, an alternative idea was to use a timed loop and the Create Timing Source (Signal from task) vi to generate the timing source for the loop. As the signal to use for this, I selected the Sample Clock.

First, I tried to use the DAQmx-Task for the second 6733 as its sample clock has the right frequency. But I got error -200452 - not applicable.

 So I decided to take the 4472 - task and use the decimation rate as additional tick count for the loop. But even there: error -200452, although the ai/SampleClock signal can be successfully routed to the 6733 modules.

This is the state for the second attached vi, Synchronised 2 rates timed loop.

I would appreciate any help on how to overcome this problem, whether by reducing the jitter in the non-timed loop or by generating a suitable timing signal for the timed loop.

Best regards,

schi

[reddog]

If I understand correctly, you want to acquire data at some rate N on the 4472 devices and another rate M on the 6733 devices where M < N.  You also want the two clocks to be syncrhonized throughout time.  It also sounds like you're taking the input from the 4472's, performing some processing on the data, and then feeding the processed data back to the 6733's for output.  What's not as clear, is how close in time you want the two operations to start or what the desired phase lag is between the input and output.  Depending on the answer to the phase lag question, I see two avenues that might work.

First, you can try the approach listed in the example link you posted that shows how to synchronize the boards at different rates but trigger the 6733 slightly after the 4472.  Using this approach, you can read the first set of data from the 4472, process it, write it to the 6733 buffer, start the 6733, and then send the start trigger to the 6733.  Subsequent interations of the loop would simply read data from the 4472, process it, write it to the 6733.  For this to work, you will need to disallow regeneration of data on the 6733's.  Also, I would probably try to setup up a counter on the 6733 to perform a triggered single pulse generation.  The source of the start trigger for the counter would be the ai/StartTrigger from the 4472.  The generated pulse from the counter would then act as the start trigger for 6733's.  By modifying the initial delay of the pulse generation, you can control how much time elapses from the start of the AI task to the start of the AO tasks.  The trick is you have to be able to read the first set of data from the 4472, process it, write it to the 6733 output buffer, and start the AO task before the counter pulse acting as your AO trigger occurs (with software determinism).  However, you're using RT so it seems like this should be possible.

Second, if you want to continue with the Timed Loop approach, you can't use the ao/SampleClock or ai/SampleClock for the 4472 as a timing source (as you've already discovered).  However, you can use a counter on the 6733 as a timing source.  This would give you more of a single point control loop approach as opposed to the offset waveform approach I described above.  For this, I would use a counter to generate a continuous pulse train and configure the timebase of the counter to be the ai/SampleClockTimebase from the 4472.  The ai/SampleClockTimebase will have to be routed across the Star Trigger line.  You can then divide down this timebase to yield a pulse train of the appropriate frequency for use as a clock to the timed loop.  To do this, use the Signal From Task version of the Create Timing Source VI and select the Counter Output Event as the signal input to the VI.

Hopefully, one of these two techniques will be useful to you.  Post back if you have any other questions or difficulties.  Good luck!