Problem with NI USB-6259

[mseb]

Hello,

I'd like to perform simultaneous AI and AO using a NI USB-6259 device. I'v read many things about synchronizing and triggering AI and AO and this leads me to the simple attached vi, heavily based on the "Multi-Function-Synch AI-AO.vi" example given with LabVIEW 8.2.1. When you run this vi, the graph should display identical signals (when AO0 is physically connected to AI0:2), however, the first analog channel seems to be consistently off by one sample and this is not what I expect. May someone confirm this behavior ? How can I avoid it ? Am I missing something obvious ?

Thank you.

PS : I'm using 8.7 DAQmx drivers, might this be related to this thread ?

[mseb]

I don't have much success with this one

One hint maybe : this off by one problem occurs on the first channel only ! If I read four channels instead of three, the first one being a shunt. I've no problem. Is this a hardware bug ?

[Mcdan]

mseb,

I think that what you are seeing is correct behavior, though perhaps not the behavior you'd expect.  Let me explain. You are sharing a sample clock between your AI and AO tasks.  When this clock occurs, two things happen.  One, your analog output begins to update it's value to the next value you have written (keep in mind there is a short amount of time between the sample clock, and when your AO channel drives it output to the desired value).  Two, at the same time, you begin reading your AI channels.  Remember that the device you are using is a multiplexed device, so your channels are scanned one at a time(0 then 1 then 2).  I suspect that when AI 0 is scanned, your AO channel has not yet finished updating, so your first AI channel reads the old AO value.  By the time you scan the remainder of the channels in your scan list, the AO update has completed, and those channels read the new AO value.

The good news is you can programatically control the delay between when your sample clock occurs, and when you would like your AI scans to begin to happen.    To do this, you set the timing->More->AI Convert->Delay From Sample Clock property.  This will allow you to delay AI scanning relative to the sample clock in order to allow the AO update to complete before you scan.

Hope this helps,

Dan

[mseb]

Thank you very much, McDan you nailed it ! Indeed, if I adjust the "Delay From Sample Clock" property, I will change the apparent delay. Though, I can never reach as "good" a value as that read on the next channel. In the case of four channels sampled at 250KS/s, I can use a value of 19 as a maximum before being warned (what is the validity of this warning in my case ? ). I can use a maximum value of 39 before getting an error. This is I presume related to how many convertclock one can count before needing to take another sample. But why, oh why does this AO setling time delay does not appear on the other channels ? This should mean that intechannel delay is larger than those 40 convertclock ticks ?

Experimenting a little, I found that I get a similar (negligible) delay between first channel and the others while waiting 62 tops of a 869565 Hz convertclock. This means, if I get it well, that the AO settling time is around 70 us on this AO on this device, does it ? Why doesn't this fit with the 2 us that is specified in the doc, then ?

I'm really curious to understand more about this. Reading the relevant section in the M series operating manual introduced me to the convertclock use already, but I still don't get how this delay might be as large as it is, it really seemed an off by one point error, which I expect not having been the only one to notice.

The bonus question is then : how to perform synchronized AI and AO taking this settling rate into acount ? Is there any kind of pre-trig hack for AO I could use ?

[Mcdan]

mseb,

The amount of delay you can set depends on several things including your sample clock rate and your convert clock rate.  Essentially between each sample clock, you want to ensure that there is time for the delay you specify, as well as time to issue a convert clock for each channel in your scan list before then next sample clock arrives.  If I remember correctly, the driver will not run the convert clock at it's max rate all of the time, but will add in some padding to allow more inter-channel settling time.  You should be able to set/query this property to get an in-depth view of the timing of your scan.  This is accessible through the Timing->AI Convert->Rate property.  I suspect the warning you were seeing may be due to the fact that the initial delay you chose may have caused the convert clock to run faster than it should to complete the scan within one scan period.  However without specific information on what that warning is, all I can do is guess.

To answer your question of why you may see this delay on one channel and not the other I still feel is due to the additional amount of time that passes between the sample clock and later channels in your scan list.  Consider scan below:

                                      _                                                                            _

Sample Clock:_______| |______________________________________| |___________________________________

                                     SC1<-ConvDelay->                                           SC2 <-ConvDelay->

                                                                       _       _      _      _                                                     _       _      _      _

ConvertClock:________________________| |___| |___| |___| |__________________________| |___| |___| |___| |_____

                                                                      c0     c1    c2    c3                                                  c0     c1     c2    c3

                                                                             |       |        |     

                                                                           convert period

The first channel you scan will have a total delay of ConvDelay from the sample clock you are sharing with AO.  This is the shortest delay from your AO update of any of the channels you are scanning.  The second channel will have a delay of (ConvDelay + convert period).  Each addition channel will delay by an additional conver period from the channel previous to it... (ie Channel 3 has a delay of ConvDelay + (3*convert period).

(Ctd)

[Mcdan]

When you are programming convert delay, you should also specify units for delay... I assume that you chose ticks, which should be ticks of a timebase which the device uses to create your clocks.  In the case of the VI you posted, this would be a 20 MHz timebase.  By specifying a delay of 19, you are programming the convert clock to begin 19 ticks of a 20 MHz clock after the sample clock occurs.  This works out to be a delay of .95 uS.  This may not be enough time for your AO channel to complete it's update.  To remedy this, you could speed up the convert clock (reducing convert period), and then lengthen the convert delay.  This would force your converts to be closer together, later in your sample period, but could add additional delay before reading your first channel, ie:

Sample Clock:_______| |______________________________________| |___________________________________

                                     SC1<-ConvDelay->                                           SC2 <-ConvDelay->

                                                                                             _   _   _   _                                                   _  _   _  _

ConvertClock:___________________________________| |_| |_| |_| |__________________________| |_| |_| |_| |_____

                                                                                            c0 c1 c2 c3                                                 c0 c1 c2 c3

I'm not sure if I've provided you the answer to your question or not, but this seems like timing information that is important for you to understand to get the results that you are looking for.  Please let me know if I haven't been clear, or if this does not answer your question.

Hope it helps,

Dan

PS... it appears that my formatting got off a bit in my clock diagrams... sorry about that.

Message Edited by Mcdan on 02-26-2008 02:54 PM

[mseb]

Well, you definitely get it right ! Your clock diagrams really look like those in the "M series manual", I really admire both your analysis and your ASCII art capacities
You were indeed right, I was using ticks as units for delay, and the convertclock is the 20 MHz onboard clock. I think I get it all now, thanks to your eplanations and my experimentations and as you mean it, I guess I could play with convertclock frequency and delay and find the "fitting" parameters set, I'm however afraid that this will be rather a mess to compute it for any number of channels at any sample rate (anybody ?) and I'm not willing to pay this additional complexity. I'll chose to read an uneeded AI first and ignore it. Since AO settling time is specified to 2 us and the max sampling frequency is of 250 KS/s with four channels, the second channel I read will be well timed with respect to AO. Of course, I'm loosing a few KS/s but I still sample fast enough for my application.
Maybe this situation should, however be dealt with by NI : when you use the same clock of AI and AO, obviously synchronizing them, the optimal convert delay could be computed including AO ? I've found this situation really didactic but rather annoying, I can't think I'm the only one who ever got it.
Anyways, thank you very much McDan for your time.

[stilly32]

You could always statically write the first sample on an AO channel before you trigger the AI and AO together - that way the value is already at the point you want before the update and the convert rates/delays won't be apparent. Maybe not the most elegant solution but a sledgehammer works too 🙂

cheers,

Andrew S

[mseb]

NO !

Definitely, there is something weird here. I'm short on time to dig deeper and I'll be back on this later, but there is something here. I was playing with the convert clock delay property today and I really get strange things :  for some values, when using one AO wired three input channels (the first one of my four channels being short circuited), 250 KS/s per channel, I may values on one channel higher than AO output range !
This seems to me like a real bug. Do anybody know what to do in this case ? I'll provide more information later today or on monday, but I'm really interrested in getting an "official" opinion. It should not be that hard to get synchronous AI and AO using this kind of hardware after all, should it ?

[Mcdan]

Hey mseb,

I think you're going to need to provide some additional information before we can tell what is going on with your setup.  I'd like to know which signals are wired to which terminals.  Are there particular AO values you are writing that produce bad results?  Are the bad results tied to any particular analog input channel?  Do you get the same result every time you see a bad result?

Finally, it is possible to read your Analog Output channels via internal channels rather than through external connections.  This can help us eliminate external connections as a source of errors.  Essentially you can set up your physical channels to look like this: Dev1/ai0,Dev1/_ao0_vs_aognd,Dev1/_ao0_vs_aognd,Dev1/_ao0_vs_aognd.  This sets up a scan of four channels (I've left Dev1/AI in the list in case you want to ground it as a dummy channel, if not you can remove it from the list).  The device will scan through the external channel, then preform three subsequent reads of the AO channel through internal circuitry.  I would be curious to see if you see the same behavior in this configuration as you are when reading externally connected signals.

Hopefully the answers to these questions can shed some light on what you're seeing.

Dan