[Dmentor]

Originally Posted by GBIT

1. Plug in your DS and wait for it to fully load....
2 THEN turn on your robot and wait for it to get comms

In pit testing via tether on Thursday morning, we would often see the described problem if we started the cRIO before the DS. We got in the habit of always starting up the DS first when testing in the pits and didn't have any more problems until we started practicing on the field... In several of our matches the robot worked without problems, in the others however we would encounter odd failures associated with the digital IO controls that are relayed through the DS. We would bring the robot back to the pit and go through our checklist only to discover no problems. After a while of head-scratching, we connected the data points by guessing that there might be a startup order dependency that the driver team wasn't aware of. Once we determined this we were able to recreate the odd behavior (DS digitial IO failures) in the pit via tether. Our driver team implemented the startup procedure above using hand signals to ensure that we would always be able to run reliably. We were pretty scared until we discovered this though since debugging unpredictable behavior is tricky.

On a related note (perhaps obvious to most folks) but since the practice sessions have two portions, we needed to reset the cRIO between the portions in order to ensure proper software initialization of states. Otherwise we ended up with the system carrying over states from the first portion into the second.

FYI. We are using the Labview basic framework so I'm not sure how much different the Labview advanced framework or C++ implementations would be.