View Single Post
  #7   Spotlight this post!  
Unread 27-01-2009, 16:06
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,751
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: LabVIEW Woes: Build/Deploy time too long?!

These are all very good suggestions. I'm afraid that the build/deploy is going to be a bit bigger than we'd like this year due to the library collisions, number of file copies to work around the library issue, and then the size of the download.

I'll give away one of my debug tricks. But unfortunately, it speeds up the RAM deploy which is already fast. If you open your top VI, Robot Main.vi or whatever it is, then Save As... to duplicate it to a new name such as RAMSpeedup.vi, then deploy this VI to the controller and minimize the window. Since the RamSpeedup and the RobotMain will share most of the subVIs including WPI, small VI mods will no longer kick as much stuff out of memory. Without RAMSpeedup, any change to the hierarchy of Robot Main will kick all of the hierarchy from memory. The RAMSpeedup will keep all but the modified VI in memory. If you make drastic changes to the Robot Main, you may want to redo the Save As to make it more effective.

At this point I don't know of a way to speed up Build or Deploy steps other than to minimize the number of VIs and maximize the connection speed and computer speed.

Greg McKaskle
Reply With Quote