SCXI 1520 does not recognize strain channels after system power cycle

[OKors]

I have two 1520 modules in my SCXI chassis. Currently I'm collecting 12 channels of uniaxial strain measurements. All channels Cal fine but if the system is shut down and restarted I loose all cal info and all channels appear "open" when acquiring data.
The only way for the system to recognize the channels again is to recalibrate them.

This posed a huge problem because my system was power cycled in the middle of a federal compliance test. When I went to acquire another data set none of my strain channels would respond. Recalibrating in the middle of a compliance test is not an option.

I'm using the latest version of Signal Express but I dont see this as a software issue so I'm posting in hardware.  

[Thomas-B]

Hi OKors, 

Where are you performing the calibration? Are you doing this in MAX or LabVIEW? After calibrating are you saving the calibration? What do you mean by "all the channels appear 'open' when acquiring data"? Are you receiving any error when trying to detect the hardware after the power cycle?

[OKors]

Where are you performing the calibration? Are you doing this in MAX or LabVIEW?
I'm performing the calibration through the strain gage calibration wizard in Signal Express.

After calibrating are you saving the calibration?

Yes, all channels cal just fine and I click Finish to close the wizard

What do you mean by "all the channels appear 'open' when acquiring data"
Open as in 'full scale'...
If my Signal Input Range is +/-10k, all the channels will show values of 10k upon system restart. Only until I recalibrate each channel will the strain channels rezero themselves 

Are you receiving any error when trying to detect the hardware after the power cycle?
None whatsoever

[Thomas-B]

Hi OKors, 

Thanks for the information. 

A software calibration, which is what is perfromed in SignalExpress, should not be able to create useful data from railed input data. That's very interesting behavior. Before a calibration, the data you gather should be relatively the same as the data after the calibration, but with a minor offset. Is performing a calibration the only thing you have to do to get correct data? 

Also, is your PCI card in a PC, or a PXI chassis? What part of your system power cylced? What is the PC/PXI Chassis, the SCXI chassis, or both? How did it occur?

Is the same behavior occurring on both 1520 modules? 

I would like to you to perfrom a DAQ Diagnostic test on your PCI-6281. You can find the National Instruements DAQ Diagnostic Utility here.

If this behavior is occuring on both SCXI modules, it is likely an issue with your PCI card, since both modules' input will be gathered using the same input channel on the PCI card, as it multiplexes through the various channels of the 1520s. 

Let me know what you find. 

[OKors]

Sorry for the delay in reply. I was unable to do anymore troubleshooting until my last sample cycled out.
In response to your questions:

Is performing a calibration the only thing you have to do to get correct data?

So far, yes, I have not found any other way for the hardware/software to re-recognize my strain channels.

Also, is your PCI card in a PC, or a PXI chassis?
I'm running a PCI 6281 DAQ card in a PC running Win7-64 (see sig for hardware details)

What part of your system power cylced? What is the PC/PXI Chassis, the SCXI chassis, or both? How did it occur?

Just the SCXI chassis (I dont have a PXI). It was powered down with the on/off switch (I think it got bumped).
I went to acquire strain samples after the UUT had been fatigue cycling, the chassis I noticed was off so I turned it back on.
After I noticed the strain channels were 'railed' I began troubleshooting. That's when I had no choice but to re-calibrate the strains. Once recaibrated and scanning as normal I power cycled the SCXI again to see what would happen. Sure enough I lost the strain channels.

Is the same behavior occurring on both 1520 modules?

Yes, I'm acquiring 12 channels of uniaxial strains MOD 1 is fully populated, MOD 2 has the first 4 channels populated. Both Modules are affected when the system is cycled.

I would like to you to perfrom a DAQ Diagnostic test on your PCI-6281. You can find the National Instruements DAQ Diagnostic Utility here.

This may be tricky since IT has our PC's locked down pretty heavy. I have to fill out a software install request which may take a while. Either way I wont be able to run the diagnostic until all testing on these samples are complete.

If this behavior is occuring on both SCXI modules, it is likely an issue with your PCI card, since both modules' input will be gathered using the same input channel on the PCI card, as it multiplexes through the various channels of the 1520s.
When I have time I will run connect some strain channels to our other SCXI chassis and see what happens (we have two duplicate systems). I will update you with the results once I have tested our other system.

[OKors]

I did some more testing on our second SCXI/DAQ system.
In short; the same results occur when power is cycled (all strain channels hit the rail) However, I found that by changing the values for the Signal Input Range then hitting RUN it causes the system to refresh. I can then change the Input Range back to my original settings and all channels appear fine.

I can live with the change of input range as a workaround, but still... this appears to be a problem.

[Thomas-B]

Hi OKors, 

I am glad to hear that you have found an acceptable workaround for the time-being. However, whenever you do have the opportunity to try the modules in  the other system, and to run the DAQ Diagnostic Utility, let me know, and we'll continue to see what we can figure out. 

[OKors]

Just to clarify, the test I ran to duplicate the original issue was on a totally seperate machine. We have two identically configured SCXI stations, both totally seperate and standalone with thier own dedicated PC's.
The original issue took place on station 1. I then duplicated the exact issue on station 2 which is way across on the other side of the lab. 

I will still run the Diag at my next available opportunity but it seems to me since the issue is repeatable on both stations it would not be a hardware problem (or PCI card as you suspected earlier) since its not isolated to the one machine.

[OKors]

Ran the diagnostic utility. DIO ports fail at the end. Not sure what that's all about.

Results:

8/28/2013 3:16:14 PM



Results saved to:  C:\Users\Odin.Kors\Desktop\Diagnostic Results.txt



Selected Device: Analog-In



Device Type: PCI-6281



Serial Number: 1213ACE



Device Support: (PASS)



NI-DAQmx Version: 9.5 (PASS)



Device Reset: (PASS)



The device was last self-calibrated on: 8/2/2006 1:15:27 AM



Running Calibration ...   (PASS)







-------------------- Testing Counters... --------------------



Testing CTR Buffered Pulse Generation...   (PASS)



Testing CTR Single Pulse Generation...   (PASS)







-------------------- Testing Analog Input... --------------------



Testing AI Ground Reference...   (PASS)



Testing AI Voltage Reference...   (PASS)



Testing AI Finite Sample Clock...   (PASS)



Testing AI Finite Sample Clock Frequency...   (PASS)







-------------------- Testing Analog Output... --------------------



Testing AO Finite Sample Clock...   (PASS)



Testing AO Finite Sample Clock Frequency...   (PASS)



Testing AO Single Point...   (PASS)



Testing AO Accuracy...   (PASS)







-------------------- Testing Digital IO... --------------------



Testing DIO Lines...   (FAIL)

************ Test FAILED for the following reason ************

Error -200587 occurred at Sub-DIO Lines.vi



Possible reason(s):


Requested operation could not be performed, because the specified digital lines are either reserved or the device is not present in NI-DAQmx. 

It is possible that these lines are reserved by another task, the device is being used through the Traditional NI-DAQ interface, or the device is being reset. You might also get the error if the specified resource is currently in use by LabVIEW network variables bound to the DAQ Channel, or if the DAQ Channel is being used in any OPC Client software.

If you are using these lines with another task, wait for the task to complete.  If you are using the device through the Traditional NI-DAQ interface, and you want to use it with NI-DAQmx, reset (initialize) the device using the Traditional NI-DAQ interface. If you are resetting the device, wait for the reset to finish.


Device:  Analog-In



*******************************************************



Testing DIO Ports...   (FAIL)

************ Test FAILED for the following reason ************

Error -200587 occurred at Sub-DIO Ports.vi



Possible reason(s):


Requested operation could not be performed, because the specified digital lines are either reserved or the device is not present in NI-DAQmx. 

It is possible that these lines are reserved by another task, the device is being used through the Traditional NI-DAQ interface, or the device is being reset. You might also get the error if the specified resource is currently in use by LabVIEW network variables bound to the DAQ Channel, or if the DAQ Channel is being used in any OPC Client software.

If you are using these lines with another task, wait for the task to complete.  If you are using the device through the Traditional NI-DAQ interface, and you want to use it with NI-DAQmx, reset (initialize) the device using the Traditional NI-DAQ interface. If you are resetting the device, wait for the reset to finish.


Device:  Analog-In



*******************************************************



 ----- DIAGNOSTIC TEST COMPLETE ----- 

[Thomas-B]

Hi OKors,

So from what we have uncovered, it sounds like this is simply a communication issue with the SCXI chassis. It is as if the chassis' communication with the PC gets cut of when the system is power cycled, and then communication does not reinitialize on its own, but has to be forced by sending a input range command, or something similar. 

If you reset the chassis in MAX or programmatically, does it allow you to read correctly from the AI channels? Could we include a fail-safe that will perform a communication check in case power was cycled, and then reinstates communication through resetting the chassis or resetting the input configuration settings, as you mentioned before?