Opinions wanted: LabView-based controller?

[Mark Pierce]

I'd much prefer to stick with text based programming for the same reasons already mentioned by others. I can see some benefits to the Labview environment and done right it can work.

However, getting it "done right" can be tricky. My FIRST Labview experiences have not made a good impression. This applies to both trying to get the Camera code working a couple of years ago and trying to do a data acquisition project last year. I'll admit to not doing much of the tutorials, but a lot of my concerns really aren't covered in the ones I did try.

1. Installation instructions have been poor or missing, even with correct instructions it takes a long time to install. We usually have four classroom computers plus at least two mentor or loaner laptops.
2. Sample applications have been buggy and cumbersome. (Think version 1 of CMUCam application)
3. The environment likes to start up device drivers for devices when you start the system. I still get occassional error messages from some LV process while shutting down my laptop.
4. LabView also likes to go out to the network when you start it. When I'm programming for FIRST, I hardly ever have a network connection. I think I eventually figured out how to turn this off.
5. LabView (or at least the applications I've tried) seem to require a lot nicer laptop than the hand-me-down school laptops we've used.

I'm sure we can work with it, but as I've said elsewhere, the sooner we know what we're working with the better. This would be a major change, not just a rehashing the current code. Labview based development will call for an entire new set of training resources. The demo at Kettering made it look more promising than I would have thought, but the details are key to making it work.