Build & Download problems in LabVIEW
 

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.

Re: Build & Download problems in LabVIEW
 

Since we've already discussed the build times, I will focus on the other parts of your post.

FMS Lock: Like bumpers, this is a new safety feature. Posting to the FIRST forums will likely be more effective.

No App: If you'd like to send me your code, I'll look to see what may be causing this. The default code, and no code I've written in the past has needed to use the switch, so I really can't tell you what to look for. I'd prefer team not use it on a regular basis. If you are opening the System Manager to measure the performance, does the VIs tab look right? Are there lots of other VIs running, or anything strange? Also, can you simply abort the VIs from that tab, then download fine?

On the fourth, I'm a bit confused as to whether you are deploying or hitting the run button, but either way, you are correct, it shouldn't crash. Most people do not have this problem. Either that, or they aren't reporting it. I have no code to investigate. PM me and I'll give you my email.

Greg McKaskle

Re: Build & Download problems in LabVIEW
 

Greg - we sent you our code earlier, and we are seeing all the exact symptoms as described here (as well as the watchdog expired issues).

Re: Build & Download problems in LabVIEW
 

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

Re: Build & Download problems in LabVIEW
 

Now that makes sense for us. We use our disabled mode for debugging - we call every sensor on the robot every loop in disabled so we can rotate and test things by hand. So our disabled loop is probably our 'busiest' loop.

Since speed doesn't matter, I suppose a simple wait would lower the processor load substantially. We'll try it.

Re: Build & Download problems in LabVIEW
 

I just thought of this while reading another post - is there a way to tell the CRIO to stop executing the program it's running (programatically, rather than the no-app switch)? Simply doing that as the first step of each download would 100% solve the problem.

Re: Build & Download problems in LabVIEW
 

I forgot to mention that.

The System Manager tab, the VI one, lets you see the state of the VIs, run additional VIs, and stop VIs that are running. If the system is loaded, it may take ten seconds or so, but it is pretty fast.

The explicit steps are, 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.

Funny that you mention the disabled state being for debugging. I've heard that before, and perhaps it should be more integrated in the framework, and have a way to keep the CPU load down. Hmmm.

Greg McKaskle