using labview for everything

[Stocklone]

I am a programmer supporting scientists in research.  Someone is pushing to have everything done in Labview.  My problem is I don't think Labview is a good fit for everything we do around here.  I think for simple applications it makes sense to do it in Labview.  You hook up a device, get the data and write it to a file and maybe display the results on a graph.  But if someone wants something much more complex, I think it makes more sense to be able to do it in CVI where it is going to be easier to manage and more flexible.  In my experience, trying to get labview to do things it wasn't specifically designed for is a huge hassle with ugly looking code.

Another problem I have is that by doing everything in Labview is you will have a bunch of people who think they know what they are doing since Labview is so easy to pick up.  This will lead to anyone being able to muck around with anyone elses code.  They are scientists not trained programmers.  It takes a lot of work to get really good at Labview.  I talked to a guy at convention who wrote nothing but Labview.  He said that he would have no problem with customers trying to program it themselves.  Because he would just wait a month for them to call him back and ask him to do it because they messed everythign up.  It takes a lot of work to be a really good programmer.  If Labview could allow anybody to do anything very easily why in the world did I go to school for 4 years to become a computer scientist? 

I would appreciate any comments on my situation.  I need to make a strong argument so I don't get in a situation where I really need CVI but am not allowed to use it for a project it makes perfect sense for.

[mvr]

I can not give you an argument against using LabView but there are a few points to consider:

- While at one time LabView was not suited to large projects or group development work NI has greatly improved the tools available.  However for large projects there are still far more third party tools compatible with CVI or VC.

- LabView really shines for data flow oriented programming, particularly things like basic FPGA based development.  It is only just now gaining the capabilities to really handle event driven programming models and has no advantage over C for more conventional procedural programming.

- LabView takes care of  memory management for the programmer.  This good until you need to do something that manipulates memory in a fundamental way, then LabView gets in the way.  C lets you drill down to virtually the assembly code level,  it is not as easy in LabView to do a similar thing.

- LabView is a natural for EEs who use schematic based design tools.  But as you pointed out, it does not make them a programmer.  LabView avoids a lot of the syntax issues related to text based programming and so is easy to use "non-trained programmers" for simple projects.  But it does not help with software design.  It does not force a user to do error checking or error handling.  Of course C or basic do not design the software either.  You can write bad programs in any language, but without a lot of the syntax/language issues LabView is easier to get started with.  At some point the LabView advantage goes away.  It is just as hard to do many things in LabView as in CVI.  Understanding the string formating statements is just as difficult for an unskilled programmer in LabView as it is in CVI.  Once you get past the basics, the advantages of LabViews Graphical Interface start to equal out with something like CVI.  Both are great tools, but it is the skill of the programmer that makes them work for complex projects.

- The graphical user interface tools in both CVI and LabView are very similar and easy to use, typically less complex than something like Visual Basic.  The control/indicator model that both LabView and CVI use is pretty easy to understand.

- There is a lot code written in C in the public domain for scientific applications.  Much of it came of unix systems, but it is easily ported to the windows world.

- There are more NI toolkits available for LabView than CVI.  But there are far more third party libraries available for text based languages. 

- If you need to use the windows SDK for access to more advanced system features it can be a struggle for "LabView Only" programmers who are not familiar with the C interface.

[mvr]

Getting past the details of languages above the more fundamental question is what do these scientists need to do?

- If they need to create quick and dirty interfaces to instruments for data acquisition and display without any real re-user requirements the first choice would be Signal Express.  It has by far the quickest learning curve, but the most limitations.

- If they need to do a little more, data processing algorithm development, data manipulation, user interface, but do not need to become programmers and will not have much involvement with large programming projects LabView is a good choice.  For basic software programming features without a long learning curve, it does not get any better.

- For more number crunching tools but at the cost of complexity and syntax look at matlab or a combination of Matlab and LabView.  With the right training the scientists can create modules for specific features that are re-usable in a larger application 

- For more complex software design, full scale intergrated systems, development of modules that must integrate with other systems, optimized performance, distributed systems etc,  you need a real software engineer.  If you don't know the difference between bubble, quick or insertion sorts and why they would be used, you have no business designing systems that need to sort large amounts of data.  For this level it is the skill of the programmer and their familiarity with the development tools they use that make the difference.  LabView, CVI, VC even Visual Basic can all be used to create consumer grade software applications.  The target application and the available skill set of the programmers are the fundamental elements in deciding which software tools to use.  There are a lot of good analogies out there, here is one: I can use a hammer and cook my own dinner, but that does not mean I should design and build a restaurant.   

[RobertoBozzolo]

---

@Stocklone wrote:

(...) Another problem I have is that by doing everything in Labview is you will have a bunch of people who think they know what they are doing since Labview is so easy to pick up.  This will lead to anyone being able to muck around with anyone elses code (...)

---

To face this situation (which could arise for CVI programs too ) both environments allow you to create executables which are not modifiable and which you can run on every computer without need to have the develoment environment installed on. Additionally, LabVIEW permits you to save the vis password protected, so that modifying them implies some sort of "authorization" from the original creator of the vi.

In my opinion the answer to mvr question "what do these scientists need to do?" is crucial in this discussion: of course they are not expected to become software engineers so it can be expected that past some degree of complexity they do need some help to go on with their programming job, so the real question is: who is expected to complete and trim all this software they need? After choosing this person and looking at his skills you will have 90% of your answers!

Just my 2c...

[menchar]

I think it usually gets down to the fact that if the implementor views him or herself as a capable C programmer, he/she is going to want to implement in CVI rather than LabView.   As mentioned, the granularity is there to be more certain you can implement a solution, even though you may write a whole lot of code to do it rather than connecting icons with lines. 

If the workload is such that non-programmers have to do a lot of development, I'd say CVI is not the answer.  With C, the paradigm is "trust the programmer" not to do stupid things, and non-pro folks can't be trusted not to do genuinely stupid things in C.  They may well be intelligent professionals in their field, but that doesn't make them capable programmers.  Some of the most botched up code I've ever seen was done by system engineers / EE's who had read the first three chapters of K & R and declared themselves C programmers.   Poor programmers, and with no grasp of even the simplest design concepts, they hack out gobs of code that typically breaks at runtime because they've mishandled pointers/arrays.  But most of these can eventually learn to accept advice as to how to structure their code.

Worse are those who have taken a couple of programming courses at the local junior college and weasel their way onto projects and strive to make themselves indespensible.  Too stupid to be embarassed, they are unable to accept any guidance as to style or form.    I find they often form up into a "conspiracy of fools" to cover their mistakes, or ingratiate themselves with a scientist or engineer who can't code at all.

I can't tell you how many times I've had the seniormost technical professional involved (usually an engineering fellow, tech director, or senior scientist) come to me to help unhose bungled CVI applications, often after the culprits shoved aside my participation in the first place.

On the other hand, the point to most systems isn't to have good code or a good software design.  The domain knowledge involved is almost always going to be held by non-software people.  Many want a sense of "doing something" as a day to day activity - and they often gravitate to coding if they can at all do this.  A pure C programmer isn't very useful, generally speaking - you have to work in some domain.

Of course, NI knows all of this, that's why they have both products.

Several groups I know of are now doing test SW impementations in C# and Visual Studio - sure, it's Microsoft proprietary, but intellegent non-software people are better able to implement using OO (and avoiding pointers and memory management).  I think NI's done what it can to approach the whole .NET thing.  But they didn't even try to accomodate Java, which I would have liked to have seen.

There are several threads on the website in re CVI Vs. LV.

[Jumper_Bones]

Here's my two cent's worth on this subject...

Prior to TestStand 3.0, I saw many LabVIEW developers argue that it's OK to write large "monolithic" programs in LabVIEW, as well as to apply it as "THE" solution to every problem in the test lab (going throught that right now as a matter of fact). I could overlook that approach back then, because it is human nature to be passionate about something you know well (for example, take a hard look at the linux vs. windows arguments posted world-wide).

But when NI put TestStand 3.0 out on the market a few years ago, with its native hooks into LabVIEW VI's, I can now say with conviction that the marriage of small-ish LabVIEW "routines" running within a large "monolithic" test executive makes an awful lot of sense, assuming you can afford the extra cost of a development-seat of TestStand (deployment seats are very cheap, however).

I say this because: Using LabVIEW within the framework of TestStand, you got the power of writing quick-and-dirty VI's in LabVIEW's rapid-application development environment, based upon any variation of arguments and/or data-I/O pushed in and out of those VI's that you could conceive of, yet the larger concept of looping/branching around these VI's when they are grouped inside of TestSTand's test sequences will inherently steer any non-programmer [don't mean to offend you LabVIEW readers by implying you are not "real" programmers with that label] to think of their VI test-routines or VI data-post-processing routines at a much lower-level. Which is the way it should be, because this is the fundamental concept behind many programming languages, including the various tools built from those languages (example: UNIX/Linux command-line tools), of the market for software components out ther efor Borland, or Visual Studio, or Java Beans. I could go on and on.

And the same is true for all you CVI developers, if you think about it. I have no affiliation with NI, but recall that TestStand evolved directly from the original "CVI Test Executive Toolkit", which came out at around CVI 4.0, if I recall correctly. The "native" hooks between LabVIEW and TestStand that were recently added in TestStand 3.0 have *always* been there for CVI code, at the source or binary (debug) level.

Worth reading more about TestStand to see if this makes sense in your own work environment...

JB