06-23-2010 09:44 AM
Problem: Using a 9073 chassis with mixed I/O and both FPGA and Scan Engine, excitation voltage for a 9237 module (in Scan Engine) would not change from the apparent default of 2.5VDC, although the module was properly deployed for 10VDC excitation from the LabVIEW project. LabVIEW version 8.6.1.
Work around: From the RT application, during application start, add an approximate 5 second delay BEFORE calling the FPGA startup.
Background:
Previous use of the 9237 with Scan Engine ONLY had NOT proposed any problems with the 9237 excitation being set based upon the chassis deployment. However, in this application, a mixed system using both Scan Engine (where the 9237 resides) and FPGA, the excitation would not change from 2.5VDC. This was a no load condition on the excitation, therefore a power limiting issue should NOT be present.
After further investigation and setting the 9073 to Scan Engine only and redeploying, the excitation voltage from the 9237 immediately changed to 10VDC. After setting the chassis to FPGA and redeploying, the excitation remained at 10VDC UNTIL THE CHASSIS WAS RESTARTED. At that point the excitation returned to 2.5VDC.
Recognizing this as a potentianl race condition between the Scan Engine and FPGA, I updated the RT application to execute a 5 second wait on initialization BEFORE the FPGA was called.
06-24-2010 04:52 PM
RSecrest,
Thanks for the detailed information on this issue! What version of NI-RIO are you using? Would it be possible to put together a simple project (with the workaround) and post it to the forums so I can try to replicate what you are seeing?
06-28-2010 03:40 PM
NI-RIO 3.1.1
NI-RIO IO Scan 1.1.1
NI Scan Engine 1.0.2
06-29-2010 05:42 PM
RSecrest,
Thanks for the screenshot and the driver information. I havn't found any bug reports on this issue and will try and replicate it if possible. You could upgrade your driver to the newest version of NI-RIO to see if th problem persists there.
06-30-2010 09:20 AM
Ben,
If I were maintaining a single cRIO, updating the drivers would be a nice thought. However, I'm responsible for maintaining 4, soon to be 5, cRIO's. All running critical tests and continuously changing tests. To upgrade the NI-RIO driver that MAY correct a problem to which I have a work-around is not something I have the luxury. Admittedly, I don't completely understand which drivers perform which functions, but this would appear to be a race condition between Scan Engine and FPGA. I struggle with updating only the NI-RIO driver being the fix. If updating has proven to correct the problem, then I will consider working that into my system updates.
RS
06-30-2010 04:20 PM
RSecrest,
We are currently trying to replicate this issue and will let you know what we are able to determine. Thanks again for the info!