Tell us about your large LabVIEW applications!

[billings11]

The lastest system I am developing is running final test on laser galvanometers at the end of a manufacturing line. Right now I have just passed 1000 vi's, but I am sure it will keep growing as I still have a lot of work to do. Everything is written in labview, including the tests, GUIs, and the test sequencer. I am using PCI NI DAQ hardware (M Series) along with a couple of GPIB instruments.

The thing I am most proud of about this system is the sequencer. I have a wizard style setup vi that allows a senior tech to setup a final test sequence, along with the parameters for each test. The wizard allows him to actually connect to a real unit and test in real time while he enters parameters, so he knows he is not entering grossly incorrect test parameters as wizard would instantly show a failed test. He can configure the test sequence to be as long or as short as he wants, and run any one test as many or as few times as he wants. He only has to configure the test sequence once, after which it is saved in an SQL server database. I made it as easy as doubleclicking to add a test from a listbox of available tests to a listbox of selected tests. Then the wizard cycles through the tests in a Next or Back style to let him set up parameters for each one.

The test parameters for the elements in the test sequence are saved as an array of variants in an OLE object of the database. Also an array of strings representing the names of the tests in the sequence is saved. When the parameters are read back, the two arrays provide everything the system needs to know to run the test. The test name drives a case loop which converts the variant to one typedef or another depending on the test name. This way we have infinite configurability in test sequencing. It also means I can add new tests without breaking old ones very easily.

Because of the drawbacks of subpanels, I have had to figure out a way to use windows reparenting rather than subpanels to parent any pop-up windows withing the mother application window. This is highly superior to sub-panels for three reasons. The first is that you can denug a reparented vi's diagram as it runs, while you cannot do so if it is in a subpanel. The second is that you can reparent many vis within the same parent window while you can only have one subpanel per vi. You can drag the child windows around within the parent window like an excel workbook within an excel application. The third is that event structures have all sorts of conflict problems if you have an event driven vi subpaneled in another event driven vi. The windows reparenting works very well, as I am using named queues to make event driven interaction between several vi's running in parallel. It is all written in labview with calls to windows API dll's for reparenting. I would encourage NI to look into this avenue instead of subpanels. Once we figured out the details of windows reparenting labview subpanels became obsolete for us.

I handle results the same way as parameters, by saving them as variants in the database OLE object. I chose this because my company has an extremely large set of products with a huge number of custom tests. I also know that there will be new custom tests to add to the existing test framwork, and I don't want to have to continually change the database each time I add a new test. The drawback is that since all tests are saved in the same table as a variant in an OLE object (with a string in abother column to tell what type of test it was), you can't look at individual test metrics at the database level. The advantage is that no matter how many tests I add to the list of available tests, or how many times in a given sequence the same test is executed, I will never have to change the database at all. The only thing I have to do to add a new test is write the test in labview in the framework I have laid out for all tests in the system, and then add it to a case structure in a single sequencing vi. It means in the future adding tests will be a breeze.

All in all I think labview is actually superior to other languages for developing large applications. The graphical nature makes it very easy for one skilled developer to create a very large application on his/her own without having to spend months of planning of every data object. This entire application including the database design has been coded in about 8 weeks, and in one more month it will be in use on a manufacturing floor. I find it hard to believe that anyone who has worked with labview enough to truly understand how to use the multitude of tools it provides for large application develoment could criticise it for lack of large application capability. When you first start using it you are struck with the ease of developing short tests, but the truth is you can develop a lot more than that.

[BenBabb]

Hello all,
I have one program that has about 400 vi's. It started out as a test program for a radio we developed. The speed in developing the test impressed managment to the point the requested a GUI be built,I had a basic GUI for lab characterizations, and we currently send it to customers as the evaluation software. The functionality requirements of the program has increased with each new addition of the radio family, currently there are three different radios being offered. The radio is controlled through the parallel port with an I2C interface. The radio uses the com port for the data over the RF link. The program grew to add a small oscilloscope program using the sound card, all the field represenatives have laptops and are not able to cary bench equipment to customers. It seemed with each new function designed for the radio I was able to easily implement it into my program and repackage it for distrubution.

There are several other characterizations programs that have been written that run 200 to 400 vi's. It seems that more neat tricks and cool gadgets I learn the better, larger( as far as VI count) and cleaner my programs become.
Ben

[P. Jack]

I made an application before that automates our company's spooky equipments. There are about 20 laboratory equipments (for IC evaluation) being controlled to perform various test and characteristics measurements for different ICs. The application includes serial programming of the IC using the parallel port, a USB device and NIDAQCard-DIO 24.

The user can customize a test set-up depending on his needs on certain IC evaluation and the results are displayed in the monitor through charts, graphs and tables. He can print print the results for a quick reference. The results are also saved in excel file (using ActiveX for Office2000 and OfficeXP) where all data (test settings and results) are stored for future references. The Excel file should be readable for the users. And if the future that a certain test has to be repeated for a different IC, the can just locate the appropriate files and load it the application to clone the tests.

This application is built over a thousand subVIs, code interface nodes, activeX invoke and property nodes and a couple of state machines.

The main objective of this application is to be very user-friendly, re-use of its subVIs for smaller applications, speed and accuracy of test and measurement and eliminate man-hours spent on documentation of results.

That was almost three years ago and the application is still in use in our company and is very much admired by our clients.

Today, we are planning to re-make this application to be controlled over the network, produce HTML and XML results, capable of e-mailing its users, monitor equipments' frequency of usage, and integration of more equipments, measurement set-ups, devices and technology.

Three years ago, I developed this one-stop tool for test engineer in our division.

[RPJ]

Hello Michael,

I supposed you asked the question for marketing/R&D reasons. Here it goes:

I used both - common programming languages (Basic, Pascal, Fortran, C) and LabView. However, none of them at high extent; that is, I do not do programming for a living. LabView seems to be very good for data acquisition. However, when it comes to programming things get complicated. For now, the word I have for LabView would be "cumbersome". It takes a lot of time to learn it and a lot of 'gymnastics' to actually program with it; if it wasn't for technical support and forum I would have had terrible times trying to program my first 'large' application.
I am looking into programming a large application right now and it doesn't look good. It makes me think about learning Visual C++ as a better alternative...

Make the training cheeper and you are going to sell LabView better.
Also, when you are selling the "full development" version explain customers that it is not really full at all...or just change the name.

All in all I am excited about using LabView but it keeps giving me a bitter taste.

RPJ (double PhD - if this could give more weight to my opinion)

[LV_Pro]

I've heard the comments about building big applications, how there is some belief that it is easier in other languages, but generally I have found, particularly lately with the various features now in LabVIEW, and hopefully those that are to be added, that it isn't any more difficult. Building a well structured large application is a challenge regardless of the language you use. The problem I frequently see with LabVIEW, particularly how it has been marketed locally, is that there is an emphasis on how easy it is to start working in it, with the sales engineers competing to throw together a basic DAQ system in under a minute. The prospective LabVIEW user leaves, believing they've seen a pretty simple solution to building their automated test system to test 400 various parameters on their products, save the data and have both meaningful test result printouts and beautifully formatted management reports. As someone who then contacts these folks to offer my company's service in achieving this goal I am frequently met with shocked silence when I present a project estimate to them. "What do you mean two months work at X dollars/hr?!!!" Some have gone to the effort of sending engineers to the LabVIEW basics classes, bought the "Full development package" and then months later, with management breathing down their necks to meet the now rapidly approaching deadline, have contacted me for help. Usually what I find is that while they may have a grasp of the basics, it is a long, long way from there to understanding how one structures a large, complex program, regardless of the language. LabVIEW isn't a magic bullet. There are things that are hard or impossible to do in LabVIEW, but these tend to be in the realm of low level communication with unique devices, where a little bit of code written in C or C++ can be used to perform the low level task and can be called from LabVIEW. I have developed large programs in a variety of languages; PASCAL, C and even FORTRAN, and have, by personal choice, used LabVIEW almost exclusively for the last 13 years. There isn't any technical impedement to building large applications in LabVIEW that I've encountered recently (LabVIEW 2.5 might be a different story!) and there is a lot to be said for being able to test most modules in a standalone setting, without building complex test cases for each one.

wire on!

Putnam Monroe
Certified LabVIEW Developer
crusty LabVIEW curmudgeon since 1992

[RPJ]

Looks like you are using LabView for a living...
Wire on!

P.S. I'm glad when somebody else recognizes that learning any programming language takes time.

[RPJ]

However, in a critical note, if your choice for last 13 years was LabView, you might have some surprises when you'll be looking to what the other 'new versions' software can do...

Nothing more on this subject.

[Odd_Modem]

LabVIEW is the most advanced computer language available at the present time. Any other contenders simply fill a niche.

[billings11]

---

I've heard the comments about building big applications, how there is some belief that it is easier in other languages, but generally I have found, particularly lately with the various features now in LabVIEW, and hopefully those that are to be added, that it isn't any more difficult. Building a well structured large application is a challenge regardless of the language you use. The problem I frequently see with LabVIEW, particularly how it has been marketed locally, is that there is an emphasis on how easy it is to start working in it, with the sales engineers competing to throw together a basic DAQ system in under a minute. The prospective LabVIEW user leaves, believing they've seen a pretty simple solution to building their automated test system to test 400 various parameters on their products, save the data and have both meaningful test result printouts and beautifully formatted management reports. As someone who then contacts these folks to offer my company's service in achieving this goal I am frequently met with shocked silence when I present a project estimate to them. "What do you mean two months work at X dollars/hr?!!!" Some have gone to the effort of sending engineers to the LabVIEW basics classes, bought the "Full development package" and then months later, with management breathing down their necks to meet the now rapidly approaching deadline, have contacted me for help. Usually what I find is that while they may have a grasp of the basics, it is a long, long way from there to understanding how one structures a large, complex program, regardless of the language. LabVIEW isn't a magic bullet. There are things that are hard or impossible to do in LabVIEW, but these tend to be in the realm of low level communication with unique devices, where a little bit of code written in C or C++ can be used to perform the low level task and can be called from LabVIEW. I have developed large programs in a variety of languages; PASCAL, C and even FORTRAN, and have, by personal choice, used LabVIEW almost exclusively for the last 13 years. There isn't any technical impedement to building large applications in LabVIEW that I've encountered recently (LabVIEW 2.5 might be a different story!) and there is a lot to be said for being able to test most modules in a standalone setting, without building complex test cases for each one.

---

I very much agree with this statement. now there are two software development platforms that I see as far and away superior to all others for developing large systems: LabView 7.1 and .Net Developent Studio. And of these two labview has a steeper learning curve for someone that does not already have a lot of software experience, and it lends itself to data acquisition and instrument control in a much simpler way. Perhas some people find large application building challenging without direct instruction from NI, but an intuitive devloper should have no problem if he or she is willing to experiment with different aspects of labview functionality.

Many of the concepts I use to develop very large applications are things I picked up through years of experience with labview, not from a training course. I recently inquired about higher level labview training from NI only to be disappointed that there really isn't any. I asked about a seminar or course from NI that would touch on large scale development, and I had specific questions about things like using variants to pass data in an adaptable way or different methods of building a universal sequencer in labview that could have new tests added without modifying source code. I also have all kinds of questions about details of things like heavily using vi server. I learned from NI that there is a course for large application developers that takes place in a different city every month or so, but only if there are 3 people who will sign up. Usually they don't have three people sign up so they end up cancelling the course. One of the problems I think is that the locations of the course were never in any kind of population center. There was one in western PA, one in Colorado, one in either Iowa or Idaho I think, and one at NI headquarters in TX. II think if they had one in San Jose, CA and another in Boston, MA they would have the highest attendance at the two largest technology hubs. In any case, if the seminar came to Boston I would definitely attend.

[drval]

Having been a software developer -- and user -- for over twenty years, I've seen a lot of changes and developments in programming languages and platforms. I've already described by currently deployed application which integrates three out-of-process servers (developed in C++). Right now my task is to rearchitect the entire application, so that I can completely remove the out of proc servers.

The ONLY reason those out of proc servers were constructed as they were was because of the programmer who was involved. He was committed to NOT having LV code throughout as a way of making certain that he would still be "needed" throughout the development cycle.

I wouldn't DREAM of beginning to rearchitect in any other language than LV and I wouldn't DREAM of beginning this project using any other platform. Most of my colleagues/competetitors in the deployed field use C++ as the language and Visual Studio as their environment. A few have migrated to Studio Net but most haven't. I will have this app re-architected and deployed with a very short time -- because of how I can refactor and rapidly prototype using LV.

The development - deploy process would be VERY DIFFERENT and far, far slower it I weren't using LV.