Debugging Information

• Control System Status Lights Are Your Friends
• Field Management Status Indicators
• Driver Station FAQ
• An Overview of FRC Watchdogs

Common problems and symptoms

• Opening the same device (PWM, Solenoid, Relay, etc.) multiple times
• Miswiring vi inputs or outputs
• LabVIEW version not up-to-date
  
• cRIO image not a match to the LabVIEW version
• Do NOT modify Framework code outside of the "Team Code" folder.
• cRIO download times out
  If you can connect and begin a download, but it freezes and never finishes.
  Try setting the "NO APP" DIP switch on the cRIO and resetting the cRIO. If your download is then successful, the problem is that your code has unbridled loops.
  What's happening is your code runs at a higher priority than the ftp utility transferring your new code to the cRIO. If your code never gives up even a bit of processing time, then the ftp utility can never get a chance to run and transfer your new code.
  Wherever you have infinite while loops in your code they will suck up all the available CPU time unless you include some miniscule delay. Your code should always incorporate a time delay of 10 or 20ms to release the CPU for lesser operating system tasks to use.
• Failed to download NI_FPGA_Interface.lvlib:NIFPGA
  Try re-imaging the cRIO
• LabVIEW screen has watermark on it or a Build fails with message: "This build specification uses VIs from Vision Development Module which is currently in evaluation mode..."
  This means you haven't activated your LabVIEW license.
  
  • Connected to the Internet
  • Under Windows Start -> All Programs -> National Instruments -> NI License Manager
  • Expand the files on the left (LabVIEW 8.6.1)
  • Right-click on "Development System" and choose "Activate"
• Cannot Activate the LabVIEW licenses. You may be trying to activate the non-FRC versions. Make sure the software version includes "FRC."

LabVIEW Troubleshooting Tools

System Manager

Tools -> Real Time -> System Manager
This is basically the task manager for the LV cRIO. To get an accurate reading of CPU usage, click to the VI tab and turn off the Track VI States. Then click back to the first tab and Start. The bottom chart shows CPU usage and you should help understand what the cRIO is having to perform. Using this, you can run different modes, turn off different features, even comment out some code, and use the task manager to learn what the CPU cost is of different features. The System Manager is indeed a very high level tool, very easy to use, but it is a single number, a single speedometer. Before going any further, make sure to go to the VIs tab and turn off the Monitor VI State feature. This is also useful to see what is running, but with so many VIs on the cRIO, this monitoring will raise the CPU number by quite a bit.

Performance Profiler

Tools -> Profile -> Performance and Memory
Change the Targets to profile the cRIO The most trustworthy way to use it is to

• Start Profiler
• Run your LabVIEW program
• Stop your LabVIEW program
• Stop Profiler

Once you know what you are doing, you can use the profiler while your app is running, but until you know what is slow, this is the best way to start. Once you stop the profile, you can click on a column to sort, and you can double click on a row to see what subVIs were called by and contributed to the VI time. Note that the profiler only reports VIs that started and finished while the profiler was on. Also note that the profiler works at the level of the VI. It will not tell you which loop or node within the VI took time unless that node is a VI.

VI time measurement

ElapsedTimes.vi (by NI's Greg MacKaskel) can be dropped multiple times anywhere within your vi's and it's front panel will display how often it gets called. In Teleop.vi for instance, this will tell you if your code is taking longer than the 20ms per Driver Station packet.

Here's another homegrown vi utility that graphs the actual timings as well as an average over the past 25 samples (you can change that to any number you want). It's easy to compare the range of variations in timing from call to call. This drops into any vi, but the main routine can only be used in one place (the Moving Average vi can be used as many places as you desire).
GraphTiming.zip

Other

LabVIEW also generally has the built-in capability to debug a stand-alone real-time application, however, this has not been delivered with the FRC cRIO image in either of the 2009 or 2010 competition seasons. There is a trade-off in lost storage and memory on the cRIO and the NI crew has decided it isn't worth the trade-off for most FRC teams. It may become available in the future.

Miscellaneous Notes

• Avoid unnecessarily repetitious sets or gets
• If the NO-APP Switch is Necessary
  Open System Manger, flip to the VI tab, Start the monitoring, wait for the list to populate, select Robot Main, and Stop the VI. At that point, the CPU is not loaded, and you can deploy.
• Builds occur faster if all the vi front panels are closed
• PID
  To insure constant loop times without impact from other parallel tasks you might want to isolate the PID into itÕs own vi and up itÕs execution priority from the default. Make it more important than all other viÕs, but be sure it releases the CPU for use by lesser viÕs.
• Where Is My Global used?
  Right click on the global and select Find>>References for a complete list of readers/writers.
  
  Get Microsoft Excel Viewer
  Get Microsoft PowerPoint Viewer
  Get WinZip