[apalrd]

I have noticed many problems with the Build and Deploy process in LabVIEW.

The first is build times. I clocked a build of mine at 2 mins 41 secs (then I timed a build for the IFI processor and it took 4 seconds to do a full clean&build - Aprox. 30 times the build times or 3000% increase). At Troy we had two matches between our quarterfinals, and had to download some autonomous mods. The full process of tethering, waiting for the cRio to boot up, building, and downloading, rebooting, and moving the arm (plus that FMS lock thing) left us with almost no time to change the battery.

The second thing - FMS lock. Often, when we come off the field, we need to do a check of the robot. This requires us to boot up the Classmate, log off, and log back on. I wish there was a better way to clear the FMS lock.


The third is another major problem - The cRio "no-app" switch bug. Apparently, NI claims our code is using too much of the cRio leaving not enough for their bootloader. I used the benchmarking on Default and my code and found that with Default code running (full build and burn) the cRio was at aprox. 92%. Then My code was between 89% and 92%. Then I realized I had one of the System Manager options enabled that gets data on all VI's, turned it off, and got 70% CPU on my code (I didn't get a chance to re-do Default since it takes too long to build and deploy). I am not using Vision, and its really annoying to have to carry around a personal scribe to flip the No App switch every time I want to flash the robot. I eventually solved this problem by running my loops slower (I was doing calculations at 20ms (50hz - perfectly reasonable time) and upped some of them to 30ms or 40ms (not as fast as I would like but still acceptable for most things).

This is the big one:
Sometimes when I try to download, the robot crashes. I loose Comm and Code on the DS and then it does a full reboot. I keep trying again, and it eventually works. It is more likely to succeed (almost 100% success) when doing full builds - but running Robot Main NEVER work on its first try and almost always works on the second or third reboot. This is completely unacceptable. Today I spent my entire lunch tuning Autonomous to fit some extra spring on the kicker. Once I got it working, it worked, but every time I changed something that wasn't a kick distance (those are controls) I would have to re-download, and probably reboot the robot (I noticed that when code is not running it has a much higher success rate). I went to the Pit Admin asking where the NI representative was, and there was no NI rep at Troy. Again not good. The system is new and there are still bugs, and without NI reps to help us out, we may never fix them. They instead sent me to another team, who informed me they have seen the EXACT same problem and fix it by re-imaging the robot.