Bizarre cRIO Server Errors (FDIO)

[Aren Siekmeier]

Originally Posted by virtuald

Sorry for the delay, today was busier than expected. I've posted a compiled binary to http://firstforge.wpi.edu/sf/go/artf1719 . Unfortunately, I haven't been able to verify it on a cRio as I don't have access to one at the moment. However, the original WPILib binary is 13.0 MB, and this one is 13.1 MB, so I expect that it should work.

Let me know if this helps your issue!

We applied this patch, and rebuilt and redeployed our code. It appeared to improve the problem at first in that it gave the same FDIO errors as we saw previously, about as frequently as we had been getting the timeout errors, and we did not appear to be hanging. However (and we don't really understand what happened here), after a very short time, it started timing out immediately when enabled, giving the same error at line 117 of MotorSafetyHelper.cpp. One interesting thing to note is that when disabled all these errors stopped, so it seems to still be making it through the control loop in IterativeRobot.cpp (StartCompetition()). We have most of these error messages logged, so as soon as someone has access to those text files we will post those.

We have ported all of our code to Java and LabView, and neither of these implementations seem to show the same problem, though we hope to run the bot into the ground a little more over the next few days to tease any more errors out of it. Some C++ code that doesn't use Commands or the SmartDashboard/NetworkTables is in the works so testing that may also give some insight. We will probably stick with the Java implementation for the rest of the season.

[JamesTerm]

Originally Posted by compwiztobe

We applied this patch, and rebuilt and redeployed our code. It appeared to improve the problem at first in that it gave the same FDIO errors as we saw previously, about as frequently as we had been getting the timeout errors, and we did not appear to be hanging.

Try this one https://www.dropbox.com/s/dbpv32qii7...sDustinFix.zip
I've spent quite a bit of time testing this, and it's an interesting twist of fate that both Dustin and My patch compliment each other for best results during booting of cRIO. For one client stress it works perfectly... for a 3 client stress it did show one error but recovers just fine. This patch divides a new critical section to restrict the main robot's get/put calls to a localized scope that was easier to manage... basically I wanted to minimize the work to just put the variables and get out without interference with I/O critical section operations. There is also a sleepless thread fix in there as well. This is still unofficial, but I think it is good enough to at least get some testing.