Closing Periodic Task Resources

[RKING]

The RobotData information extends from the Begin VI to the Finish VI in Robot Main, so any resources opened and configured in the Robot Data dev ref and bundled into the robot data structure can be closed in the Finish VI.  But, the PeriodicTask Resources opened and configured in the Begin VI are not wired to the Finish VI in Robot Main.  Sensors like gyro and accelerometers might be opened in the periodic data and not in robot data.  What is the correct procedure for closing the resources opened only in the Periodic data structure in the Begin VI?

[DiscoBall]

Hi RKING,

To properly close tasks you can add the references to a terminal and then wire them into the Finish VI or you can use a global variable, or many other options. So long as you are closing the references before the Stop VI is executed in Finish.vi you will be doing the right thing.

[sciencewhiz]

I think it's a little more complicated then that. Specifically, the while loops in periodic tasks stop condition is wired false. Therefore, if you wired your references from output of the perioid while loop to finish, you wouldn't ever execute finish. If you wired it from the inputs of the while loop, or from a gobal variable, the periodic tasks would possibly still be trying to access the hardware between the time that the finish VI is started and the stop condition is called.

I guess it really comes down to the question of whether the WPI Robotics library references really need to be closed. In most cases, a robot is going to be powered off without finish being called, thus they don't get closed. Is that a problem?

[MarkBlack]

There are very particular instances where we need to use a close VI in order to for the code to operate correctly.  As Sciencewiz pointed out we do not see many close VIs used in parts of the frameworks, and this is because when the controller is shut down or the code stops running we do not need to explicitly release the hardware resources.

The situation where we do need to use the a close VI is when we are accessing a hardware channel during on point of the program, but we need to open a new reference to that same channel later in the program without stopping and starting to the code in between.  If we try to open an already open hardware reference the program will throw an error.  If we close and then reopen the hardware reference we will not throw an error.

Let us know if this is helpful!

Cheers,

Mark

NI FIRST Support

[RKING]

Thanks, DiscoBall, sciencewhiz and BLAQmx for your responses and ideas.

I would like to explore the comment that when the hardware shuts down we don't need to close.

I am wondering about redeploying without closing and without hardware power off.  I'm not sure if a memory leak would develop on the cRIO.  Do you know?

I am also wondering about teaching high school students that they can get away without closing.  Do you think  it would be better to modify the framework to make it more straight forward to close the resources in the Periodic Task devref and Periodic Task VI?

[RKING]

The pdr, "Best Practices for using the FRC cRIO Project Frameworks," suggests that the Close VI be placed after the While loop in the Periodic VI.  The pdf also suggests that the error out from any resource be wired to the loop conditional terminal, so the loop only terminates if there is an error.  the pdf uses accelerometer as an example.  If there is an error reading the accelerometer signal, the loop stops.  But the Finish VI might execute before an error is experienced by the accerometer read.

Perhaps the solution is to put a Boolean global in the Finish VI and write TRUE  to it when the Finish VI is called.  The Periodic VI could read this global and stop the loop if the global is true or if there is an error from any of the devices in the loop.  Is this an appropriate solution?  Is this even necessary?

[MarkBlack]

You are correct to point out the frameworks do not use some of the programming practices described in our tutorials.  I woud recommend using your method of stopping all loops with a global variable so the program can more gracefully shut down.  This is simply good programming practice

I also spoke with our developers asking why we do not need to explicitly close  hardware resources after aborting or deploying new code to the controller.  The Open VIs look to see if the hardware channel is already reserved.  If it is reserved and its the first call of the VI the hardware resource is programmatically released before it is reopened.  If we try to open a reference to a hardware channel that is already open and our code has not stopped running then LabVIEW will generate an error.

Please let me know if this is at unclear.

Cheers,

Mark

NI FIRST Support