Chief Delphi - What Language To Use?

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - What Language To Use? (http://www.chiefdelphi.com/forums/showthread.php?t=97748)

Re: What Language To Use?

Quote:

Originally Posted by flameout (Post 1083155)

We also experienced issues with code downloads (the only available workaround was to reimage before every download).

This is a common problem involving user code taking up too much of the processor (as the bootloader runs in low priority, it can not run at all if the user code does, say, vision all the time). The solution is to flip the "No App" switch, reboot, then download. It has nothing to do with the cRio image (although an update could've increased processing requirements somewhere to put your code over the edge, so to speak).

Quote:

Originally Posted by flameout (Post 1083155)

As our code that year was relatively simple (because the default vision worked out of the box), it was within our capabilities to have coded in both languages (and C++ too, for that matter). Had we done so, we could've switched languages away from LabVIEW -- likely solving the code download issue (since Java and C++ use FTP, and LabVIEW doesn't AFAIK) as well as possibly restoring camera function.

The real reason that LV dosen't reboot the processor to restart the code - It talks to the bootloader, which then restarts the user code. This allows for much faster code development while using the "Run" from Robot Main, as you don't have to reboot each time. When the LV user code is using too much of the processor, the bootloader can't run, and bad things happen (in the user code too - usually it struggles to run the lower priority user code, probably the cause of your vision issues).

Re: What Language To Use?

Quote:

Originally Posted by apalrd (Post 1083157)

This is a common problem involving user code taking up too much of the processor (as the bootloader runs in low priority, it can not run at all if the user code does, say, vision all the time).

I went back and looked at the thread that discussed the issue -- apparently, a LabVIEW issue nuked the vision, causing it to consume 100% of the processor (I say vision because, from what I recall, nothing else could possibly have taken up a significant amount of execution time, unless the LabVIEW update contained a compiler bug (which I doubt due to the nature of the updates)).

We did not change our code at all when we updated LabVIEW, so that rules out a mistake on my part.

I apparently missed the No App DIP fix -- the post came two days later, so I probably either forgot to check the thread or subscribe to it (we wouldn't have done any further programming after this point until regionals).

Thanks for the help.

Note: I still feel my point about using multiple languages (iff you have the resources to) holds, even if this one instance turned out to be a solvable problem (it would've been nice to just switch languages, rather than needing to scramble for a last-minute solution).