Exempt a cRIO module from a chassis reset

[cahoonaLV137]

I have a cRIO chassis that includes digital, analog out, and analog in modules, and also a 9467 GPS module used to sync the chassis clock to the GPS time signal.  That works fine once the GPS signal acquires a lock.  However, occassionally in the code I need to send a reset to the cRIO chassis to start a test.  This unfortunately resets the GPS module, which then takes between 2-5 minutes to re-establish a lock.  However, my test is less than two mintues long so by then it's a bit useless to wait for the GPS lock.  Is there a way to exempt the 9467 mudule from a chassis reset? That is, is there a way to reset the other modules and NOT reset the GPS module?

[RenKylo2]

Can you me know how you are resetting the cRIO? Are you using the System Reset digital line? Maybe the RT utilities VIs?

Can you also let me know why you need to reset the cRIO to start a test?

[cahoonaLV137]

Hi Ren, thanks for the response. I'm using LabVIEW to talk to the cRIO and am resetting with a "Reset" invoke node after a get an FPGA reference. I'm actually inheriting this code from someone else and realize that resetting the entire cRIO chassis every time a test starts may not be the best approach, but I have some time pressure to deliver and don't have time to re-write the application right now.  I believe they are resetting the chassis to restart the time and return the other modules in the chassis to their defualt values before each test. Unfortunately, the reset also loses the GPS lock as well.

[RenKylo2 · Accepted solution]

Ah! I think you are using this method. If this is not it, please send me a screencap.

This one reset the FPGA VI on the cRIO to the default state, which makes sense that it reset the 9467 as well. If you have to use this method, there is really no way to get around it, unless you program your test to not start until the GPS is sync'ed.

From my experience, a major reason to use this method is good practice. The FPGA runs in parallel with the RT processor. When you open a FPGA reference, it is not a bad idea to reset the FPGA to make sure it is at the default state (a kownn state) before you start running the FPGA. A lot of FPGA related examples in the LabVIEW Example Finder have the "reset" method after opening a FPGA reference.

For your application, it sounds like the original developer wanted to make sure the FPGA is at its default state before a test, which is valid. You need to figure out the reason behind it. Was it for good practice? If it was, then the reset might not be needed at all.

Take a look at the help doc of the method. If the things it reset actually matters to your application, try do a manual reset. For example, the method resets the front panel controls to their default value. If you actually want that, use a read/write control to set the value instead of using the reset method.

[cahoonaLV137]

Hi Ren,

That is the method I am using.  I am a bit new to cRIO programming, so I wasn't used to seeing this use of the reset.  The only drawback is that it does reset the GPS module.  Thanks so much for your input, though.  I am evaluating the code and trying to see if I need to use this reset method, or if I can set it to a known state without it.  I appreciate the comments.