3/12/13 Game Update

[Hallry]

Taken from the FRC Manual, 3/12/13: http://frc-manual.usfirst.org/Updates/0#term 99

Game Manual


Mandatory C++ Update:

If your team programs using C++, please make sure you’ve installed the update posted last week before taking the field at an event. CSAs will be circulating in the pits to ensure and assist with this update for those particular teams affected.

From last week’s Team Update: A required update has been released for C++. This update fixes an error in the implementation of Network Tables feeding information to the SmartDashboard. It also fixes an issue with LiveWindow code causing crashes for teams using threads. Full release notes can be found on the 2013 Software Notes page. Our thanks to the teams and volunteers that helped us identify and troubleshoot the issues and solutions during Week 1 Events.

Bandwidth

We want to remind teams of the bandwidth limit incorporated in to this year’s communication protocol (described on pg 7 of the FMS Whitepaper and legislated per [R59]-B). Generally speaking, this limit restricts the amount of information that can pass through the field network on a team’s VLAN. This setting can be mimicked at home using the Bridge Configuration Utility.

Pay special attention to the camera setting and related data rates on page 7 of the FMS Whitepaper. If you notice sluggish or erratic control using these settings at home, you can expect the same behavior at an event. If you disable these limits at home, you’ll be able to transmit more data, however once you’re on a competition field, the limits will be back in place, and you may again experience sluggish or erratic controls.



Thank you, and good luck at Week 3 events!

Nothing regarding the camera/dashboard ban in eliminations or the optional removal of the tops of the feeder station slots that occurred at NYC this past weekend...

[joelg236]

It concerns me that it seems like FIRST's solution to field problems is removing software options. The network should be fully capable of handling basic network IO. My hope is that they address this honestly, but even an email from our CSA said to use as little bandwidth as possible. It seems like this can only go worse unless something is done to make communications consistent.

[roystur44]

Backup your robot code and give your programming team enough time to rebuild the CRIo if the patch doesn't install properly.

We had the FTA give us the patch right before a match and it killed our robot.

Special thanks to Ross of 973 for helping us get our our robot back in action.

[RufflesRidge]

Originally Posted by roystur44

Backup your robot code and give your programming team enough time to rebuild the CRIo if the patch doesn't install properly.

We had the FTA give us the patch right before a match and it killed our robot.

Special thanks to Ross of 973 for helping us get our our robot back in action.

If there is a bug in the update, I'm sure FIRST wants to know. File a bug report on the WPILib project.

[catacon]

As expected, this update also bricked our cRIO. After reimaging, we can get the cRIO to talk, but the update has introduced some incompatibilities with our code. Everything but the bare template gives us a "No Robot Code" error which implies a runtime error. We are making heavy use of threads this year and we are suspecting that is the issue. We are going through our code block by block to try and find the issue.

[joelg236]

Originally Posted by catacon

As expected, this update also bricked our cRIO. After reimaging, we can get the cRIO to talk, but the update has introduced some incompatibilities with our code. Everything but the bare template gives us a "No Robot Code" error which implies a runtime error. We are making heavy use of threads this year and we are suspecting that is the issue. We are going through our code block by block to try and find the issue.

In C++ right? Is there no console to output stack traces to with C++?

[catacon]

Originally Posted by joelg236

In C++ right? Is there no console to output stack traces to with C++?

Working on that now.

WindRiver was also having an issue with some of our include files. So we are trying to sort that out now. Looks like this update doesn't like to play nice, at least with our code.

BTW, we have two guys at the shop working on this. I am assisting from 100 miles away, so bear with me.

[catacon]

Looks like we hit a fatal error during runtime.

Fatal Error!
Machine Status Register: 0x0008b012
Condition Register: 0x24004448

No idea what that means.

But, they did narrow the issue down to the cypress.cpp file.

[MamaSpoldi]

We were one of the teams that they tested the latest update on at the end of the BAE Regional and we had no issues. We did not have to re-image our cRIO or make any changes to our code other than rebuilding and downloading the updated executable.

Originally Posted by catacon

As expected, this update also bricked our cRIO. After reimaging, we can get the cRIO to talk, but the update has introduced some incompatibilities with our code. Everything but the bare template gives us a "No Robot Code" error which implies a runtime error. We are making heavy use of threads this year and we are suspecting that is the issue. We are going through our code block by block to try and find the issue.

Originally Posted by catacon

Looks like we hit a fatal error during runtime.

Fatal Error!
Machine Status Register: 0x0008b012
Condition Register: 0x24004448

No idea what that means.

But, they did narrow the issue down to the cypress.cpp file.

Note that we are not using threads or the cypress board, so perhaps those potential differences mentioned are related to the problems you are experiencing. Can anyone else who is using these features indicate whether they are also seeing issues?