Tell us about your large LabVIEW applications!

[spaceman_spif]

tbob, I would have to say (IMO) the biggest disadvantage to LabView is that I find it very non-intuitive for those seeking the self-taught route. For example, something as simple as changing background and text colors on a tool, you would think there would be a "property" option for that or a "options" for that tool to change color. But holding the shift key and right clicking the mouse button? Who'da thunk it?

Yeah, my program is enormous. And looking back, knowing what I do now, I now see how I made parts of it so much more complicated than they needed to be. Of course, every time I put my program to work on the floor, someone eventually finds an oddball way I never dreamed of to make it lock up. And it's back to the drawing board!



The biggest advantage to LabView (IMO) is the huge library of examples you can look at. That's been a great help for me in programming in LV!

[Roshan]

Man, I have become so depentdent on labview that I convert my excel files to .dat file and use labview to operate on the data instead of the Macros from Excel. crazy huh?

[waldemar.hersacher]

I'm rewritting a LV 6.0.2 app in LV 7.1.1 taking the advantage of events and making it more modular and expandable.

One part is a driver layer for the security testers of my customer. This driver consists of by now of 60 VIs and CTLs. This driver is deployed as Active-X Server, DLL and LLB and also used in the main application. This driver is acompanied by help in CHM and PDF format for the programmers. I also created some VIs and CMD files for automatical build. The driver is not complete by now. It misses the private functions for firmware update and setting internal parameters. It will expand by another 25-30 VIs for the driver and 2 apps.

Another part is the main application which now consists of 8 kernel modules builded by 375 VIs and CTLs. These modules are not all ready. I'm expecting to get another 100-180 VIs and CTLs. Missing by now are another 12 modules each expected to be 20+ VIs and CTLs. Together with them a programmer reference is builded. Each module is located in one LLB. There are more than one implementation for one module. As long as the interface of the module builded by CTLs and fixed named VIs aren't changed the modules can be exchanged. All the modules will be automatically build by some VIs and CMD files.

These two parts are now aimed for Windows but there are plans to get them running on Linux too. We have made some investigation and found that we need only a limited number of functions differently implemented for each platform. We will expand our build process to have the work and testing done on Windows and include an automatic build on Linux. The Linux version is aimed to run in an embedded PC of an automated test system in a light or full version. We need to rescale and rearrange the UI of the Linux version during the build process.

Another part is a custom installation routine to enter some registry information and doing a first configuration of the application when the end user installs it on his machine.

Also there is a plan to build a deployment application. This will automate the process from getting the right modules from a master layout to the the CD the end user is buying.

The problem of measuring how large an app is appears not only in the number of VIs and nodes. This is only the sight from the programmers state. Its also related to the number of steps you need to build it from the sources. And its not only the EXE and LLBs its also the programmer and end user information.

[RobCole]

We have developed a Hydrogen Fuel Cell Test System that includes 2 parts.

On the RT system where the safety system and test sequencer run along with an Instrument Manager, DAQ, Data Logging, DI Monitor, Watchdog and a few other parallel processes - we have currently 1027 VIs (not counting some that are dynamically loaded).

The GUI on the computer side has a little over 600 VIs. There is also a configuration system that contains a little over 200 VIs.

This program is managed in Perforce and is built modularly, so that a number of sections can be used, tested and managed separately. Testing a build in this software suite takes a while. There is an extensive test document to go along with the scads of design documents.

There are a number of "common" code modules that have been used in other projects as well.

If you're wondering, this program has been developed over about 5 years and is being rebuilt to use DAQmx.

You can see some of our projects at: http://www.advmeas.com

The ONLY way to build something this complex in any language is to do a lot of design up front.

Rob

[shoneill]

Roshan,

don't worry, that's not crazy. It's simply a more convenient way to do it. It's not that it's really hard to do it as an Excel macro, it's just that LabVIEW is so darn easy.....

Oh, and I do that all the time too (Replacing CR with CR/LF and so on.....)

Shane

Message Edited by shoneill on 05-09-2005 10:00 AM

[rfriedr1]

Hi,

I've designed I LabView program to evaluate gas-chromatographie-spektra. It does a lot of calculations a plotting data.
It needs about 50 suVI's and saves many (many many...) "Excel-klicks".

In the moment I'm about to write a program to control a mass-spectrometer and the preparations line for water-samples.
That means I have to control various instruments, e.g.
- Quadrupol masspec
- Cryogenic coldtraps controller
- valve controller
- pressure gauges
- digital multimeter
- countercard
- magnetic-field-controller ...

First you have a water sample that should be processed in a preparation line and after that measured in a mass-spectromter.
All between should be automatically done by LabView with a high amount of flexibibility to process the sample.

Of course storing the measured data and designing a usefull Userinterface is another point.

I estimate the final number of VI's to 300-400.

Regards.

Ronny

[Fire]

Hello,
I would like to mention our Control System (CS)-framework.
http://www-w2k.gsi.de/controls/CS/cs.htm, developed at GSI, http://www.gsi.de.

- It is supported on LabVIEW for Windows XP, Linux and LabVIEW RT.
- It includes more than 80 classes with about 4000 VIs.
- It is object oriented, event driven and network distributed with SCADA functionality.
- Executables can be build with the LV application builder.
- It is published, documented and downloadable from our web site unter the terms of GNU GPL.
- It is in production at 6 experiments.
- It is running with LabVIEW 8.0 Beta 2!
- More experiments are planning to implement their control systems based on the CS-framework.

Regards Holger

[Jim_Kring]

Holger,

The OOP framework you are using looks very nice. However, the GPL license effectively prohibits the use this framework for proprietary applications. Has your group considered the LGPL instead?

Regards,

-Jim

[Fire]

Hello Jim,
thanks for your interest in our CS-Framework.

I proposed the CS-Framework as open source project for the LabVIEW User Group Central Europe e.V., http://www.lvug.de, in the LVUG discussion forum. German language is used in this forum. But you can try to convince us with good reasons to switch to LGPL.

LVUG Discussion forum: http://forum.gsi.de/index.php?t=msg&th=431&start=0&rid=8&S=a0cd750bcc4fbce321f012ee4861d158

Holger

[Ray.R]

---

@Spaceman spif wrote:
Yeah, my program is enormous. And looking back, knowing what I do now, I now see how I made parts of it so much more complicated than they needed to be. Of course, every time I put my program to work on the floor, someone eventually finds an oddball way I never dreamed of to make it lock up. And it's back to the drawing board!

---

Hey Spaceman...

don't be so hard on yourself.

Most people write enourmous LV vi's at first.
Then one day.. they see the light. They discover the power of the sub-vi.

I would cramp up so many functions within a vi, that it was nearly impossible to follow the wires, as they were tightly placed together (like a circuit board 😉 ).

I started using sub-vi's as sub-routines. For each little task, a sub-vi. Then I started re-using the sub-vi's.

Now large vi's consist of wires and sub-vi's (which also contain a bunch of sub-vi's).

Have fun in space!!! among the friendly wires...

😄

JLV