View Single Post
  #28   Spotlight this post!  
Unread 14-03-2012, 21:18
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,753
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Team Update - 2012-03-13

Quote:
I wasn't going to post this until later, but the insane CPU usage I've seen this season has prompted me to release this now. I'll do a more formal write up of this in a few days.

Basically, we found ourselves with robot code running near 97% all the time, and it was really messing with our timing. I looked through some of the deep internals of LabVIEW, and found that it's actually quite inefficient in VI scheduling (assuming RT is the same; the documentation did not indicate any differences between LV desktop and LV RT) - In a nutshell, LabVIEW is running a tasking system for each VI, and queuing VI's to run and such.
This seems like an odd place for this discussion, but I'll go ahead and respond here.

The WPILib implementation is indeed pretty heavy. I was able to make small safe enhancements during beta, but due to timing, I could only knock off the biggest issues. At that point, CAN had a call that was quite expensive, and the named registration for RobotDrive was not inplace. I would have liked to do more, and fully intend to do so over the next break.

On the other hand, this is by no means the deep internals of LV, and if by tasking system for each VI, you mean a thread, that is not how scheduling in LV works. I'll be happy to go into more detail, but again, the LV section is a better place to go deeper on this.

While the default framework uses the high level WPILib and regular loops and simple globals, there is certainly no issue with you making mods and using fancier language elements. In fact, that was part of the reason for writing it in source for each language.

Thanks for publishing this, and if you want to go deeper and see how much the various edits saved, please open it up on the LV section.

Greg McKaskle
Reply With Quote