NI USB-6218 - DAQ Assistant Scan Order Affects AI Signal

[lpm4ni]

I have encountered a very odd problem with my DAQ program, and am wondering if anyone has insight as to what might be going on. I tried to look in the forums but couldn't find anything similar to what I am experiencing. In short, it seem as though the order in which my signals are scanned in DAQ Assistant affects the signal that appears on that AI channel, even with the same input signal. By the way, I know I should be using DAQmx but I would like to know why this problem happens in DAQ Assistant in the first place. 

Program Summary (please refer to attached JPG):

-DAQ Assistant scans a list of 57 channels, some AI channels are repeatedly scanned (this is not an issue, I've had this working properly for months)

-Flow Trigger is a simple trigger signal, that ranges from 0-5V every 10ms or so (this ai channel, and the input, have been independently tested and it's verified that the input is always the same and that ai16 is functioning properly)

-All signals have a voltage range of -10V to +10V, so I don't believe it is a problem of the DAQ having to switch input voltage ranges between channel tasks

-Aggregate sampling rate must be less than 250kS/s, and at 4.25kS/s over 57 scans, I am under by a reasonable margin (~242kS/s)

-Other signals seem to be acquiring correctly when this happens

If I leave Flow Trigger where it is (order 15), I get some non-descript signal that looks nothing like the trigger I expect when I run the VI; it is noisy and peaks twice before drifting to some random voltage. If I put Flow Trigger first (order 0), the signal comes in fine. This has been true over a number of repeated trials.

Does anyone know what this could be? I know the DAQ hardware is operational, and I also know that my input is consistently the signal I expect (0-5V digital, 10ms cycle). I am stumped and don't believe I've broken any of the recommended implementation rules in the user guide. Any insight would be appreciated!

Cheers!

[Richard2950]

Could it be a ground referencing issue? Have you checked to make sure that the RSE, NRSE, differential settings are all correct and that all signals are wired with the appropriate ground reference?

[lpm4ni]

Hi Richard,

Thank you kindly for the reply. I do not believe it is a referencing issue, nor a channel setting. My DAQ Assistant (and all channels in the scan order) have the exact same settings in both Scenario A and Scenario B.

Scenario A: Flow Trigger is acquired 16th in the list - incorrect signal acquired

Scenario B: Flow Trigger is acquired 1st in the list - correct signal acquired

In both cases it is an RSE signal, -10V to +10V range, and the sampling rate for the entire DAQ block remain the same. If it was a referencing issue, I would not get the proper signal in either of Scenarios A or B. Literally, the only thing changing is the order in which that one signal is acquired!

Response is much appreciated, please let me know if you have other ideas!

[Richard2950]

The reason that I suspected a ground referencing issue is that the troublesome channel is channel 16, the first one in the upper half. That is, I think, paired with channel 0 when set for differential input. I thought that perhaps channel 16 got read single-ended when it was first in the scan, but the configuration got changed to differential for one of the other channels, resulting on a bad reading when channel 16 was scanned later in the sequence. Can you change physical channels to one that is less than 16 to see if the same behavior occurs?

[lpm4ni]

Hi Richard,

Interesting, I now see your point more clearly. AI16 is paired with AI24 when sensed differentially, however in my my DAQ Assistant both AI16 and AI24 are RSE channels, and both are sensed with respect to AIGND. I do have differential signals scanned multiple times in my DAQ Assistant, but they are paired accordingly and there is no repeated channel assignment where it is Differential and then RSE. AI16 is not used in a differential pair in my DAQ setup.

I might be missing the point, but I'm not sure I see what changing the physical channel will do. It is only scanned once per cycle, and it works when it's scanned 1st, but not when it's scanned 16th, same physical channel assignment. The scan order should not have any impact on the channel behaviour, if the ranges and type of scanning are the same, unless I'm mistaken.

EDIT: I missed a point in your message. The pattern in my DAQ Assistant has a channel read RSE, then two Differential, then the same pattern is repeated with different RSE channels but the same Differential channels. I think this is clear from the JPG. So I can't imagine it is an issue of it switching from RSE to Differential, and as I said above, AI16 is only scanned once in the cycle.  

[JtotheB]

Hey lpm4ni,

It sounds like you might be running into ghosting. If your flow meter is a high impedance source, it makes sense that you would get a cleaner signal by moving it to the front of the scan list. Here are two articles about troubleshooting ghosting and some other signal problems (in case ghosting is not the cause);

How Do I Eliminate Ghosting From My Measurements?

Troubleshooting Unexpected Voltages, Floating, or Crosstalk on Analog Input Channels

Have a great day!

[lpm4ni]

Hi JohnB,

Many thanks for the links and the reply. I thought it could have been ghosting but if you refer back to my VI JPG, prior to every RSE channel, I scan the same two differential channels in the same order. Further to that, what I see when it is scanned 16th has no resemblence to the signal scanned prior to it, which is another reason I didn't think it could be ghosting. I also tried to drop the sampling rate to see if it was an issue of settling time between scans.

What I didn't think about is whether the impedance of my Flow Trigger signal differs greatly from the rest of my RSE signals. From your experience, if this channel was scanned somewhere other than 1st and 16th, I would probably see the same effects if it was ghosting, right?

Cheers!

[JtotheB]

Hey lpm4ni,

You would see ghosting minimized if your high impedance sources are earlier in the scan list.