LabVIEW: Takes way to long to run Robot Main

[baronep]

Assuming as given that our laptop is not the greatest, but it is taking forever to run the Robot Main VI the first time (>5 min) and then longer than usual (>2min) every subsequent time. This was annoying in the shop, but at the competition, this is a real problem. Does anyone have any ideas why this might be happening?

Thanks,

Patrick

[Joe Ross]

https://decibel.ni.com/content/thread/16692?tstart=0

[Greg McKaskle]

To expand, I was in a meeting just yesterday reviewing issues related to similar bug reports. We understand them pretty well and are now able to give some best-practices for this season that will help avoid unnecessary compiles during run and build.

Run-button click for RobotMain:
-------------------
If you DO NOT have a startup application on the controller, simply press the run button. The first time it will deploy all VIs to RAM and subsequent "warm" runs will take advantage of already present VIs and will be quite fast.

If you DO have a startup app on the controller, the recommended procedure is to close the RobotMain VI, right click on the target and connect to the controller. This will abort the startup application. Then open RobotMain and click run.

When RobotMain is open while conflict resolution runs, it will cause each VI to believe it needs to recompile, causing a very slow run operation. If the slow run is already underway and the startup application has already been aborted, it is also acceptable and safe to cancel, close RobotMain, reopen RobotMain, and click run.

Another approach to avoid this bug is to unset as startup when you need to do substantial development involving reboots of the controller. Remember to Build and Run As when development is complete.

Building:
----------
When building the application, be sure to open RobotMain first. While it will build the same EXE with the VI open or closed, opening the VI will allow it to use previous compile results and will be far faster.

Run as Startup:
-----------------
We have seen situations where a startup application is present and immediately following the conflict resolution dialog, the communications ceases and the dialog will state that it is waiting for the controller. If the CPU usage of the cRIO is steady at zero, it is best to cancel and select Run as Startup again. The process should not take more than twenty seconds, so when it does, it is not working correctly and should be started again without rebooting the controller.

This bug has been quite hard to reproduce in-house and the root cause is still being investigated.

---------------------

I want to personally apologize for not catching these issues earlier in the season or during beta testing. The tests that were in place did not have a way to measure the number of unnecessary compiles and didn't always include the startup-app situation. These issues are being addressed and tests put in place to ensure they aren't introduced again.

If you find other issues, please don't hesitate to report them to the NI/frc support forums so that we can investigate them fully and correct the issues.

Greg McKaskle

[baronep]

Wow! That makes a world of difference. Just wish we had known this earlier. Just curious, what changed between last season and this season that makes this necessary?

-Patrick

[Greg McKaskle]

Bugs. Pesky corner case bugs.

More specifically, a few years ago the compiler was rewritten to include more passes and more optimizations. It now uses LLVM from Urbana Champaign for backend code creation. Great stuff except that the compile became about ten times slower than it was previously.

In response, they created a caching mechanism that looks at code signatures and attempts to reuse previous object code stored in a database. Bugs in this approach come in two forms. If you use the cache when you should have recompiled, then the code is wrong, may crash, or may give the wrong answer. If you recompile when you could have used the cache, you get the right answer and operate correctly, but take much longer to build. The owners of this code have to be pretty careful not to have bugs in category 1 and have inadvertently introduced bugs in category 2 due to insufficient tests.

I also wish we'd heard of or found these earlier. The best we can do now is to publicize the best practices, apologize, and wait for an improved edition. These particular issues are already resolved in the codebase for LV 2013 which is in beta testing and due to be released later this year.

Feel free to tell other LV teams of the best practices. Many teams don't go to CD or the NI or FIRST forums and may not hear of this.

Greg McKaskle

[baronep]

Ok thanks. I really appreciate the timely help with this.

-Patrick