Tim, just as John Sabath said, the intent of the flat sequence structure (besides avoiding a race condition) was readability, especially with younger programmers not familiar with LabVIEW.
Quote:
Originally Posted by Greg McKaskle
<snip>
|
Thanks for the feedback, Greg. We started using network variables because of how well they are organized and viewed in the Project Explorer, and because they simply seemed like a another type of global variable. Interestingly enough, we actually got the idea of using network variables to store refnum names from FRC68, in order to avoid the errors due to misspelling refnum names (when creating string constants, as the default code is set up to do), after they saw how we used network variables to share local robot state data across VI's.
Our intent was always to be able to view all of those variables constantly - sharing them between computers - but accomplishing that in FRC means pushing them through the Dashboard, or manually using UDP or TCP packets, not actually utilizing the network variable itself (I assume).
I think that what Greg proposed - an enum (perhaps one for each type of refnum - motor, digital I/O, solenoid) would be the best way to evolve this system further. I think the ideal solution would be for LabVIEW to throw an error if refnum names were misspelled (similar to how in a text-based language, if variable names are misspelled, errors are thrown) - but I don't know how that would be implemented in a visual language like LabVIEW, where most data flow isn't named.
Sorry for the graveyard resurrection, but I thought some input from 2337 would be nice, even after the fact.