Quote:
Originally Posted by apalrd
The Default code gets around this limitation by not running most of the code when disabled. I hate this method, as I can't debug without enabling the robot, and it's sometimes useful to probe an output without allowing it to move.
|
First, we solved the issue Palardy mentions by having a switch so we could enable and disable all our programming in the disabled VI. We also run a ton of code in disabled: every sensor is polled in disabled and we have some autonomous script code running as well.
Secondly - our default project in 2012 and the 2013 runs in the neighborhood of 60-70% cpu utilization as read from the driver station. This was true for us on both the 4 slot and 8 slot cRIO's. Usually we saw it closer to 60%. You should not be seeing 95% utilization with a default project.
We saw the 'loop running slowly' messages when running the code from the programming computer. We did a couple things that seemed to help. First, we noticed that they completely disappeared when we did a permanent deploy. Perhaps it's the number of indicators / controls we had in our project. We also started tethering. We were running through our wireless network with all the other computers on it. That occasionally caused a failed deploy and was definitely causing connectivity problems. I assume that was because of latency: we didn't dig any deeper because it was easier to just tether the robot.
Our 2012 code in teleop rarely when over 85% cpu utilization. However, when vision was enabled, which was only about 1/4-1/2 second during our lock-on phase, usage spiked to 100%.
We kept a very close eye on it during development. Several times we implemented code and saw it jump substantially, so we went back and restructured things. Our most common trick was to have an equality in front of VI's so that they did not execute if the incoming data had not changed.
In addition, we implemented Palardy's 'improved' motor set VI's. That dropped our cpu utilization by a fair amount. Perhaps 6-8%, but I can't recall exactly anymore.
Finally, we found that our old '09 classmate was no longer adequate for our driver station. We found this accidentally at our first competition. After the first practice match the drivers complained of lag in the control system. We checked the cpu and it looked good, however the timing in the communication graph was shot through the roof. We reimaged clean and nothing changed. We were not using a custom dashboard. We plugged in our development laptop (quad core etc) and the ping spikes disappeared.
That's all I can think of right now.