DAQ channel "jump"

[Jacc]

We are having a problem with sudden channel "jump" on a PCI-MIO-16 XE50 with
one AMUX-64 card.
It's as though the scan order was suddenly scrambled or shifted: values expected
for channel 3 may appear on channel 9, etc. The jump seems as stable as proper
operation: that
is, the system will run fine for 1 to 20 hours and then jump and hold the
new "scan order".
We have tried to make sure that there are no voltages above 10V on any channel,
as the knowledge
base indicates that this could be a cause for the symptom. The system previously
worked fine for
about a year; then the thruster was changed and our problems began.

The usual suspects of grounding and over-voltage are still on our short-list,
but I would be
greatfull if anyone can add to our list of suspects or offer troubleshooting
insights. There was
a discussion a year or two ago on this topic in the LabView mailing list,
but I have been unable
to locate it.

The System:

Power Mac 9600/300, OS-8.1, NI-DAQ 4.9.2., LabView 5.1 PCI-MIO-16 XE50 with
one AMUX-64 card
(Referencedsingle ended), PC-DIO-96, PCI-GPIB card. System controls a 100V
(4KW) power supply
that provides power to a power supply that operates an ion thruster. The
thruster power supply
is operated by a digital line connected to the PCI-DIO card. 23 lines are
sensed, 19 of which
monitor voltages and currents from the thruster power supply. The 19 lines
each pass thru an
opto-isolator pair and optical cable before being connected to the AMUX.
The voltages range
from mV to 1500V, but the sensors (voltage dividers and shunts) are designed
to operate
between 0 and 10V. The 4 other lines are are from commercial sensors that
measure flow,
pressure and temperature. All unused inputs on the AMUX card are grounded.
The LabView program
calls the Single Scan DAQ vi at 40Hz and the array from this vi shows the
incorrect data.

What we have tried:

We have changed both the DAQ card and the AMUX card without success. If we
disable all inputs
by turning power off to the opto-isolators and then turn them back on, the
problem persists.
If we switch off the AMUX card and turn it back on, the scan order resets
to what it should be.

[kmoermond]

"Jac Colby" wrote:
>>We are having a problem with sudden channel "jump" on a PCI-MIO-16 XE50
with>one AMUX-64 card. >It's as though the scan order was suddenly scrambled
or shifted: values expected>for channel 3 may appear on channel 9, etc. The
jump seems as stable as proper>operation: that>is, the system will run fine
for 1 to 20 hours and then jump and hold the>new "scan order".>We have tried
to make sure that there are no voltages above 10V on any channel,>as the
knowledge >base indicates that this could be a cause for the symptom. The
system previously>worked fine for >about a year; then the thruster was changed
and our problems began. >>The usual suspects of grounding and over-voltage
are still on our short-list,>but I would be >greatfull if anyone can add
to our list of suspects or offer troubleshooting>insights. There was>a discussion
a year or two ago on this topic in the LabView mailing list,>but I have been
unable>to locate it.>>The System:>>Power Mac 9600/300, OS-8.1, NI-DAQ 4.9.2.,
LabView 5.1 PCI-MIO-16 XE50 with>one AMUX-64 card >(Referencedsingle ended),
PC-DIO-96, PCI-GPIB card. System controls a 100V>(4KW) power supply >that
provides power to a power supply that operates an ion thruster. The>thruster
power supply >is operated by a digital line connected to the PCI-DIO card.
23 lines are>sensed, 19 of which >monitor voltages and currents from the
thruster power supply. The 19 lines>each pass thru an >opto-isolator pair
and optical cable before being connected to the AMUX.>The voltages range
>from mV to 1500V, but the sensors (voltage dividers and shunts) are designed>to
operate >between 0 and 10V. The 4 other lines are are from commercial sensors
that>measure flow, >pressure and temperature. All unused inputs on the AMUX
card are grounded.>The LabView program>calls the Single Scan DAQ vi at 40Hz
and the array from this vi shows the>incorrect data.>>What we have tried:>>We
have changed both the DAQ card and the AMUX card without success. If we>disable
all inputs>by turning power off to the opto-isolators and then turn them
back on, the>problem persists.>If we switch off the AMUX card and turn it
back on, the scan order resets>to what it should be.>>>

Maybe similar to a problem I just had using a DSA board. The channels would
randomly go out of order. Per NI Support, this was a problem with doing
slow scans on a fast computer and fixed in NI-DAQ 6.5.2. A document containing
the information will appear if you search on the Knowledge Base at NI Support
for "DSA and channel." The ID number for the document containing this
info is 1GAHJA0O . The fix may have only been applicable to DSA boards
but its worth a look.

[Jeremy]

The AMUX-64 contains a counter that is clocked by the "SCANCLK" PFI output of the DAQ board. I think that noise is getting on that line and advancing the clock by some count, which offsets your channels by that count. Since you are calling Single Scan and not doing a continuous acquisition, I would recommend running Board Reset either occasionally or, if possible, every acquisition. I'm not certain, but I bet that this would reset the counter to its initial value. One way to test this for certain is to call the reset function next time you get this error. Good Luck!