The Change State button is set to Latch mechanical action:
This means that once the value of the Change State terminal is read on the diagram of FPGA Main.vi, it will latch back to its default state of FALSE.
There doesn't seem to be a way to stop the RT Main.vi running on the cRIO. The document on "...Overveiw of Architeture..." by Meghan August 2012 states on page 29 that pressing the "Exit on the UI Main.vi will cause the RT Main "Exit" case to execute, but this doesn't happen. The code is not setup to do this.
What do you think should be done to bring the RT Main.vi to an orderly Exit?
When the user hits "Exit" on the UI, this case below executes on RT, which should in fact stop all of the RT loops, put the FPGA into a safe state, and then shut down the FPGA VI by closing the reference, and then lastly, restarts the RT system. When you send the "Exit" command, are you receiving any error messages displayed to the UI that may indicate that the message was not received? Does the UI exit, and the RT Main continues to run?
The UI Main does not send an Exit message to the RT Main. I'm wondering if you have a different version of the project than what is supplied with LabView.
These sample projects were designed to have UIs that can disconnect and reconnect to a continuously running RT Main VI on the cRIO. Consistent with this design, clicking the Exit button in the UI will *not* stop the RT Main VI. This allows you to re-run the UI Main VI and re-connect to an RT Main VI that is already running on a cRIO system.
If you want the UI Main VI to stop the RT Main VI on exit, then you can add the code in the blue sequence structure to the "Exit" message of the UI Main VI:
Darren - Thanks! First: this makes sense and will be what we need for the final system. Second: I'm not going crazy after all, which is a little bit of a relief.
I would strongly suggest updating the documentation on this sample project. This is one item to change for sure. Also; 1) The FPGA Reference is a typedef and has to be updated if controls or indicators are added to the FPGA Main. (BTW - why is this a typedef?)
And, 2) The Close FPGA VI Reference needs to be changed to "Close" instead of "Close & Reset" if the project is to work as described with the fpga bitfile in flash and always running to keep safe-state outputs in place.
These things may seem trivial but they will stop someone in their tracks for quite a while. especially someone who is still learning to work with the cRIO.
I've asked Meghan to update the PDF to indicate that the only thing that will shut down the RT Main VI is a critical error. Thanks for pointing this out for us.
I think we typedefed the FPGA VI Reference to preserve interfaces to subVIs that take FPGA VI reference in/out values. It's a pain when modifying the FPGA VI, but once you have updated the typedef, you shouldn't have to update any subVIs that deal with that reference as well.
Since a critical error is the only thing that can shut down the RT Main VI, I think that's why we set "Close and Reset" on the Close FPGA VI Reference. If you were to change the sample project to close RT Main VI when the UI shuts down, then I agree that it would make more sense to change the Close FPGA VI Reference to just "Close".
"1) The FPGA Reference is a typedef and has to be updated if controls or indicators are added to the FPGA Main. (BTW - why is this a typedef?)"
You should actually notice that you only have to update the typedef when you remove controls or indicators from the FPGA VI, not when you add them. As Darren mentioned, the typedef is used so that when you update the following dialog once, all other VIs using the reference are updated as well.
To be clear, the information in this dialog specifies the minimum set of FPGA resources that are required for your user created FPGA API to function properly. You could update the information in this dialog by copying the new output of your FPGA Init into the typedef as it sounds like you are doing now, but it may be easier to instead go and make modifications here by removing the items that are no longer required.
As for the "Close and Reset", I believe you are correct that this is a bug. I don't think we would want the FPGA to ever get reset, and instead rely on it to always be running. If the RT system gets in a bad enough state, the watchdog should kick in and automatically set the FPGA to a safe-state. I really wish important configuration settings like this one were never hidden inside of a dialog accessible only by clicking that VI, making configuration mistakes like this one vary hard to catch, but that is a conversation for another time.
Thank you for the great feedback.
Thanks Burt. Your comments are very helpful. I also found the following presentation and subsequent discussion on reliability that provides more good information on using the cRIO: https://decibel.ni.com/content/docs/DOC-32505
Glad you found that presentation! It generated a lot more discussion than I was expecting, but now there is some great information in the comments as well. Please post back if you find anything else or have any additional questions about the sample project.