Quote:
Originally Posted by Sconrad
As far as I know (my second year on the team), we haven't had much trouble with the code overloading the cRIO resources in any way. However, compile/build time has been an issue. Some things that helped us were to avoid organizing code in subvis and avoiding while loops in teleop and autonomous (nested loops apparently are very difficult for labview to manage)
|
If you think this compile and build time is bad, go back to 2009 (the introductory year of the cRio and Labview for FRC).
You can minimize compile and build time by:
1. Using text files that read in constants that you use. You can FTP the text file, modify it, FTP it back, then have your code re-read it. This requires a little knowledge of the File I/O pallet and FTP, but it's a huge boon when you are tweaking things like autonomous.
2. Run the program from your laptop / computer rather than building it and deploying it. Use controls instead of constants. Once you've reached the right values, right click on the control and change it to default to your new value.
In fact, in 2010, the very first time we deployed code was the week of bag. Up until then we were always running from the computer while we updated it.
Labview handles loops just fine. The problem with using loops in Teleop and elesewhere is that the robot framework is already a giant loop that runs over and over again. The timing is tied into the driver station packet timing, and watchdogs monitor that your code is inputting and outputting often enough. If you have a loop in teleop and that loop takes some time to complete (we're talking more than around 1/20 seconds) you'll trigger the watchdogs. They assume something has gone wrong, and begin disabling functions on the robot for safety reasons.
Because Teleop is already one big loop, there's never really a reason to RUN a loop there. If you need something to loop more quickly, then use the period tasks (the area where the vision VI is put) in robot main.