Well, you already tried the obvious. The less obvious might include NI-DAQ driver problems. It has happened before.
On a SCXI-1126 frequency module, back in the 1998-2000 time frame, the underlying code within NIDAQ had a problem where when you picked a channel scaling that was EXACTLY within the boards ranges, such as 1k, 2k, 4k, 8k, etc., the board read back frequencies correctly. However, when you used a virtual channel to set up scaling to something like, say, 0-2200hz, the algorithm to span that wrange worked incorrectly. It evidenced itself as a drop off followed by a peak rather than a gradual ramp up in readings as the frequency increased. I eventually created a program that plotted the problem and showed it to our local
rep, who got it fixed back at NI.
The point is, the problem didn't show up in NI's production testing because they always used exact ranges in tests, while virtual channels allowed more flexibility. Somehow you need to be able to get NI to duplicate the behavior.
- You could try using other ranges in your scaling that still have your necessary ranges as a subset.
- You could try using DAQ MX if you are using traditional DAQ, or vice versa.
- You could send someone at NI your NICONFIG.DAQ file and have them try it there, with whatever version of LV and DAQ you are using.
Another thing that could have happened is that you may have a group of boards with a bad lot of chips. Check to see if all the boards you are swapping during troubleshooting have the same lot numbers on the chips. If possible, try to find at least one board that is much older or much newer when you are swapping. We resolved a 4 year problem when we finally realized 56 solid state relays on 14 different S
CXI-1321 front end modules all had the same exact thermal problems, and were all from the same manufacturer lot. Swapping with a different module 2 years older confirmed what we had been missing for years!
Tim Jones
