[Greg McKaskle]

Please open up the System Manager, switch to the VI tab, turn off the checkbox, switch back to the first tab and turn on CPU monitoring, and finally Start the monitor. The other tab is useful as well, but with it on at the same time, it pollutes the CPU measurement.

Look at the CPU number in different robot modes. It seems that the download failure is largely provoked by high CPU usage during the download. Typically, the robot mode is disabled, the CPU will be at its lowest. But because it is possible, and in fact pretty easy to put parallel loops that run full speed, even in disabled mode, some robot code loads the CPU to the point that the deploy either fails or takes a very long time. I had never seen this until late this season, and I'm finding some things in LV and in the framework that contribute. Now that I have a couple projects that show this, we'll stomp it for next season, but for this season, lowering the CPU usage seems to be the best approach.

Can you give more details on the watchdog? This could of course be a number of things. If you can tell me how to reproduce this in the code you sent, or in new code, I can probably help out.

A few common performance issues which WPILib will soon help with, but which it currently doesn't...

Relays being set to the same value each iteration, or read each iteration. If you are only setting them one place, use a feedback node to avoid unnecessary sets or gets. Be careful to do the first iteration so that they are set once. Don't read the compressor state in a loop, or change the timeout on the FIFO.

If you indeed see high usage in disabled mode, you can use the profiler to find where it is coming from, or you can make your best guess. Anyway, if you want to make one or two of the heavy parallel loop contents conditional, and have them sleep when disabled, I think you will see the deploy improve immediately. Please let me know your results.


Greg McKaskle