Tell us about your large LabVIEW applications!

[LuI]

Hi,

I know I am late here, but anyhow...
My projects range into the medical and medical devices area. The two largest apps span the whole bandwidth:

1. ECG Mapping:
This is an app to control an examination and DAQ setup, basically to perform 96 channel ECG recordings and to evaluate the results. It is used in the Deutsches Herzzentrum Berlin (German Heart Center Berlin). Its aim is to review the electrical operation of the human heart without the danger of intrusive heart cathether examinations. It measures ECG on 96 places around the patients torso, as well as the exact position of each ECG electrode. From this signals it calculates a signal mapping (voltage level graphs like barographs on metheorological maps) onto a virtual globe around the heart. This is done (off-line, of course) for each sample time. From the movement of the voltage level graphs one can see the movement of the excitement of the heart muscle and its time course. This allows to detect problems like stroke-damaged areas or extra systole sources.
It is about 600 VIs with several dynamically called parts, Needed some new technique (at least for me) for storing large amounts of data, data compression, highspeed multiport serial communication and, last but not least, sphaerical triangulation and displaying techniques. Took about two years...

2. Multiseat test sequencer:
This sounds perfectly like an app for NIs TestStand, And I started with it, but finally gave up after nearly a full year of devellopment. Now I did what we needed with LabVIEW.
The app controls a teststand with two SVGs, a PXI chassis containg two DMMS, two switching modules and some AO and DIO devices and, last but not least, 8 USB ports and 27 serial ports. It is used to test up to 8 medical devices.
Its main VI controls the whole system, starts test processes from templates, gets their results and displays it to the user.
Each single test process is a kind of test sequencer preloaded with an array of steps to perform. This array can be changed during the test process whenever needed (errors, missing components etc). Each test process communicates with _its_ UUT. All access to 'global' ressources is protected by semaphores. Some parts of the process are dynamically called daemeons. Interprocess communication is done using named queues.
The app has more than 650 VIs, Parts of 'em are toolkits or from my private libraries. Took about a year for the LabVIEW part now. Had to learn a lot about using DLLs, exchanging data with C-DLLs, evaluation complex C-data structures, writing multiprocess-safe code, using stacked type definitions etc.
As it is a test system, it is still (and probably will forever) be under construction.)

Greetings from Germany!
--
Uwe

[stoeckel]

Uwe,

I am overwhelmed! Have you already written or do you plan to write an article about your application? It would be awesome! Which sources did you gather your LabVIEW expertise from?

Greetings from german Rhine,
Peter

[LuI]

Peter,

parts of the Mapping project have been reported about in the VIP congress book of 2003. AND there was a handout for the visitors of the 'Lange Nacht der Wissenschaften' 2003. As this is just a tool for the physicians, they might have published results of their work with this SW that I am not aware of..

As for the test solution, this is more or less an internal ptoject. It is (and will probably be) under construction to improve its functions. To publish it would be like comparing with NIs own solutions (especially with TestStand). I am not willing to do so and my employer won't neither.

How to get to the expertise? Reading good books, Trying (& learning from Errors), discussing solutions, taking courses ... It takes time and effort, no question. And I feel like beeing far apart from being an expert.
To recomment some sources:
* www.ni.com * info-LabVIEW * www.lavausergroup.org
And there are some good books:
* j. Conway et al: 'A software engineering aproach to LabVIEW' Prentice Hall 2003
* G. W. Johnson 'LabVIEW Power Programming' McGraw-Hill 1998 (and a 2nd band availabel)
t b c'd
Greetings from Germany!
--
Uwe

[Roine]

Hi Michael,

We all know that it is possible to write large applications in LabView. I have seen it being done myself and we have all read this thread and knows that it is possible. But, I would like to stear this thread into a new direction and that is to identify the problems that where encountered developing all this large LabView applications. I mean problems or annoyances in LabView or the LabView development environment.

When I think of it, I still have the same problems with LabView 7.1 that I had with version 4.0 (that was my first LabView version). LabView has developed in this years, no doubt about it, but the majority of new features are for beginners. I mean things like wizards, express VI´s and things like that. The core LabView application hasn´t changed that much really!

I will try to list a few things that was a problem in LabView 4.0 and still is a problem in 7.1. I know that there are "work-around" solutions to some of the problems, but I have no interest of building my own IDE/LabView system as I think that NI should have done that work for me.

LabView problems:
* There is still not possible to debug a reentrant VI.
* There is still no conditional breakpoints.
* There is still no way seeing variables on the diagram when a breakpoint is hit.
* There is still an awful icon editor.
* There is still no good way of entering code comments without cluttering up the block diagrams with lots of text.
* It is not possible to search VI only present on disk and not in memory.
The above points are just ontop of my head, there are a lot more if you come to think of it. There are also code bugs and problems, but I´ll leave these for now....

Enviroment problems:
* It is still difficult to use a VCS system as LabView constantly recompiles VIs (marked with a * in the titlebar) making it hard to know what to check in to the VCS system. For example paths to VIs used between different developers might not be exactly the same or simple things like a subvi used that might not have same revision for all developers.
* LabView searches for missing VI´s in hidden folders that makes a VCS system like CVS or Subversion hard to use as these programs makes use of hidden folders to manage itself.
* The diff tool are only availible in the professional version of LabView and it is (what I know of) only availible from inside LabView, making it harder to do compares from the VCS system of your choice.

If it wasn´t for GOOP developed by Endevo (I am still using 2.02) I would NOT concider developing large applications in LabView at all with a large team of developers! LabView is good, but the direction for the past 10 years has been for beginners and NOT for more advanced developers.

/ Roine Stenberg & Henrik Toräng

[tst]

Roine, just a remark.
Admittedly most of your points are valid (why not use a conditional probe as a conditional breakpoint?), but they're irrelevant to creating large applications (at least the first part). It would definitely be good if LV got more "general" and included some more large scale development tools. I think 8.0 is supposed to have project control of some sort, but I don't really know anything about it.

[JanK]

Roine

A comment regarding the environment problems and version control. I have succesully used ClearCase in projects involving several developers. We set up the environment to ensure paths would not be modified if a new programmer opened a VI. I am sure this could be done in CVS too. It just takes some dicipline. Everyone had the same search paths and worked in identical file structures mapped to the same drive.

Regards,
Jan Klasson
www.endevo.se

[Jim_Kring]

For doing differencing in LabVIEW you can use:

1.) LVDiff, an open source tool available for free
2.) LabVIEW Version Chooser, a comercial tool available for purchase

[Roine]

Tst:
I think that at least some of my points are valid. Large applications (with a few developers) needs better debug tools and work environment than a small application, but the tools to do this are not availible in LabView as most new features are geared for beginners. Where can I read about the upcomming features in LabView 8?

JanK:
We have done the same as you suggested. Every developer has 100% same environment and the same paths. But CVS has one more problem. It uses several hidden folders inside your project to store the orginal checkout copy. If you decide to remove a VI in one folder and then opens another VI that uses the removed VI you will not get the broken arrow as LabView will search and find the orginal checkout file in the hidden folder. This can create a mess. I am working with Starteam in the current project and then things are just fine. But development with with the two major open source VCS systems (CVS and Subversion) are a little more difficult.

Jim Kring:
I did not know about LVdiff, thanks for the tip! But I can´t use it as I am only using the full version of LabView. LabView Pro is to expensive to buy if you are only interested in the diff tool! It should be availible for ALL versions!

I think that a new tread should be started by NI where anybody can post suggestions for new LabView features! This would benefit everybody!

/ Roine

[Jim_Kring]

---

@RoSt wrote:
But CVS has one more problem. It uses several hidden folders inside your project to store the orginal checkout copy. If you decide to remove a VI in one folder and then opens another VI that uses the removed VI you will not get the broken arrow as LabView will search and find the orginal checkout file in the hidden folder. This can create a mess. I am working with Starteam in the current project and then things are just fine. But development with with the two major open source VCS systems (CVS and Subversion) are a little more difficult.

---

I think that you might be mistaken about what's stored inside the hidden CVS folders. These only contain meta information about the files that CVS knows about, for example the modification date and repository location. To the best of my knowledge there are no duplicate copies of the "original checkout file".

My experience with CVS and Subversion have been very good. The only problem, is getting up to speed on the fact that you can't just move folders around, because the hidden CVS folders will cause you a world of grief if you accidently move them around.

Also, you can't just delete files in your sandbox. You must remove them using the cvs remove command. This will cause the CVS client to delete the file on disk. If you only delete the file, then it will reappear next time you do a cvs update.

Regards,


-Jim Kring

[Roine]

I´m not mistaken Jim. We had problems with this in the last big LabView project. You are talking about removing a file from the VCS system, I´m talking about remove or rename of a file in my sandbox, where I can do anything i want before a commit. LabView will then find the file in the hidden folder.

I don´t remember that much more the problem as it was about two years ago. But it was a real problem for the development team at least!

/ Roine