01-16-2009 03:38 PM
Hi Earl,
What version of DAQmx are you using? The latest version is DAQmx 8.8. Please update to this version if you have not already. Also, what happens if you connect the voltge and a thermocouple to the same module? In Measurement and Automation Explorer, if you right click on the chassis and go to "Properties," there is a Cable tab. What is your configuration for Digitization Mode? Thank you!
01-16-2009 04:35 PM
Actually the first system where this problem manifested itself had 8.8f2 and I got the issue resolved(by using a different SCXI chassis) in our client's test cell.
This particular system that I have been working on to resolve has 8.5.0f2 installed and is my development machine.
To answer your question it is problematic even in the current DAQmz version.
Earl
01-19-2009 01:47 PM
Hello Earl,
It seems as though the chassis may be the problem since you seem to have switched everything else out. Please try reading the CJC channel directly and see if you get an accurate reading (the channel is referred to as _cjTemp). Please check and see if the reading on the CJC changes when you add more channels to the scanlist (vs just reading a single channel). If this is the case, there may be something wrong with the chassis multiplexer control.
In the one channel case, no multiplexing is necessary on the chassis end, since everything always points to that channel. Once you add more channels, the chassis starts to control the timing signals. Note that on a temperature task, when you use "built in," you actually add another channel to the list--the CJC channel. When you use constant, no extra channels are added and the measurements are just scaled by that constant value.
If the test described above fails, then the chassis may need to be sent to NI for repair.
Thanks,
01-20-2009 10:44 AM
Hi Margaret,
I suspected that the multiplexer was indeed bad.
Results...
http://i34.photobucket.com/albums/d150/angrypistols/SCXI%20Issue/2VoltageChannelsOnSameModule.jpg
I don't know if we caused the problem when we were troubleshooting the problem in the test cell or they were bad to begin with.
The funny thing of it is that I have 2 other SCXI-1000's that exhibit the same behavior. Can we ship all this hardware to have it checked/ and or repaired by NI?
Thanks,
Earl
01-21-2009 02:14 PM
Hello Earl,
It is very suspicious that you have more than once chassis with the same problem. Please check that the chassis address in MAX matches the address set on the chassis. Also, please check that the chassis daisy chain index is set to 0. If the daisy chain index was set to something other than 0, the chassis would still listen but maybe wouldn't do the MUXing since it thinks the commands are being sent to a different chassis at index 0. Please let me know the results of this test. Also, when did you purchase the chassis? We can discuss the hardware being sent back to NI, but let's make sure that we have thoroughly troubleshooted first.
01-22-2009 03:36 PM
The address is set to 0.
Earl
01-23-2009 12:16 PM
Hello Earl,
I want to check with you that by "address" you are referring to the daisy chain index. Please see the screen shot attached for certainty. If this is set correctly, than it seems that our only option is to bring the chassis back to NI for testing and potential repair. To do this, you will need to call in to NI at 866-ASK-MYNI and make a service request to RMA. You can relay to the engineer that you speak to that we have done extensive testing over the forum and that this is the conclusion that we have arrived at. Have a good weekend!
04-22-2009 03:51 PM
Howdy,
For posterity's sake, I want to mention that we ended up tracing the problem to one of Earl's SCXI-1125 modules--particularly, one of the multiplexers on a particular 1125. When inputs were connected to this particular 1125, those inputs read fine but only if this 1125 was used as the communicating SCXI module. If a different 1125 module was selected as the communicating module (in a chassis with more than one 1125 modules), then you would read incorrect values. Also, if you tried to read in signals from another SCXI module with the problematic 1125 acting as the communicating module, then you would read incorrect values. Repairing/replacing this problematic 1125 resolved the issue.