Peculiar multichannel analog read problem with PCI-6014 -- hardware issue

[DianeS]

Hello all,

I am seeing some very peculiar behavior with a 6014 when I do a multi-channel analog read.  I am revamping some existing code for a client, which involves switching from traditional DAQ to DAQmx.  Traditional DAQ does not use a task-based system, so my client was doing software-timed reads for a single channel at a time, depending upon which signal was of interest at the time.  (the application is a series of acceptance tests on a control PCB that interfaces with some hardware, checking responses and voltages and the like)

When I rewrote the application using DAQmx, I set up a single task containing all of the analog input channels on the board (AI0:15).  When I am interested in a particular signal, I index out that channel's data from the read array.  Channels that contain actual data are 0, 1, 3, 4, 5, 6, 7, 13, 14, and 15.  All of the channels are NRSE.   

One of the signals of interest comes in on AI7.

When I connect the signal on AI7 to an oscilloscope, I read 2.5V -- which is exactly what I expect to see.

When I read AI7 using MAX, I read 2.5V.

When I read AI7 by itself using a single-channel DAQmx read (i.e. 1Chan 1 Samp or 1Chan N Samp), I read 2.5V.

When I read AI7 simultanously with any and all channels which have a higher channel number (i.e. AI8-15), I read 2.5V.

When I read AI7 simultaneously with any channel which has a lower channel number (i.e. AI0-6), I read 2.34V.

?????

So for instance, if I read AI0:15, I read 2.34V on AI7.  If I read AI0:7, I read 2.34V.  If I read AI7:15, I read 2.5V.  If I read AI7:10, I read 2.5V.  If I read AI6:7, I read 2.34V.  And so on.  Any read channel combination which includes AI0, AI1, AI2, AI3, AI4, AI5, or AI6 results in an erroneous reading on AI7.

All of the other channels read as they are supposed to, regardless of which channels are included in the task.  AI7 is the only one that shows this behavior.

I have been writing DAQ code for 10+ years now and I have never seen anything like this before. The behavior is completely consistent.  I am quite certain that this is a hardware problem with the particular board I'm using.  It's my client's board, I have no idea when they bought it, but I think they've had it for years.  I doubt it's ever been calibrated.   

I suppose it's more that I'm curious than anything else -- what on earth would cause this behavior?

I'm going to tell my client to replace the board, so really I'm just asking for my own knowledge.

[John_P1]

Hi DianeS,

It sound like it could possibly be ghosting.  What is the impedance of your signal source?

DAQmx has a different method for choosing a default convert clock rate than Traditional DAQ (although you can set the rate to whatever you like programmatically with a DAQmx Timing Property Node).  For "slow" sample clock rates, the default convert rate is chosen to be the maximum convert rate + 10 us to allow for settling.  The 6014 has a maximum convert rate of 200 kHz (5 us period), so the default amount of time between consecutive channels in a scanlist is 15 us, provided that the sample clock rate allows for it.

For aggregate sample rates larger than 66.6667 kHz (1/15 us), the convert clock will be increased so that every channel can be scanned in between sample clock edges.

So, by default the convert clock rate will be anywhere between 5 us (1/200 kHz) and 15 us (1/200 kHz + 10 us), depending on the sample rate.  One way to verify that the behavior is indeed ghosting is to adjust the convert clock rate and see if this affects the voltage.  Steps that can be taken to correct the problem (including lowering the convert clock rate) are addressed in the KB linked above.

Best Regards,

[DianeS]

Hi John,

Thanks for taking the time to respond!  I do not know the impedance of the signal source.  I can find out easily enough.

I am sampling the channels at 20Hz, so from your response below it sounds like the convert clock rate will be about 15usec?  I have not fooled around with the convert clock rate but that sounds like it could be an interesting thing to try (I didn't know I could access it through a property node -- thanks!), just to see if anything changes when I do so.  Do you have a suggestion as to what I should set it to, or should I just experiment?

I've convinced the client to buy a more modern board, but I think it would be interesting to chase this problem down simply for my own knowledge.

Thanks again for the response, I'll post back if I find out anything interesting.

d

P.S.  Forgive my ignorance, but I assume the convert clock rate works the same way if one is acquiring a single sample for each channel using software timing?  The effect is also present if I use software timing, so I assume that it does indeed.  If not, could you clarify?

[JÞB]

In addition to John's excellent post on "Ghosting"I would point out a few considerations:

1) excessive common mode voltages can damage the AI Mux front end and increase the settle time for the PGIA by introducing a shift in the AI sense signal.  That is, essentially the mux channel input becomes unreferanced until connected through the MUX.  You may correct that the device is damaged- but take some caution! double check the sensor connected to AI7 to verify the source and sense are within +/-11V of AIGND and do not have a large common mode noise source coupled to the signal.  100Gohm can allow some pretty serious induced noise.

2) Gain increases will introduce error.  if the previous lower channel uses a 20V range and this channel uses a 5V range you have two possible solutions - decrease the sample rate or arrange the scan order by gain in decreasing range. 

[JÞB]

---

@DianeS wrote:

Hi John,

P.S.  Forgive my ignorance, but I assume the convert clock rate works the same way if one is acquiring a single sample for each channel using software timing?  The effect is also present if I use software timing, so I assume that it does indeed.  If not, could you clarify?

---

Its all in the AI MUX.  the 6014 has only 1 gain stage on the output of the AI MUX.  So its Disconect- Shift Gain - Connect- settle -convert -repeat.  Modern DAQ's capable of simultainious sampling would be a good advantage to sell your client....

[DianeS]

Hi Jeff,

Thanks for chiming in!  I really appreciate your help and insight.

My client did take common mode noise into account when designing the circuit from which my input signals come (thank goodness -- they are smart guys!).  No crazy voltages or impedances anywhere.

I have the range set identically for all channels, (-10 to +10 V) so I don't think it's a range difference.  Unless I'm misunderstanding you?

I did not get a chance to play around with the convert clock setting because another part of the test bed decided to head south (the kind of heading south traditionally associated with travelling in handbaskets) and they have to get that straightened out before I can continue with my testing.

I'll report back as I continue to learn things...

d

[JÞB]

Glad to help! (we aren't all grumpy old men).  It sounds like you've got a good grasp on the causes and cures for ghosting and ch-ch switching error on the outdated equipment your client has. 

In my experience I have had any number of headaches moving from traditional DAQ to DAQmx.  Usually caused by less than ideal documentation and sometimes caused by unanticipated features (like this) that only appear when the full power of the device is accessable through DAQmx.  Its worth the investment to update the code (and realize the improved system capabilities) but, never sell it as a "trivial" revision!  It does involve a paradigm shift- and you can thank NI for its great support team helping you understand both models.

When the rest of the system gets back from lunch I'm sure you can tackle the rest of the issues.  But, keep us informed if you learn anything interesting

[DianeS]

Hi guys,

Sorry for the long delay.  We've had other things going on, but now we are back to this.  Changing the AI Convert rate did solve the problem...sort of.

I'm finding that the AI Convert rate can be set to a maximum of ~40kHz without the ghosting problem showing up.  This limits us to a multichannel sample rate of ~2kHz (a little higher), though.  My client has thought up some new tests and we'd really like to be able to sample at a higher rate -- say, 10kHz (on all 16 AI channels) without having ghosting issues.

So.  Our next question.  John asked in a previous post to this question what the signal source impedance is.  It's about 50Kohm.  THe source is an op amp with 50mA supply current.

Does this sound like it should be causing this problem?  If so, would buffering the signal with another op amp and significantly lowering the signal impedance help us get to a higher sample rate without seeing this ghosting behavior?

Thanks for your help...looking forward to hearing from you, John and Jeff!

Diane

[JÞB]

Diane-

Thanks for coming back to this.  It sure sounds interesting.  (read as Hmmmm..)

It does sound like unexpected operation-  So I like you to try a few experiments.  First lets rule out a bad mux front end (without risking additional damage).   You've said the task is configured NSRE so you are monitoring between AI in and AI sense.  measure the input + and - to AI sense and AI GND.  This will prove or disprove the input common mode is within design limits (hey- things DO break)  If that's OK see if you can duplicate the erroneous reading on anothe AI channel.  If you can't- have the DAQ repaired!

If you can duplicate the artifact on another channel you'll need to pull the datasheet on the OP amp driving the input-  It may be slow  and responding with a "glitch" when the DAQ mux connects to the PGIA.  Having an external scope on the signal would "hide" the artifact since the scope would present a 10Mohm load and the 100Gohm AI impedence on the DAQ is essentially swamped.  A 10M load accross the AI input would solve your issue if this is the case.

Good Luck! 

[DianeS]

Thanks Jeff!

I'll be back at this particular client site on Friday, so we'll measure those voltages (CMRR) then and I will report back.

I will say that I have not been able to duplicate this issue on any other channel -- every other AI channel read matches perfectly with an oscilloscope.  Weird, huh?

This behavior also occurs identically with two different DAQ boards --  the 6014 and a 6221 -- so one suspects it's not the DAQ board ("one" being "me").

I'll post back when I have more information.  Thanks again for your help, and for tracking this thread!

(I never once suspected you of being a grumpy old man.  After all, didn't Ray say that I was the grumpiest old man he'd ever known?)  🙂