LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Large applications - Labview and other programming languages

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
 
 
 
0 Kudos
Message 1 of 4
(2,893 Views)

This is a topic that has come up frequently over the years. I will attempt to answer the three main points for the purposes of this thread.

1) Depending on what you are refering to about it not being possible to do global searches and replacement that isn't entirely true. One, if you have controls, indicators or constants based on a type definition, they will be updated throughout all the vi's in memory if you modify the type def. Two, if there is a function being used in many places throughout your program, clicking on one instance, and then doing a "save as" will cause that new named vi to replace all the ones currently in memory. You can then modify this new copy, or, closing labview, copy your new vi that was possibly created earlier, to the location & name that you just "saved as", thereby replacing it. Of course it will require that you have the same connector pane layout.

2) I'm not sure what other languages give you any additional flexibilities, but one "trick" in LabVIEW, for instruments in particular, is to encapsulate the instrument functionality in a type of sub-vi sometime called an "Action Engine", which is basically a case statement within an uninitialized shift register (a "LabVIEW2 style global"). Each case of the case statement contains one function, i.e. initialize, write, read, close. The various setup information is stored in shift registers in the while loop, so that this info is modular with the vi, doesn't have to be wired throughout the heirachy.

3) Learn event structures, they make the old hardship of polled user interfaces vanish, and provide a lot of other flexibility. There have been other threads addressing benchmarking applications written in LabVIEW and other languages. There are probably things in C++ that may run a little faster, but LabVIEW, when run, generates compiled code that is generally comparable to the others. If there is some little function that LabVIEW is slower, then it can be written in the other language and linked to, by CIN or dll, etc.

I have written large applications in other languages (Pascal, C, HPBasic) and will not consider doing one in another language than LabVIEW at this time without some really overwhelming reasons (sometimes that is all the customer will allow)

 

 

Message Edited by LV_Pro on 05-29-2006 01:13 PM

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 2 of 4
(2,872 Views)
First, I must add the disclaimer that I am an NI employee and that my fellow employees may disagree with me.

I have written and been involved with several large LabVIEW applications, both using and not using external code.  My experience has been that using external code is generally not a good idea unless you really need it for a specific purpose.  In particular, debugging a LabVIEW/(C++, perl, C#, pick your language) application is much more difficult than debugging either LabVIEW or the other language.  I would recommend you stick with one language or another.  As LV_Pro's reply shows, there are ways to handle the large program issues natively in LabVIEW.  I have never had to use another language due to program structure limitations in LabVIEW.  Most problems are due to lack of knowledge.  Unfortunately, the right way to do something in LabVIEW is not necessarily very obvious.  There is usually more than one right way, as well.  Keep posting here and we will keep trying to answer your questions.

That said, I have had great success using specific, well debugged, tools from another language which supplement LabVIEWs capabilities.  Emphasis here is on "well debugged."  The necessity of this is reduced with every version of LabVIEW, as it gets more capabilites.
0 Kudos
Message 3 of 4
(2,825 Views)
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.
0 Kudos
Message 4 of 4
(2,817 Views)