[Clayton Yocom]

Hello Everyone!
I'm the programming lead for the TechnoKats, and we've been having some interesting issues/results that we'd like to share and see if anyone else has been having similar issues.

Today, after our practice match, we took to the practice field where we had large delays and weird results from our PID loops. This included our arm pid occelating as if we set the PID wrong. The first thing we did when we got back to the pit is tether the robot and try to replicate the problem. Here, we found that not only could we not replicate the problem, but we could not find any issues with communications or dropped packets in our driverstation logs.

Now we go into debug mode. Where is this mysterious bug and what could be causing it? We then noticed we had been pushing 100% cpu on the cRIO without even running teleop. (This is odd because all of our vision processing is done off-board, on the driverstation) We then checked all of our code and loops for delays. After not finding any, we asked NI for help. They continued the search, and we ran into dead end after dead end. We started disabling code to find the errornous code, and we started to narrow it down when we ran into the double timeout bug.

The double timeout bug is where (as it has been explained to me) where the cRIO thinks its connected to something but isn't. That causes it to do weird things like not let you deploy code and such. The only way to fix it (that I've found) is to reboot the robot. If it continues then turn on "No App" switch on the cRIO and deploy code again. Then restart the cRIO without the no app switch. This should solve the problem at least for awhile.

So as we were testing for the code that was flooring the cpu, we decided just to upload the original code and run the profiler, and that's where the weirdest thing happened. The cRIO stopped being floored. It cut the usage in half without a single change. If anyone else has had an issue similar, please let us know so we can fix this properly.
Thanks!