LabVIEW dashboard works in the pits but not on the field

[forbes]

At the Central Illinois Regional my team ran into a problem that put our tote manipulator out of order for about 4 matches.

We read values from a modified version of the LabVIEW dashboard to be able to update parameters on the fly (such as our elevator speed). This worked fine during the build season and worked when tethered in the pit. It also worked in the first 2 matches, but then in subsequent matches we were not receiving some values from the dashboard, causing two of our mechanisms to completely stop working. (I'm not sure if we were getting any data at all, but we were at least not getting two boolean arrays)

We worked with a CSA, but were unable to identify the root cause for several matches. Once we figured out it was the dashboard, we just scrapped using it completely and hard coded all of our values.

I didn't get to talk to the CSA after we figured it out to discuss why this might be happening.

Any ideas?

[IceStorm]

We had a similar issue with using the dashboard to send variables for our auto routine. I spoke with the CSA as well as one of the FTAs about the issue and didn't get a resolution either. However we found under the variables tab if there was a diamond next to the variable then it wasn't being passed between the driver station and robot.
What we found was that the robot needs to connect to the field first then the driver station. As long as they connected in that order we were fine. Other way around and it wouldn't always link up. We would then need to close and reopen our driver station program and everything would be good. Our solution to keep matches flowing and not cause a delay after a brief conversation with one of the FTAs was to wait till we seen at least one of the 5 other robots connect and then connect.

[Arhowk]

How essential are these variables? If it's something that must be configured mid-match than I'd recommend switching to smartdashboard. If they are pre configuration than I'd just set them up via tether than detect in code if the values are good than save else discard and retain old.

You mentioned you had a modified dashboard so that's most likely the root of the cause. did you try starting from scratch and rewriting the dash with basic commands?

[Alan Anderson]

There is still some voodoo involved with getting Dashboard (NetworkTables) communication running. For it to work, many things have to take place in the right order.

The easy way to ensure that everything happens properly is to restart the robot code immediately after the Driver Station is talking to the robot. (I have only seen that fail once, and while I'm not sure what the extra problem was, I suspect it was because the team had the wireless network adapter enabled on the DS computer.)

[Greg McKaskle]

The voodoo is caused by corner-case bugs in the error handling of the TCP reconnect cases. There are several edits needed, some in the DB and some in the DS. As mentioned, the diamonds should tell you definitively whether the variables are synchronized.

Greg McKaskle

[forbes]

Thanks everyone for your input.

We decided to continue not using the dashboard at our Regional last week due to the uncertainty.

A few days ago I saw team update 3/23 that addressed the issue with this document: http://wpilib.screenstepslive.com/s/...24193/l/327864

We may decide to re-implement some of our dashboard features before the World Championship.

[FrankJ]

We are using smart dashboard so maybe not directly applicable.... We were told to restart smart dashboard & DS after tethering in the pits & before connecting to the field. Didn't have any issues with smart dashboard connecting. Didn't try it the other way to test the theory either.