Not unrealistic! There are a number of battery powered aircraft (that even hold people!) being manufactured today. Still kinda experimental, but getting much better. For starters, check out:

http://www.yuneec.com/
http://www.electraflyer.com/
http://www.pipistrel.si/planes/35

Yes, the energy density of the best batteries are about 5% that of gasoline (not 1%) but a gasoline engine is only about 20% efficient at converting chemical energy to mechanical. An electric motor is more like 90%. It's no where near equal, but definitely usable.

... but my VT102 terminal only has the one and the APL compiler doesn't understand a \t.

Mantis shrimp eyes would be f-ing cool!

All of the "Johns" from Buckaroo Banzai. Worfin, Ya Ya, Small Berries, etc. That is all.

You've a valid point with regards to the LabVIEW code. I've been a LV and C programmer for a really long time and, as an independent consultant, I'm usually called when things go awry. That said, some of the worst code I've ever seen has been written in LabVIEW. Loops nested 20-levels deep when a simple state-machine would do. Parameters passed solely via over 1000 globals. Logic so contorted that Godel would have shot himself in frustration.

The problem is not that LabVIEW is bad per se, but that the coding bar is low. People who have only written "hello world" in VisualBasic get a copy of LabVIEW and try to conquer the test and measurement world.

So I guess I feel your pain, but don't blame the tool for crap-code. - Jim

Oh, and that's me (j_cavera)... Just forgot to log-in. - Jim

Two ways of doing this. Easy way (and the way that NI tells you to do it): create a control template for the cluster. When the template changes, everything that subscribes to the template changes accordingly. The limitation is that it is still a cluster and those aren't the easiest things to work with. Your circuit analogy is a good one in this case.

Harder way (but worth it and something that NI doesn't tell you): Store all variables as a 2D array of either strings or variants. For each row in the table, the first element is the variable name, the second is the value, the third is the data type and the fourth is the units.

This is a royal pain in the *** to code initially, but will save you limitless time later on as you end up getting things like state persistence, search-sort, type conversion, and so forth.

Over the decades (yes, I've been coding LabVIEW for a couple of 'em), I've come up with an entire suite of VIs to work with these variables in 2D arrays just as though they were named members of clusters.

Don't know if the paper and sample code is still up on ni.com, but I did a presentation on this at NIWeek 2006. Hope this makes your LabVIEWing much more pleasant...

- Jim

I've been a LabVIEW developer for 20 years now (since v2 came out in '89) and a C-coder for about almost as long and I can say this with about 99% certainty: LabVIEW is not for everything, but what it is good at, there is no good replacement (open source or otherwise). LabVIEW is second to none for data acquisition, control, (some) analysis, (some) simulation and (some) SCADA. On the flip side, unless you've a lot of experience with LabVIEW and/or a lot of time to kill, don't try anything with recursion, distributed computing or high-end visualization. I guess I'm not really sure what the problem is here: For less than $2k, you can pick up a copy of LabVIEW and save your boss hundreds of hours of your time. For about $5k, you can get the whole dev package and compile things to .exe's for deployment all over the company.

Just my $0.02...

1/100th of 1 bear. By the way, polar bear tastes wonderful smoked over apple wood with a red wine marinade.