Tell us about your large LabVIEW applications!

[Ben]

Hi billings11,

YOu wrote "There was one in western PA, one in Colorado, one in either...".

My boss (CLA #5) is one of the few people who are certified to teach those courses.

Western PA is where I am headquartered.

Contact me off-list if you think you can come up a bunch of people who are interested in the course.

WARNING: Shamless plug follows.

We have also developed a bunch of modules that basically pick-up where the normal training leaves off. These have been organized as 1.5 hour presentations that discuss a lot of advanced topics. My favorite was "Fun with Graphs and Charts". If you do not have the time to stay on the top of discusions on the Devloper Exchange, they can be a good. We will also show the the source code that I am not permitted to share in this forum. We are planning fee based web-inars if we can get enough people to sign up.

Done with plug!

I can be contacted at

bar@dsautomation.com

Ben

[shoneill]

LV_Pro,

couldn't agree more.

Shane.

EDIT: A Name change would still be good though. LabVIEW has attached such a stigma over the years it nearly makes me mant to cry..... 😞

Message Edited by shoneill on 05-20-2005 03:38 PM

[Ben]

Shane wrote "A Name change would still be good though."

I could not agree more!

There are many non-math and science types that cringe when they hear the word "lab".

Ben

[JanK]

Hi Michael,

One of our projects has been going on for some years. Several developers are involved in the project and they are still working on the project. It is a platform for system tests.

All platform code is built in GOOP, using the original GOOP Wizard 1 developed by NI-Endevo.

There are 195 classes. We counted almost 5000 VIs but all classes where not loaded at that time. Although GOOP does add some extra VIs (class helper VIs) I guess this qualifies as a large application.

To cope with large applications it is necessary to have some means of structuring the application. GOOP is doing an excellent job here. Could we have done this without GOOP? Everything is possible, but I wouldn't like to try.

With GOOP we got the means to create structure, this enables us to continously add new functionality and still be productive and maintain good quality. With GOOP we could partition the platform functionality into several components which enables the user to select what functionality to use and intialize when using the platform. We also got the means to divide work on project members (one or several classes per person). You cannot do big-bang testing on an application like this, with GOOP we got small code modules which enabled us to do unit testing before integrating the application.

So, is LabVIEW suitable for large applications development? Well, there isn't much specific support built-in, but with the GOOP extention it definitely works fine. One feature which I think cannot be overestimated is the ability to run and debug each single VI as soon as it is written. This really supports incremental development! It also saves us from writing a lot of test code. Otherwise you can easiliy write the same amount of test code as application code.

Thanks,
Jan

[JanK]

Hi Michael,

One of our consultants (Mikael Holmström) has written a graphical editor in LabVIEW. Writing a graphical editor isn't the typical LabVIEW application. In a graphical editor you should be able to handle individual graphical objects, get context help, configure the graphical objects etc.

The tool is a UML Modeller for Endevo GOOP (UML is a standard for graphical systems design, check out www.uml.org and also www.endevo.se).

The tool is built in 100% LabVIEW and structured using Endevo GOOP Wizard 3. Current code count is 36 GOOP classes, around 700 method VIs (probably around 1000 VIs in total although we haven't counted). Large? Well, it is not small anyway.

GOOP as a way to structure the code is very suitable for this kind of application. Why? Well, in a graphical editor you need to handle a lot of individual graphical elements, move them, add them, resize them etc. Each kind of graphical element is naturally modelled as a GOOP class. Although the "things" you like to do with each graphical element are conceptually very similar (move, add, draw, resize etc) the implementation will naturally differ (drawing a circle is different from drawing a line). So, how do you cope with this?

We used a feature called inheritance (avaliable in Endevo GOOP Wizard 3, sorry for the tools promotion). Inheritance enables the structuring of GOOP classes into inheritance hierarchies. It also enables adding the same method (like draw) to each class but you can implement them differently on each class. In addition, inheritance will let you pass objects from an inheritance hierarcy around and also use them without knowing which class they where created from. For example, you can create an array of object references, to redraw all objects you just call method Draw() on each object. One of the objects could be a circle, so calling Draw() will cause a circle to be redrawn. Another object could be a line, so calling Draw() will cause a line to be redrawn.

The benefit with designing using inheritance is that you can add new features, like in our case a new kind of graphical object (it will be a new class in the inheritance hierarchy), and still not have to modify more than a small portion of your application. Most code is untouched by extentions to the application.

GOOP and also with the addition of inheritance are important for large applications development. Although this example is not the typical LV application, inheritance can be a very useful technique for designing extendable LV applications.

Could this tool have been built in non LV environements? Definitely, but Mikael wanted to see if it could be done with GOOP Wizard 3. It could:-) Could it be done in LV without GOOP and inheritance? I wouldn't dream of trying.

Thanks,
Jan and Mikael

[JanK]

My two replies where a bit anonymous.

I am Jan Klasson of Endevo.

[PaulG.]

Our company manufactures ultrasonic test equipment. My specific LabVIEW and IMAQ application is an ultrasonic test immersion tank with data acquisition. With LabVIEW we control 6-axis of motion, a 35MHz pulser/reciever and a 'scope card (2GS/s). One customer scans metal discs up to 18"/dia, 1" thick at scan increments of .02" at 8"/sec. The program contains over 500 vi's. We measure and acquire amplitude, time-of-flight and phase inversion for up to 8 data gates. We can also perform flaw/pixel measurement and analysis and report generation. Currently working on "next generation".

[Mads]

Shane wrote "A Name change would still be good though."

Hear hear!

I would prefer the use of "G", or a derivative of that. Get rid of all the lab references, it is way too narrow for the use of G.

I think they should stop using Virtual Instrument as the name for the code files as well, a VI is very seldom a virtual instrument, it is a function.

[LV_Pro]

Unfortunately, despite National Instruments refering to the underlying language as "G" for as long as I can remember (Fall '92) others have co-opted the name for a Java based programming language, leaving us with, perhaps "Gee" ;-). LabVIEW, strictly speaking, was defined in days past (by NI) as the development environment for working in G (Gee?)

Regardless of what it is named, the add on tools and built in features are making LabVIEW an incredibly powerful environment to develop in. No, it may never be the optimal language to build the next spreadsheet, but to design, develop and deliver an FPGA based, intense control system? Try it in VB. I have worked, right along, in other modern languages, some obscure obsolete ones and others that really are just GUI development environments, wrapped around VB or C, and my preference remains LabVIEW. And if you think it is kool and intense now, just wait ...



Putnam Monroe
LabVIEW curmudgeon since 1992

[tds.wells]

I built a test executive program in LabVIEW 2.0 more than 10 years ago (before Teststand was developed). I have more than a dozen test systems running functional test in my operation. Each of these systems has 250 to 1000 subVIs. The test systems archive test data over the network to a central file server. The data can be parsed and various reports generated using executables deployed on any remote computer.

The transition from HP Basic and Tek Basic to LabVIEW 2.0 was difficult at first, but once you get the hang of LabVIEW it gets easier and easier. LabVIEW 7 is significantly more powerful and tasks are much easier to complete.

I don't know what constitutes a large application, but I could easily see instalations 10 times larger (thousands of subVIs).