Buffer channel required in NI-6259 ADC?

[Pete_Culmer]

Hi,

I'm getting some odd problems with analogue input using a NI-6259 card in a Labview RT application.
I am reading in channels AI0:A:5 and AI:16:AI27 in a single task at 500 Hz (hardware-timed single-point acquisition as this is a control application, configuration is RSE and -10,10V input).

The software works fine, and all analogue inputs are read without error. However, the AI16 channel is incorrect (as compared to a volt-meter or oscilliscope) and seems coupled with the channel preceding it, AI5. If the voltage input to AI5 is varied then AI16 also varies. However, there are definitely no crossed connections in wiring, it seems to be an issue with the ADC on the card itself.

We have tried adding a buffer channel (reading AI15 before AI16). This seems to intermittantly solve the problem, pointing towards maybe a certain settling time needed? However, this is unreliable and we need a solution that works 100% of the time!!

Any suggestions much appreciated, totally baffled here,

Cheers,

Pete Culmer

[RobSims]

Hi there Pete,

Thanks for posting on the NI forums.

There are a few things that may be experiemented with to eliminate/reduce this kind of noise. I noted you are using an RSE terminal configuration. If the signal source is grounded then it is possible to induce a ground loop current between your device and the signal source. This can introduce error in your measurements.

http://zone.ni.com/devzone/conceptd.nsf/webmain/177A8B29FEDC0F5886256FA90083C0F8

There has also been a forum thread (link below) on a similar issue, albeit for an E-Series device. The thread documents some steps to try, one of which I would suggest looking into would be increasing the interchannel delay (Convert clock) setting. This will allow the ADC and ASIC more time to settle, but also allow any external capacitances to discharge slightly.

http://forums.ni.com/ni/board/message?board.id=250&message.id=2663&requireLogin=False

I am surprised you are seeing inter-channel crosstalk with your DAQ device at the given sampling rate as the device can sample at rates much greater than this. I would suggest taking a look at the ground loop link noted above to see if this may have an implact on your issue.

I hope this helps. Let me know how you get along. Thanks,

Rob

[RobSims]

Hi again,

Further to the above, please take a look at the below link. It contains a decription of the convert clock property, and a snippet of example code.

http://digital.ni.com/public.nsf/websearch/23AC65052AE183658625705B0067D5E6?OpenDocument

Thanks,

Rob

[Pete_Culmer]

Hi Rob,

Thanks for the advice, much appreciated.
Since I posted we've had some success. I ran across a post recommending grounding all non-used channels. This seems to prevent the cross-talk although we can't be certain yet that it isn't happening on a small scale. I'll have a look at implementing the convert clock method and post back.
The more accuracy/reliability the better!

Cheers,
Pete