We just detected a case where it appears that loading an example corrupted a robot project. WPI_DriverStationStartStop.vi had a bunch of code related to one of the examples in it, in the “execute” case, that was not the simple stuff that belonged there. I can imagine how in the examples messing with some of these VI’s to run the examples is a really good idea. I am looking for the stupid user trick we pulled to cause it to happen. I’m kinda looking for you, NI Greg (please
Learning take-away: the deployment whined about a DIO collison; we went into begin and selected the DIO Open Vi, and fired off "Find All Instances’ off the right mouse button. Bingo, all of out expected instances, plus two from the corrupted code. Worked again a few minutes later to find a collision on the analog inputs between the battery Vin on AI8 and the ultrasonic we plopped in on 8 because 2 had gone bad on our adapter (the voltage regulator smoked, too).
This is getting to be too much hardware for a software jock
The good news is we can get big scores two weeks before B&T for the first time in our history!
I’m not really sure I know what happened. I don’t really follow the description you gave.
Was this extra code perhaps related to simulation?
Some of the WPILib VIs needed to be modified for simulation. Some of these were done with a conditional compile, but most were done as a separate library for the desktop target. If you open your VI on a desktop, it will load the desktop version. On an RT target, it will load the RT version of the VI.
Another thing that could have happened is that you opened a robot VI and it was added to your example project, or you opened an example VI and it was added to your robot project. The suggested process is to open the example’s project and not just its source.
we had an issue with one of the example vi’s addressing DIO 2, which was not present on our robot. just make sure you comb through all examples and that they match your actual hardware configuration.
Review of a backup showed that it happened during a relatively unsupervised moment, so we’ll never really know. I’d bet on the last of Greg’s explanations.
Admittedly, it was neat to see how the simulator gets set up
