I’ve been hearing for quite a while that calling Finish.vi is better than cutting power and that all device references should be closed there. What I’d like to know is why. During competition the robot is shut down in this “bad” way many times, with no messy results of Finish.vi not being called. So does it really make any difference?
I would also really like to know this! Is calling Finish.vi better then not? Does it make a noticeable difference?
In case the discussion on the forum isn’t clear, I’ll attempt to summarize.
The WPILib code for the cRIO was written so that aborting a VI will cleanly deal with closing I/O for you. This is not always the case, and some OS resources or 3rd party libraries will lock up or behave incorrectly if you misuse their API.
As a good programming convention it is a good habit to close things you open, and furthermore to strive for having resources opens and closes be consistent, easy to verify, and easy to describe to others. Rube-Goldburg devices may be fun to look at, but are not fun to debug or modify, and you don’t want one in control of your resource handles.
On the other hand, simple is good, and if there are no bad consequences to writing infinite loops and letting the auto cleanup deal with resource handles, why not take advantage of it in your code.
These conflicting goals have led to the template code being a little inconsistent. It tends to contain data wires leaving infinite loops wired to close nodes. By definition, an infinite loop does not finish, thus the close will not be called. The auto cleanup is the way most handles are currently being closed in the standard LV template. Meanwhile, if a team decides to change their loop so that it does terminate, then the next thing they’d probably want is to have a close for all the resources outside the loop, so the close was placed there for that purpose – to show where you would typically close things if/when the loop is changed.
I hope this helps explain the legal usage options.
Greg McKaskle
Thanks for closing the loop…