Hi all. I have been searching forums, reading NI documentation, and generally beating my head against the wall so I've got to ask.
Hardware and Software:
Labview 2014 and associated add-ons
NI-9205 Analog input module
The 9205 is a 32-channel analog input module that is pretty ubiquitous. We got one in our hands and are very disappointed to find out that it doesn't have any pull-down or pull-up resistors and that the ADC is fed through a mux that samples all 32 channels. It is probably well known at this point that these modules have problems with 'ghosting' between channels as described in the first link below. This ghosting means that, for instance, if you sample channel 0 with a 5 volt signal, then sample channel 1 that is left unconnected, you will see roughly 5 volts on channel 1 because the sampling cap is charged to the voltage of the last connected channel. Why NI chose not to provide pull-downs or open-circuit detection is beyond me and not the scope of this question.
Description of the ghosting problem and recommended solutions, all of which are cheesy and impractical hacks in my opinion: Ghosting Description from NI
Hardware setup of 9205 module, stolen from the NI link above:
I decided that perhaps I could create a poor man's pull-down by sampling a grounded input channel before sampling a channel with a real signal on it. I found this article from NI that discusses using an FPGA IO Sample method for low-level control of the registers (or whatever) that control the configuration of voltage range, terminal configuration, and channel order that is used by the 9205 at runtime. Getting very excited, I put together an FPGA VI that is intended to sample channel 31, which is connected to ground, between every other channel on the module, thus draining the sampling capacitor and giving me a clear indication that a particular channel has become disconnected. So the sampling should go AI0, AI31, AI1, AI31, AI2, AI31, etc. We don't need to sample at any higher than 50 Hz so I don't care that I'm cutting the effective sample rate in half, but our application does require us to know if a channel has become open because of a broken wire or something.
The bad news is that despite creating an array of configuration values that samples channels in the order described above, it appears that the 9205 is still sampling in numerical channel order. My test setup is as follows:
AI0 - 5 volts
AI1 - open
AI31 - ground
If I sampled in numerical order I would expect to see 5 volts on channel 0 and something close to that on channel 1, which is what I actually observe. When I sample in the order AI0, AI31, AI1, I expect to see 5 volts, 0 volts, and 0 volts, but that's not what I observe. Instead I see 5 volts, 0 volts, 2.4 volts. I've messed with extending the time between calls to the IO Sample method, thinking that it might leave the mux connected to ground longer and thus drain the cap further (I'm not sure if this is a valid assumption), but this doesn't change the value measured for channel 1 at all.
Here's a screenshot of the FPGA code:
Here's the real-time code:
Here's the results on the front panel:
Looking at the results, it's clearly returning the data from channel 31 in between channels 0 and 1, but channel 1 does not look like the cap has been drained. Am I really controlling the order in which the channels are mux'ed to the ADC, or am I just controlling the order in which the data is returned to me? In other words, does the mux always go from channel 0 to 31 in order, no matter what I request? If so, why does the article linked above explicitly tell me that I can control numerical order?
If channel 1 is sampled immediately after channel 0, why does it show such a voltage drop from the 5 volts on channel 0? If the channel is open, where is the charge in the cap draining to?
Are there any NI analog input modules (or discrete input for that matter) that provide pull-down or pull-up resistors? I'm catching major flak for picking acquisition hardware that doesn't have these seemingly basic features and that's my fault, although to be perfectly honest, most decent acquisition hardware does normally include these features.
Thanks for your help,
Confused in the Desert
I believe you are correct in that the MUX always go from channel 0 to 31 in order. I am curious to know how much ghosting is happening in your actual application, and what the details of your physical set up. If you are seeing unexpected measurements your signals I would recommend double checking that you have the proper grounding in your system. Please see the Field Wiring Guide for more detailed information regarding grounding.
Something worth mentioning is that we do not recommend reading open channels as that is not the intended use of the device therefore resulting in possible unexpected readings.