- It is not suitable for extremely complicated systems.
- It produces very stable programs.
Just a quick question and comment. I've seen people post about how LabView is very unstable. Like any language, it doesn't make a bad coder into a good one.
Your comment about "extremely complicated systems" has me intrigued and I wonder if you could give your thoughts on what this means. Maybe provide an example along with describing what prevents LabView from being used. Size of the software, execution speed..... Even for my hobby I have written what I would consider some fairly complex programs in LabView and have now abandoned using C to interface with it. It would be interesting to get your perspective on it.
Execution speed - no problem. I know a company which did some fairly comprehensive speed benchmark tests in C or C++ and they reported there was not much difference. I only heard this from the CEO at a NI conference; I had not looked at the result myself and what the code was. I personally have had no problem with speed.
Examples where Labview has "its limits"...
About 8 years ago, I wrote a Labview program to control a semiconductor wafer doping test machine. It drove various NI cards - matrix switches, power sources and measurement cards, and a PID algorithm to heat up a power zener diode silicon wafer anode, insulation foil and qty 525 special Ingun test probes to precisely 72 +-1 deg C using a very long time constant PID algorithm (the anode had a large thermal mass and lag). I would then test and map the characteristics of 525 zeners though a matrix. The results were recorded and various characteristics colour mapped onto multiple Excel spreadsheets, thereby enabling the customer to modify the doping of the silicon according to the characteristic pattern shown the colour map. The Labview code was quite complicated, but manageable with efficient use of sub vi's and putting extra effort into layout.
About 17 years ago, I developed a B2B system in LabWindows/CVI (a C version of Labview). This was really complicated in that customers could put in an order for a fully configurable smart office exchange (Internet, BIR/PRI ISDN, FAX, smart phones/POTS phones, trunk lines for different countries etc) via the Internet. The system would check stock levels, configure the order with all its option cards (build-to-order), instruct the assembler how to assemble it, and then start testing the system. The system programmed in heaps of PGP licences (timed or permanent) to enable different features. Everything would be verified and tracked and a full machine record with serial numbers etc would be stored on a server. The system would then print out the packing list, address labels etc. Any RMA's system would be tracked with a full history, including warranty data. I reckon it was better than using SAP, because SAP does not test systems deep down (and it has a crappy user interface). There is no way one would write such a system in just a G language like Labview. Labwindows/CVI was a great solution. However today, one could write subsystems (eg: test) in Labview and the rest written in .NET or CVI or whatever.
I once did a medical product in Labview (but for the PCBA, I used embedded C). The Labview worked well and was stable, but I was the only one in the company that knew Labview and the driver and runtime libraries were bigger than Texas, so after a few years I rewrote it in C#. Lesson learnt there.
I consider making the community edition will make Labview be used for all sorts of applications though - not just test and measurement.