Large applications - Labview and other programming languages

Question

Hello Labview Users,
as the forum saw this very interesting thread about large applications programmed in Labview
(see: http://sine.ni.com/niforum/niforum?requireLogin=False&forumDU=http://forums.ni.com/ni/board/message?... ) I would like to ask the community about their experiences with Labview applications in combination with other programming languages.
In advance: I have several years of experience in programming Labview applications starting from quick-and-dirty solutions which had to run within few hours and complex test solutions. I saw Labview growing and becoming better with the released versions and lot of things I missed in former times got implemented in the meantime. Actually I have to develop a complexe ATE solution with numerous equipment to control and numerous data to be captured and archived. Despite the Verison 8 I still feel still some drawbacks of the LV concept which let me hestitate to setup the solution completly in Labview:
1) It is alway hard to re-use code of complex applications since it is not possible to do some kind of global search an replace of functions
variables etc. It nearly impossible to re-use approved code structures (e.g a state machine) if the "inner part" is changing more the a little bit.
2) If the application requires a certain flexibility (e.g. exchangeable test equipment of varying vendors) this is hard to implement since you have to define a lot of parameters through your hierarchy if you dont want use global variables which slow down your application and hide
the code functionality.
3) Despite modern PCs the look and feel of LV applications appears somewhat slow compared to other applications. For complex user interfaces the polling methode generates a lot of complex code. (I dont have expierence with the event-structure).
Now my questions:
Do you have experience of implemention of complex solutions dividingthe code modules using Labview and other languages? Which other
languages did you use? Why did you use these languages (speed, flexibility of text based code, available library functions)? Did you found out this to improve your development time and code maintainibility?
(I concider a solution where I do the single tests with Labview-VIs but delegate all the test sequencing and data collection stuff written in PERL which allows really very compact code)
I'm curious what your experiences are.
rainercats

Answer 1

Given that you're asking these questions in a forum for LabVIEW users the opinions given are going to be somewhat slanted towards the general like of LabVIEW. I've been working with LabVIEW for a long time, ever since 2.something on a Mac. I've written numerous large-scale applications as well as "mundane" instrument drivers. As you've noted you're experienced with LabVIEW, so you know some of its strengths and weaknesses.
To address your specific questions:
(1) Yes, that has always been a limitation in LabVIEW, but I don't believe it is an overriding one to choose C over LabVIEW. Putnam provided one workaround for the search and replace of VIs. Once you've programmed in LabVIEW long enough you get used to doing it this way. Is it clumsy? Yes. As for the re-use of code structures, that's not entirely true. You can create a "template" VI (a regular VI, not a .vit) that contains the code you want to re-use and place in your palette with the "Merge VI" option set. That way you can select it from your functions palette, plop it down on your diagram, and you get the "template" VI's diagram placed right into your new VI.
(2) This is not something that is specific to LabVIEW, as this exists with any programming language. It's not the language that limits you here, it's how you've designed your code. In a language like C++ you would go with classes. You can do the same thing in LabVIEW. IVI is another option (though not preferred by me).
(3) As Putnam mentioned, you should be using the event structure.
Other thoughts:
The biggest strength I see with LabVIEW is that each VI is a miniature program, which allows development and debugging of functions a snap. With a language like C you have to write another program to call that function in order to debug it. The biggest weakness? I would say user interface. Yes, even with the event structure. Don't get me wrong, the event structure has vastly improved the way user interfaces and event handling in general are done with LabVIEW, but it simply doesn't hold muster to a program written in C or VB. ActiveX anyone? LabVIEW still doesn't do ActiveX properly in terms of actually getting the controls to work. Programming ActiveX controls is just plain aggravating what with all the property nodes taking up so much diagram space.
It certainly makes sense to use the best tools available to you to get the job done. In my recent projects I had to write software to run automated tests on some products my company made. The test modules were written in LabVIEW. The tests executive was a proprietary engine driven by a SQL Server database. I had to write a "wrapper" DLL that interfaced between the LabVIEW code and the executive since the executive hadn't been designed to call LabVIEW DLLs directly. This allowed us to use LabVIEW as the preferred language for developing the test modules and let the guys who were fiddling with the test executive do their bit. Of course, TestStand's premise is basically that.