Tell us about your large LabVIEW applications!

[billings11]

Brittner,

When you use local variables I believe labVIEW creates duplicate copies of the stored data in memory.  So if you have a 1000 pt array and call 10 local variables of it, you will end up allocating memory for 10,000 data points.  Try using property nodes instead.

Also, in an above post you said "there is nothing like object oriented classes".  This is not true.  There are many easy ways to create objects and classes in LabVIEW.  Do you know how to use typedefs in your labview code?  You can use typedefs of clusters to create the equivalent of c++ structures.  You can create subvi's with these structures that contain a while loop with a shift register containing the data.  These are sometimes called functional global variables or FGV's.  These have limited use, but you can also have something similar to FGV's that accept action commands and actually can do operations on the data fields based on a command.  You are in control of everything, and you can certainly have all the power of c++ classes.

I think the true beauty of labview is that you should never have a project that takes 10 man years of labor.  I've never seen one taking more than about 2 man years, 4 skilled large application developers should be able to finish developing the most gigantic project in 6 months what it would take four visual basic developers 10 years.

Part of the problem is that there is not easily accessible training for large application developers.  Indeed, it does concern me a lot that NI seems to be pushing more toward simplistic student oriented features like express vi's (useless outside of a college lab) instead of focusing on expanding the power of labview as a complete programming language capable of handling large applications with very rapid development.  Event structures really revolutionized labview for large applications.  They need to keep working in that direction.

You are right, they could definitely use a project manager that organizes and also tracks subvi changes.  Also, the application builder is far too simplistic and dumbed-down.  They need an advanced application builder that gives me much more power.  They need a windows connectivity toolkit that gives me better access to environmental variables and lets me reparent windows.

But still, LabVIEW offers by far the most cost effective and fast solution, and has all the power necessary to build very large applications.

[Odd_Modem]

Well, there are plenty of ways to write LabVIEW in an object oriented style, and really, there is a baseline for what one calls object oriented, and that is Smalltalk. I don't think anyone uses Smalltalk today, because of the late binding. I had the unfortunate experience of trying to interface to an ActiveX object that used late binding exclusively, and not only was it difficult to program in LabVIEW, compared to regular ActiveX controls, but I simply abandoned the project because the code looked like an abomination. Object Oriented was developed so engineers could re-use the bits and pieces in other projects without too much trouble. A lot of C++ I see in production is object oriented, but no one would reuse it, becuase the master paln design step was never taken, and the code is bonded too closely to the problem at hand. It is easy enough to reuse LabVIEW code without calling it OOP, after all, -I- have a few 100 Megs to draw on!

[Otman]

I'd like to give my two cents regarding issues/concerns brought up by previous writers on the use of LabVIEW as a large-scale application development language and making the language more powerful from a programmer's point of view. First and foremost, LV is not a "tool", it's a programming language. Big difference between the two terms. Second, it's nice to have all kinds of fancy programmer's bells and whittles, but in my own humble opinion, I think they're not necessary since LV intended use is measurement applications, and as long as you're productive developing them, then that will suffice for its target audience, scientist and engineers. And as such we want to focus on speed so we can get to answers to our scientific/engineering questions faster. If you're developing applications for a mass audience (here you're probably a professional programmer's which most of us are not), that's another matter where text-based languages with their IDE's are more suited for such tasks.

Just my opinion of course.

Otman  

[PJM_Labview]

Hi Billings,

You said: "Also, the application builder is far too simplistic and dumbed-down.  They need an advanced application builder that gives me much more power."

You should really try the OpenG Builder, it has a lot more features than the NI Application builder and is truly a great tool. You can get it through the OpenG Commander.

Best of all, its free.

Regards

PJM

[LV_Pro]

In response to Otman, the original target audience may have been the engineers and scientists who needed to automate the taking of measurements, "in the Lab", but that, as the language, has evolved. At NIWeek 2005 the message was that LabVIEW's intended domain was going to grow to encompass most of engineering, with tools to develop FPGAs (beyond the basic ones available now), to run on almost any mProcessor, system simulation tools, and a great deal more. While I would guess that the majority of LabVIEW applications are still aimed at data acquisition, the big systems do a lot more than make a reading and store the data. The interfacing of the data acquisition, manipulation, display, storage etc., is driving the additional tools. There are a growing number of projects that may not ever interface with a data acquisition board, GPIB enabled device, etc. and may be entirely devoted to manipulating user input and producing output in the form of data (VHDL code for the FPGA's for instance). Also at NIWeek they gave us strong hints that the next version of LabVIEW will have more of a project oriented thrust, with features that will help in that regard, rather than the dumbing down that the last major (7.x) release gave us, with those diagram side icons that made our LabVIEW look like, ... VEE.  If nothing else they take up way too much real estate on the diagram and make it impossible to neatly wire more than one control to a sub-vi! Admittedly, NI has added a bunch of "tools" for the "newby", without a doubt to ease their initial entrance into the world of LabVIEW, but in discussions down in Austin it appears that they are recognizing the need to help those of us that may be developing projects bigger than 20 VI's, with teams of programmers.

P.M.

[billings11]

LVPro,

I am very glad to hear that news.  You are right, the audience for my code is not just engineers and scientists.  It is technicians of all skill levels, adminstravtive workers, sales associates, managers... pretty much everyone at my company will use my code in one form or another.  Originally I set out to automate testing on a manufacturing line, but it has grown to encompass applications to organize and view test data, view RMA activity, link to sales orders, etc all packaged together.  Even without all those other tools, even if it was just a manufacturing test application, my code would easily top 1000 vi's in a single labview application.  None of them are express vi's, by the way.  It's not just test and measurment, its database utilities, report generation, test setup wizards (with back and next buttons) that I coded in labview.  Its all kinds of options to print graphs and save graph images to Jpegs, write all different kinds of files, pass data with all different typedefs for different tests in the same communcation structures in labview.  Its being able to build an application and distribute an installation remotely to a dozen PC's, with command line switches and no GUI required.  It's being able to give technicians toolkits with reparented draggable windows inside the tope level front panel window, containing things like function generators, spectrm analyzers, scopes, meters - replacing all that hardware on their bench.  Labview is great for writing those things, now lets get some more functionality to integrate them all together.

If NI gets all of that stuff up to par with any other project based software language package they will really extend the usefulness of labview as a language.  I am really looking forward to the next release.

[fliyer]

Our typical application is 400-500 vi's, we have to be very precise about memory management limiting the number of global variables and so on.

[K C]

Reading the title of this thread, I asked myself: what a large LabView application is. Can it be measured by the number of VI’s or the time you spend making the application or …?

My first introduction to LabView was a demo with version 3. After this introduction I made my first application with LabView 4. A tester for a small PCB with a microcontroller we produced for one of our customers. The tester, with a bed of nails adapter, was build with SCXI modules.
Not enough time to do things the right way and little knowledge how to make a good LabView program. Afterwards I think I did al lot of things the wrong way but the tester was in production for a lot of years at the company where I was working at that time and still is by someone else.

During last 10 years I made a lot of LabView applications. Large and small ones.

Currently I am working on a Go-No-Go tester for about 30 different safety modules. (See http://www.yokogawa.com/iss/products/iss-en-prosafe-sls-plc.htm: ProSafe-SLS)
Each module is one Euro-PCB with a 48 pole DIN connector. With only e few standard signals.  The tester is build with a PXI rack with a DMM and Matrix-switch (66x16). The Matrix-switch is used to be able to test all the different modules with one UUT connector. Also some boards from the ProSafe-SLS modules are used in the tester.
The tester must be useable in a factory environment and give the operator enough information about the found error. The test-program for a module is a plain text file (test-script) with commands for the tester. The LabView program executes these commands.
In short: The LabView program must translate the commands in the test-script, set the Matrix-switch, communicate with the SLS board (Modbus), take the measurement, and decide about Go or No-Go.
Is the LabView application large? It’s about 200 VI’s and it took me about 6 months to build everything (hard- and software)

I am still very enthusiastic about LabView. When I have to program something (at home or at work) I use LabView.

[DavidMundie]

I have an application that is a full web based backend that gets data readings from remote units via email with binary attachments and sends command to remote unit via email as well.  Each site has a custom web page and a custom vi that monitors that sites data and provides a graphic representation of the current data.  Customers use a menu based web interface to request excel reports (generated in LV, and graphs of data history generated on requiest using about 100 CGIs all writen in labview.  There in on main message processing VI that receives the email messages extract the data and operates based on the contents.  About 40 vis monitoring data files looking for changes generated by the message processor that update their front panels. and 100 or so CGIs.  We us the G-Web server obviously and upon request we set up password protection for access to the customer site and allow him to manage his own usernames and passwords again via CGIs and html forms.

In effect this is a web based virtual scada system for customers that don't want to invest in a stand alone scada system.

Typical customer site looks like this:  www.httscada.com/rcud

[TerryR]

I can't figure out how you count the # of VI s in the first place.  And is a large application based on the number of I/Os and calculations?

My first application was a system controller with only 32 DIO 15 Analog In, 8 Analog out and 4 rs232 ports (2 streaming data in and 2 pull/response mode) and datalogging.  Among the other calculation and charting I would only consider this a small to medium application for LabView.  I am guessing 50-60 VI s

As for its performance is it is big,  Development time under 3 months. 

(Development time would have been less if more time was put into the requirements up front.)