multifunction sychronization problems with PCI-6229

[Matt11]

Hi there, I am using PCI-6229 and LabVIEW 8.0 to take sychronized measurements of thermocouples and voltages. The diagram is attached here. Following are my questions:

1) with TC analog inputs placed very first and followed with voltage analog inputs, as shown in the diagram, it works fine. But once voltage AIs are placed first and followed with AIs for thermocouples, the reading of thermocouples does not make sense, e.g. contant 25 deg C, the program will show strong fluctuating temperature 10-80 deg C. 

2) on trigger delay using DAQmx Trigger, here I set the Start.Delay=2, Start.DelayUnits=ticks. And sampling rate=1000 Hz for Sample Clock VI. Then, is the time delay equal to 2X(1/1000 sec)=2 ms? If no delay is configured, what is the delay between actural reading and triggering signal? Will it be the device time resolution 50 ns?

Any inputs would be highly appreciated. 

[alcava.cr]

hi there, what is your DAQmx version?

[Matt11]

Hi Alejandro,

NI-DAQmx version is 8.0.0f0. Any conclusions on those two questions I have? I appreciate your time.    

[John_P1 · Accepted solution]

Hi Matt11,

1)  The order that you specify channels in your task is going to affect the scan order.  That is, when you add the voltage channel(s) before the temperature channel(s), the hardware will sample the voltage channel(s)s followed by the temperature channel(s).  Since the 6229 is multiplexed, this involves switching each channel sequentially into a single ADC.  In your case, it sounds like the voltage on the ADC from your voltage measurement has not had time to completely settle before the temperature measurement is taken.  We refer to this sometimes as ghosting in extreme cases where the measured value on channel b mimics the voltage on channel a.

I think you have already found that you can get around this by adding the TC task first.  You could also likely achieve the same result by allowing more settling time between channels in your scan list.  You can set the settling time between channels with a DAQmx Timing Property node (the actual property that you can set is the Convert Clock Rate, which is the inverse of settling time).  For slow sample rates, DAQmx sets a default convert clock rate to a minimum of 1/14 us (on the 622x).  If your aggregate sample rate is less than 1/14 us (about 71 kHz) then you should have room to lower the convert clock rate more than this if you desire to allow for more time for settling between channels.

I'm a little surprised that you're seeing errors due to this (usually the problem comes from measuring a high imepdance signal source or when sampling at higher rates), but then again the temperature measurement would be very sensitive to any small fluctuations in voltage since you are dealing with thermocouple voltages at room temperature.  Given that the scan order is affecting your measurement the problem is almost certainly introduced by not allowing enough time for the ADC to settle after reading your voltage channel.

2)  Ticks actually refers to timebase ticks rather than sample clock ticks.  The minimum is always 2, but this corresponds to 2 ticks of the 20 MHz timebase (100 ns) from which the sample clock is derived (unless you choose otherwise or specify a sample rate lower than 20 MHz / 2^32), rather than 2 ticks of the 1 kHz sample clock (2 ms).  In reality the trigger is probably occurring asynchronously to your timebase, so you have anywhere between 1-2 ticks of timebase delay (50-100 ns) depending on the relative phase of the trigger to the timebase.  If no delay is configured, the default I believe is still the 2 ticks which is the minimum that the hardware allows (you can verify on your own by reading back the property node if you want).

These points should be consistent across driver versions, with the exception that DAQmx chose the default convert rate differently in versions prior to 7.4.  Selecting the convert rate is a tradeoff between settling time allowed and how "simultaneously" the channels are sampled on the multiplexed board.  The end result in DAQmx 7.4 was a seemingly arbitrary compromise to add 10 us to the minimum convert period and use this as the default maximum time between channels.  The user of course can always set the convert clock to whatever suits their application best (in your case you might want to allow more settling between each channel). 

Best Regards,

[Matt11]

Hi John, 

Thank you very much for your detailed and excellent explanations.

For the actual settling time bweteen channels, is it determined only by aggregate sampling rate? I actually used 5 channels in total (one temperature AI, and four voltage AIs) with 1K Hz sampling rate. So the resulting aggregate sampling rate would be way lower than the default convert clock rate for the minimum setttling time (5X1K Hz=5 KHz v.s. 1/14us=71Hz; am I correct?). But in my case, it seemingly shows the settling time between channels is insufficient as you pointed out. 

Thanks again for your time.

[John_P1]

Hi Matt11,

At slow rates like you are using, DAQmx will actually choose a default minimum convert clock rate.  So, the end result would look something more like this (if you had 4 channels):

The default minimum convert clock rate for the 6229 is 1/14 us (~71.43 kHz).  At an aggregate sample rate of ~71.43 kHz and above the convert clock edges will be evenly spaced between sample clocks (and so at higher rates the convert clock rate must increase).  So, at lower rates, there is a good deal more time between the last and first sample in your scan list than the time between the rest of your channels.  At higher aggregate rates, the amount of time between all channels is equal.  These of course are just default parameters, you can increase/decrease the convert clock rate as needed with a DAQmx Timing Property Node.

The settling error between channels is a function of time, step size, and source impedance.  The 622x Specifications actually have a chart which show the relationship between the three for purely resisitve source impedances.

Best Regards,

[Matt11]

Hi John,

Thank you so much for your time and help. Now I understand those issues much better.