triggering issue between PXI DIO and AO/AI

[Francois Esnault]

Hi,

I have a PXI DIO (PXIe 6535) that I use to generate a pattern and this pattern is repeated continuously thanks to the regeneration mode. Each cycle is about 100ms and the DIO is currently clock at 100kHz. All this works fine.

I have also a DAQ board (PXI-6281) in the same chassis that I use for AI and AO.

My goal is to use the DIO as a master device to trigger both AO and AI and the beginning of each cycle so that ideally the DIO pattern, AO and AI are synchronous. Currently, I use a physical signal from the DIO to trigger the AI/AO using the digital trigger port PFI0 of the 6281.

For now both AI and AO are clocked at 100 kHz using the onboard clock but I would like to have the availability to choose different clock rates.

The problem is that when I run the .vi the AO pattern and the AI window are slowly drifting away from the DIO trigger signal (drift rate = 20 microseconds per second or, equally, 2 microseconds per cycle).

Do you have any idea where does that little timing offset come from and how I can make that work properly ?

I tried for a while using a DIO-triggered retriggerable counter that was used as a secondary trigger and a shared clock for AI and AO. That mitigates the drifting behavior but it seems that the DIO trigger signal is coming a little too early (ie, while the counter is still generating pulses) so that the counter ignores it and waits for the next cycle (and next trigger signal) to generates pulses again.

Thanks for your help

Francois-Xavier

[Lewis_G]

Hi,
I have had a look at your code. I think the first step would be to try and improve what you have written so far.

LabVIEW works on the concept of data flow and a function will not run until it receives all of its inputs. You have used a lot of variables in your code which does not allow for data flow. Using lots of variables like you have is not good practice and could introduce race conditions.

You also have lots of tasks running in parallel, writing code this way means we cannot guarantee execution order. As an example, you try to clear the data from the graphs before the program starts but there is no guarantee that this code will run before the code enters the main while loop. Flat sequences are a good way for sequential programming but using the error wire is another way you can enforce execution order.

I have modified your code a little just to show there is no need for all of the variables that you have used. The left most part of your VI now has much less variables. I have also added some error wires to force data flow.

If you clean up your code, it may fix the bug you’re having. If it doesn’t, post back and we can get to the bottom of it.
Here is a video on data flow, SubVIs and parallelism in LabVIEW.
Kind Regards

[Kevin_Price]

That kind of drift is very likely due to tolerances in two boards' timebases.  Many boards have an accuracy spec of 50 parts per million, so it would be no surprise at all for two distinct boards to differ by 20 ppm.

The solution is to use a master timebase from which both boards' tasks derive their sample clocks.  (Some apps are simpler where you just share the sample clock itself, but it sounds like you need independent control of various tasks' sample rates.)

-Kevin P

[Francois Esnault]

Hi Lewis,

first of all thank you so much for your very quick response.

Could you please re-send your corrected vi in Labview 2009 SP1 format, i can  not open it ?

Cheers

FX

[Francois Esnault]

Hi Kevin,

thanks for your suggestion.

I thought that both on-board clocks were somehow automatically synchronized through the PXI chassis back bone 10 MHz reference clock.

Maybe this is not working properly or I did not set it up properly, I ll look closer.

Thanks again.

FX

[Lewis_G]

Hi FX,

I have saved for previous version in version 9.0.  I have not changed your're code much, just trying to show the concepts.

Hope this helps.

Lewis