Robot Twitch

[Greg McKaskle]

I don't mind good complaints -- especially when I agree with you.

The issue is that we are using an uncommonly used hook to catch unwired errors and routing them to the DS. This doesn't take the full 200ms, but I think it takes 15 or 20ms, ruining your control rate.

We tracked down the issue a few years ago and I didn't have the foresight to get it fixed for 2011. I looked again this year for a workaround and couldn't find one. Fortunately, I know the guy who can fix it and he is now on the FRC team, so I think it will get fixed.

For more details on the issue, before LV can run code it has to reserve it. It visits all called subVIs and other resources that it needs, reserves them, and ensures that everything is actually able to run. Then it runs the handler once, then it unreserved it, which unreserves all of the subVIs. The algorithm is typicall run once when the app starts up, but the hook for catching errors does this each time the error occurs -- not really the right hook for what we are doing. The hook was intended to log to disk or put up a dialog and we are using it in a situation where it keeps going, so the performance is more important.

Greg McKaskle

[tipsmiller]

My team was having the same issue. Our programmers had written code and initialized sensors which were not yet connected on the robot. What we saw happening was that the digital sidecar would poll the pins that the sensor was supposed to be attached to. When the sensors weren't there, it was releasing the charge it had built up through the other ports.