Talk:LabVIEW

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as High-importance).

Copyright/Criticisms Section

Under the "Copyright" section, there is an additional paragraph that discusses criticisms of the language. First off, I don't think this applies to "copyright" so it should, probably, get it's own section if it's going to stay. However, I don't think this really belongs in the article anyway. The only reference I can see there is an article from 2006. The paragraph itself lists a couple of criticisms and then, immediately, points out that they no longer apply to the language as of the 8.x versions (long since released by now). Should there even be a criticisms section if the only criticisms listed were made irrelevant years ago? I'm hesitant to just remove the paragraph since I know that criticisms about programming languages can be heated discussions and it'd be better if there was some consensus first. Colecoman1982 (talk) 20:57, 6 August 2012 (UTC)[reply]

In the criticisms section, the criticism that LabVIEW is non-textual contains a circular argument and does not make sense. In addition the referenced sources do not support the criticism that it is non-textual. This section should be removed unless it can be shown that there is an argument for textual vs. non-textual programming.Rgwagner888 (talk) 14:21, 15 September 2017 (UTC)[reply]

What does the LabVIEW acronym really mean?

This article starts out stating "Laboratory Instrumentation Engineering Workbench" but the book "Learning with LabVIEW 8" says it means "Laboratory Instrument Engineering Workbench". Small difference, but a difference nonetheless.

Well, you left out the "V." Corporate documentation seems to use both definitions at times.. If memory serves, however, LabVIEW 1 actually said "Instrumentation" when the program started. Not 100% sure though. In any case, as NI attempts to redefine LabVIEW as a general-purpose programming environment, I suspect we'll see the actual definition used less and less. -Seyon

The acronym originally stood for Laboratory Virtual Instrumentation Engineering Workbench since LabVIEW is used to create virtual instruments (VIs). -shogg —Preceding unsigned comment added by 99.54.127.246 (talk) 15:22, 13 August 2010 (UTC)[reply]

Userbox

LV

This user is a LabVIEW wireworker.

I've created this userbox for Wikipedians who programme using LabVIEW:
Just put {{User LabVIEW}} on your user page! - Gobeirne 08:12, 26 January 2006 (UTC) akhay nore ka m3 clear karo — Preceding unsigned comment added by 103.197.221.60 (talk) 05:33, 31 March 2017 (UTC)[reply]

Autobiographical Editing/Using Wikipedia for Marketing

The owner of the company that produces this software created and edits this article. See http://www.webpronews.com/topnews/topnews/wpn-60-20060301SEMNYCommunitiesWikipediaTagging.html . Superm401 - Talk 02:34, 2 March 2006 (UTC)[reply]

I disagree with the above entry

The person who added this text does NOT work for National Instruments so the statement: "The owner of the company that produces this software created and edits this article." is pure fiction. If you visit the mentioned link it is plain to see that it is a clear marketing tactic akin to spamming Wikipedia.—Preceding unsigned comment added by Michael Aivaliotis (talk • contribs)

The article says that Jeff Watts, someone involved in LabVIEW, started the article, but has since let it be. It was certainly created with "marketing intent", and would have been deleted if the product did not have a userbase of a notable size, but at least National Instruments has let it grow organically since. Our spamming problem would be a lot less if all companies could act the same -- start a profile or product article with facts (not marketing-speak), let the community edit, step in on the talk page if they see any errors creeping in, provide documentation of information they'd like to see included....hopefully the corporate public will start to "get it" in the next few years. — Catherine\^talk 17:05, 17 March 2006 (UTC)[reply]

Dataflow programming

Doesn't it seem incorrect to claim that "data-flow...completely defines the execution sequence"? Perhaps it can be completely defined, but usually it isn't. Justin212k 21:26, 28 February 2007 (UTC)[reply]

We need to be direct and truthful about LabVIEW shortcomings

Labview is a great product but several of the recent edits of the criticism have seriously obscured some of the legitimate problems. For example, there are concerns regarding the portability and longevity of code. The text that described in detail some of the new implications of software activation requirements was replaced with “could lead to future problems” and “it is not completely clear what would happen to the LabVIEW development environment if National Instruments were to go out of business.”

The earlier text (around Feb 26, 2006) pointed out precisely what the concerns were given the facts as they stand today. Namely, that without a company to activate the product there would be no way to install the software on new hardware and no way to access old code or certain types of archived data. This is an informative point and an important consideration for Medical and Scientific researchers that might be using Wikipedia to look into LabVIEW as a potential platform. The implications are NOT speculation; they are a direct consequence of the new activation policy. The activation policy can be determined by examining National Instruments own FAQ which clearly outlines that National Instruments must to be contacted to install the software (now referenced). Of course, National Instruments might claim to have contingency plans but whether these exist or could be implemented in practice is speculation. To simply hide these archiving concerns behind the fuzzy “could lead to future problems” is not helpful or specific enough.

BTW, this archiving and access issue and is not just a future problem and is probably more serious than described. Look through Labview news groups and forums and you’ll find plenty of folks who are trying to access code and/or datalog files (which are often the choice format) but can’t because their version is incompatible (either too old or too new for conversion).

National Instruments does have a "contingency plan"

I happen to know that National Instruments does have such a "contingency plan" already implemented and ready to deploy if it were ever needed. It would enable one to activate their license file locally without contacting National Instruments. Because of this, and the fact that it's not specific to LabVIEW but rather all products with product activation (as already discussed), I think this part of the Criticism section should be removed or rewritten. — kentyman 18:25, 4 August 2006 (UTC)[reply]

Can you verify it? eaolson 23:37, 14 August 2006 (UTC)[reply]

I am on the licensing team at National Instruments, and I personally worked on the aforementioned tools. — kentyman 20:15, 16 August 2006 (UTC)[reply]

I'm not doubting that you're correct, I'm just asking if this has been published in any reliable source, so that adding this point would meet the verifiability requirements. eaolson 21:52, 17 August 2006 (UTC)[reply]

As far as I know, it has not been published in such a source. I will look into it. — kentyman 20:53, 21 August 2006 (UTC)[reply]

This is irrelevant, because National Instruments must provide access to the software by law. To protect licensees of licenses of intellectual property, Congress enacted the Intellectual Property Bankruptcy Protection Act of 1988 to add Section 365(n) to the U.S. Bankruptcy Code. Section 365(n) protects licensees rights "as such rights existed immediately before the case commenced." Therefore, the filing of a bankruptcy by National Instruments would not affect the rights of licensees to use the software. --Marni1s 17:29, 15 November 2006 (UTC)[reply]

Sorry, this legalalistic analysis is off, see below...

Corporate contingencies and legalistic augments miss the point about problems w/ Labview activation

Both the legalalistic commentary and purported contiginies miss the point and real concerns with Labview activation schemes. National instruments may seem and actually be reliable but larger companies have disappeared ((E.g. Enron had over 20,000 employees and claimed revenues of 111 billion, which dwarfs National Instruments). Who exactly is the user going to contact for activation or sue if National Instruments ceases to exist? Would the bankruptcy trustees or US government run a Labview activation support line? None of this even begins to consider the problems for users outside the US. Would they have legal protection and ongoing technical support? What if their government restricts outside contact? Also, what if the lines are down? International and national emergencies can easily result in communication problems.

The point is that advanced users upgrade hardware regularly and in secure scientific or medical programming you need to be assured that you can install all software, access all data and all code anytime, anywhere without relying on corporate promises, outside entities, bankruptcy trustees or going to court. The operational default has to be ACCESS not potential legal recourse. November 16, 2006. —Preceding unsigned comment added by 74.12.163.45 (talk • contribs)

I think that it's obvious that even if kentyman's solution is not verifiable in a published form, the purported problem itself is not verifiable in a published form.

Some of the shortcomings aren't specific to LabVIEW

The concerns raised in the post apply to all activated software, including office productivity tools, used by researchers and engineers. To make sure researches are correctly evaluating all their software would it be more appropriate to update the definition of activation to outline the pro's and con's and refernece that from all activated software entires? The other comment regarding "access code/datalog files": at present there is a migration path for LabVIEW code from it's first version, 2.0, to the latest version, 8.0: http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/429e45271cfd683786256d87006b1eef?OpenDocument

Would it be possible for you to reference some of these posts to better determine the specifics?

Specific problems with LabVIEW activation, migration and file formats

1) REGARDING ACTIVATION, sure product activation is a major problem that applies to other products as well (unfortunately the wikipedia entry on "product activation" is fairly weak) BUT the issue with Labview is MUCH more serious than most other products. Unlike Labview, most office productivity packages and commercial programming tools have many Free Software and Open Source alternatives, so there is always an alternate way to get at your code or data. This is not true of Labview. If a few years from now you need to get to old code and data that requires reinstalling the software you'll have to hope that National instrument exists and that it's still handing out activation codes for old products. Scientific and medical settings often require absolute confidentiality and data integrity, these are seriously and unacceptably compromised by an activation scheme. The fact that national instruments now requires all users to contact them and provide personal data in order to use the software is clearly specified in the already referenced national instruments documentation: "To complete the activation process, the user must provide the end user name, organization, and serial number" (http://digital.ni.com/public.nsf/websearch/3F93009F5EEE114B86256D6C0051777F?OpenDocument).

2) As for the MIGRATION PROCESS, it is dubious at best. First of all, the process is mostly unidirectional. For example, version 8.0 will load version 7.0 and 6.0 code, but cannot save back to these formats (you can only go back one minor version at a time). The only way to save back to older versions is to find multiple installs (8.0, 7.1,7.0, etc) and progressively save in older versions (see http://digital.ni.com/public.nsf/websearch/C18E6D5FFA8F0D85862568CC0067274F?OpenDocument) As someone who has been dealing with these migrations since Labview 3, I can tell you it gets nasty, especially if you're working in a mixed environment with colleagues working on various versions or mission critical systems that can't be immediately upgraded.

Very few other programming languages or office productivity packages still have such clumsy file compatibility limitations so common in the 90s. But if code compatibility was bad enough the data formats issue is even worse! If you update datalog data in a new version you often can no longer access it in your old code NOR can you save it back to the old format. Again, these limitations are spelled out in the sugar-coded national instruments documentation; check the links on the page you list. Also see the upgrade notes for version 8, 7.1 and 7.0 (e.g. http://www.ni.com/pdf/manuals/371780a.pdf).

3) In general, the DATALOG STORAGE integrity is poorly thought out. Although datalog files are often the only practical solution for saving complex data compactly, if you don't know the structure of your saved data you can't load it! I.e. if you lose your program or even make a minor change to a data cluster structure you have no way to open old files without successfully guessing the record structure. Labview engineers have somewhat ridiculously tried to claim that not being able to determine record structure is a security feature and that "Having a way of knowing what the datalog type is directly from the file would defeat the purpose." See "Retrieving datalog files" thread in comp.lang.labview. (http://groups.google.ca/group/comp.lang.labview/browse_thread/thread/c49b974496137855/399c38d3b58bfb4e?lnk=st&q=Retrieving+datalog+files&rnum=1&hl=en#399c38d3b58bfb4e).

On the whole, I think the article's criticism section is fairly forgiving and doesn't get across just how serious these problems can be. Labview is an amazing language, but all these proprietary format and activation shenanigans really raise doubts about it being appropriate for secure scientific and data archiving purposes.

Datalog formats are very easy to use but have never been the recommended way to save your sensitive data. Yes the LabVIEW programming manual explains how to create and use them and I would expect it to do so since it's a possibility of it, but at the same time it states the version dependency. If you have critical data that needs to be accessible over 20 years then datalog is not for you (and effectively any other binary format neither).

The problem is that here someone requires a compact (or binary format) and at the same time openly accessible from any environment. If that is your concern do your own format header description and then stream the data in binary format to a binary stream file. This is similar to a datalog file in terms of compactness but avoids the version specific datalog header. The binary data itself is streamed in that way directly to disk in the format as outlined in the Application Note about Data Types. It is not as trivial as datalog files since you need to maintain your own header (recommended to do) and if you want to stream many data you also will need to do some record keeping somehow to easily be able to index data in the file. But the format is fully defined by you and can then also be read in other applications such as C programs in binary stream format.

While I agree that Activation might have certain long term risks I find it very easy to criticize certain aspects of a feature of a software because you want to use it for something it was never created for. And there exist fairly easy solutions for the problem you say you want to solve.

And since you talk here about future security mostly, the migration in these terms is much more important towards newer versions than the opposite. If you create a program now in a certain LabVIEW version and want to be able to recreate it over 10 years then it is not likely that you will then use an older version of LabVIEW than what you used today. So for that the limited ability to safe to older versions is never a problem. It is sometimes inconvenient during development if you work in different versions at the same time but not for the ability to guarantee access to your code in the nearer of longer future.

RolfK (talk) 20:40, 30 March 2008 (UTC)[reply]

In reference to the first point, I dont see how a requirement to disclose end user name, organisation and serial number in anyway impacts the confidentialilty of the data stored using a LabVIEW program. It is akin to stating that Microsoft's Windows activation adversely impacts the confidentiality of all data stored using a windows program. It is an annoyance to developers but nothing more than that. —Preceding unsigned comment added by 66.25.183.241 (talk) 02:55, 2 June 2009 (UTC)[reply]

Criticism

The article mentions that LabVIEW does not offer a testing framework. However, a quick check of the website reveals a Unit Tesing toolkit, here. Before modifying the entry, though, I would like some degree of consensus about whether this meets the criticism, since it isn't free and I haven't used it (I prefer to simply wire my own tests for subVIs). — Preceding unsigned comment added by 130.164.78.152 (talk) 21:11, 6 July 2011 (UTC)[reply]

the article mentions that programmers coming from conventional languages are reluctant to adopt labview due to misunderstanding the paradigma, and that there are issues with registration keys. I am a physicist and I am fairly skilled with C/C++. I have written a couple of somewhat complex Labview programs (Labview 7.1) and I have very different problems with Labview - which may or may not apply to LV 8:

I'm endlessly clicking to move wires around. If there are a few things sitting inside a sequence or while loop, and I want to exend the program, there are usually two options: (1) make a complete spaghetti of the wires because it doesn't fit otherwise, or (2) putting stuff into a separate subVI with a zillion inputs. Moving code from one VI into a sub-VI takes 10 times more time than encapsulating a chunk of C code into a separate function.

Not sure what you mean by this. You can increase the size of any structure by dragging. Ctrl-drag will add blank space and move existing objects out of the way. eaolson 20:56, 4 August 2006 (UTC)[reply]

If you use event structures, clusters and property nodes effectively, you don't have this problem at all. Even if you are really bad at writing code, you can just highlight a chunk of code, and the "edit->create sub VI" will put it in a VI for you.71.228.100.123 08:08, 29 April 2007 (UTC)[reply]

Clusters, the Labview-equivalent of a struct in C: you have to guess in which order the elements are declared. The function "bundle by name" does not work unless you already have a variable of that type. You can't make the equivalent of a typedef, which means that you have to update all VI's which use a certain type of cluster, just because you wanted to add an additional boolean flag that you need somewhere four levels deeper, rather than update the definition of the cluster at one central point.

No, the default order is the order in which they were added to the cluster. You can change that order by right-clicking the cluster and selecting "Reorder Controls in Cluster." You can make a typedef. It's one of the three kinds of custom controls. If you later update the typedef, it automatically updates in all VIs using it. eaolson 20:56, 4 August 2006 (UTC)[reply]

With labview 8.2 you can now use a class as well as a typedef. w00t.71.228.100.123 08:08, 29 April 2007 (UTC)[reply]

For complex applications, you usually have to resort to global variables. They are a pain. You have to initialize the global vars AND all controls that modify these global vars (or put a lot of extra wires around every control terminal, which take up valuable screen real estate).

I disagree, you can just pass a reference to you a cluster or class. Yes labview supports pass by reference.71.228.100.123 08:08, 29 April 2007 (UTC)[reply]

Preventing race conditions in multithreaded apps (that communicate through global vars) is hard; there's no such thing as an atomic operation.

Globals are a bad idea in multithreaded apps for the very reason that they lead to race conditions. Functional globals, queues, and notifiers are a better idea in multithreaded apps. You have read the "Using LabVIEW to create Multithreaded VIs..." Application Note? eaolson 20:56, 4 August 2006 (UTC)[reply]

I'm coming to this discussion more than a year late and I've never used labview, but this is a complete cop-out. A "real" programming language has some type of synchronization primitives for this purpose. When you use labview's queues, etc., that's what the labview runtime must use behind the scenes to ensure thread safety. The fact that it provides synchronization for some data structures and not for others sounds to me like poor support for threading. Andyluciano (talk) 15:16, 5 December 2007 (UTC)[reply]

LabVIEW does have the semaphore if you want a synchronization primitive. C++ has no such primitives, and no one would say it is not a "real" programming language. eaolson (talk) 21:46, 6 December 2007 (UTC)[reply]

Okay. Well a statement like "global variables cause race conditions" is erroneous, and that was what I found most strange about your comment. Also note that I said "I've never used labview".

Also, C++ doesn't have synchronization primitives, but POSIX does, Win32 API does, and C++0x will.

–Andyluciano (talk) 20:38, 18 December 2007 (UTC)[reply]

Re: globals, a more correct statement is that "global variables in LabVIEW cause race conditions." Terminology does not translate directly from C/C++/etc, the wires in LabVIEW are the variables that you are used to in other languages. A functional global uses wires (and shift registers) and avoids these race conditions. Timothynolan (talk) 21:46, 16 May 2008 (UTC)[reply]

I can't easily make user controls that consist of a combination of standard controls plus logic behind, for example a graph with an adjacent bar indicator that shows the integral of the graph. I have to lay out all the wires again each time I need such a combination of functionality.

This is now available in LabVIEW 8.0. It's called Xcontrols.--Michael Aivaliotis 08:30, 6 August 2006 (UTC)[reply]

The formula node supports some subset of C, but with different behaviour regarding integer rounding: ~~int i=5/2; int j=i*2~~ int i=5; int j=(i/2)*2; will give j=5 rather than j=4. ~~(Maybe I'm remembering wrong, can't reproduce it now).~~ Editing (no auto-indent) and debugging is a pain.

No way to do dynamic linking to sub-VIs. For example, if you want to use a Levenberg-Marquard fit (LMF), you are supposed to copy the LMF VI and edit the wire diagram in order to insert the function of your choice.

I don't know what you're talking about here. The Levenberg Marquardt VI does not require you to edit it's block diagram to solve an equation. There's even an example that comes with LabVIEW showing you how to use it. If you do want to dynamically call a sub-VI you can do so at runtime with the Invoke node or the Call by Reference node. eaolson 20:56, 4 August 2006 (UTC)[reply]

I could probably go on and on for a while, but am I the only one who dislikes Labview for these reasons? Or is all the functionality that I'm looking for already available and am I looking in the wrong places? Han-Kwang 16:43, 11 April 2006 (UTC) (additions Han-Kwang 17:10, 13 April 2006 (UTC))[reply]

I had some issues adapting to LabVIEW from traditional coding as well. I believe another "graphical programming" package, E-Prime, attempts to be fully functional both in the graphical model and conventional programming worlds. Twinxor t 02:44, 13 April 2006 (UTC)[reply]

Han-Kwang - sorry that you are having such troubles. But alas, there are simple ways to do all the features in LabVIEW that you are looking for--but it takes time to learn. Try contacting N.I. support with your specific questions, they can help you. P.S. this is my first Wiki-posting...Good luck! Gaurav1967 20:01, 21 April 2006 (UTC)Gaurav1967[reply]

I guess this is not the right place for a discussion of how to do X in labview, but I will ask around. My complaints were merely examples of why someone (me in particular) might dislike LabView. I do not at all recognize the criticism mentioned in the article (in the first paragraph and the section at the end). But since I don't know that much about LV, I didn't feel like editing the article. Han-Kwang 19:54, 29 April 2006 (UTC)[reply]

Han-Kwang - I also find LabVIEW immensely frustrating to use. Especially if you decide you need to rearrange some part of your program and all the connection get messed up. I also have to wonder how anybody with poor eyesight or a shakey hand could possibly use LabVIEW (all those tiny connection points you need to click on)Wjousts 17:25, 5 May 2006 (UTC)[reply]

It is not about doing X in Labview, it is about beeing able to do all the things, which you are used to do in C++, Matlab (Matlab is not so good: Classes, Templates, anyone?) or Maple. I will no start any large project in Labview and abort it on the final mile, because a feature taken for granted is missing, and would rather use their C++ Libaries, although I miss a decent debugger for C++ (I like debugging in Matlab: Small prototypes, call them from cmd and later integrate ... it seems to be the same in Labview).Arnero 18:19, 14 December 2006 (UTC)[reply]

It turns out that the majority of critcism presented about Labview is a result of not knowing how to use Labview properly. In the same way using C++, with concepts such as abstract classes, polymorphism, templates etc, can be difficult for a Fortran 77 programer, coding in Labview can be difficult for someone who doesn't know how to properly use Labview and its API set. What it really comes down to is learning how to program in Labview "effectively".

I think the problem is most people don't respect Labview as an complex indepth language. The initial ease of use of when first starting Labview fools people into believing they know how to program correctly. Coding properly in Labview requires a good deal of experience and knowledge of abstraction principles specific to G, and a good CS background in general. Having a Ph.D in numerical methods using Fortran 77, etc, will do little for improving the structure of your Labview code. 71.228.100.123 08:08, 29 April 2007 (UTC)[reply]

Re: Compiled executables produced by the Application Builder are not truly standalone in that they also require that the LabVIEW run-time engine be installed on any target computer on which users run the application.

I do not accept this as a fair criticism. Any code written for a modern GUI uses runtime libraries. This is even true of C, it would even be true of assembler. If I was to write an assembly level programme that needed to make use of KDE features I would have to link into the KDE runtime libraries, or the Windows runtimes if I needed to use Windows features. Noone would dream of levelling the above criticism at assembly language so why should it be made against G. It is not the language that necessitates the runtime libraries, but the complexity of the environment. On these grounds I feel that this criticism should be withdrawn and the paragraph deleted. Kimdino 18:07, 28 July 2007 (UTC)[reply]

--- The proprietary file format --- A still unmentioned criticism is the fact, that the file format of Labview, similar to that of Mathcad, is totally proprietary. Even a change to an XML format like Mathcad did after Mathcad 2001i, would not change anything, as it did not change anything with Mathcad 11 - 14. Besides the SERIOUS migration problem mentioned above, already, its that there is no free viewer and no free "cutter". With software development systems based on text files, you can ALWAYS look at the code. With visual programming languages like Labview, you NEED to load it in the development system. Especially if you want to "cut" part of the application to reuse it for other applications, you NEED the development system and not just a text editor. There is no free viewer for Labview which might allow a user to "copy" even visually the code to another (older) system. The same with documentation: You can hardly guess how an application works by looking at printing colored (or even b/w) Labview diagrams ( as it is often useful and necessary, to "hide" certain code in lower structures, which are not accessable to the user when ONE layer of the application is "printed". hemmerling 16:41, 2 October 2007 (UTC)[reply]

Where is this criticism made? I'm not saying that you don't have a point, but we're not here to write a critical analysis of LabVIEW. Such a criticism needs to be sourced. eaolson 22:29, 2 October 2007 (UTC)[reply]

Hmm my criticism is my own user experience :-), so I am my own source, you can quote me :-).

hemmerling 17:18, 3 October 2007 (UTC)[reply]

I'd like to add that Labview seems to be struggling with some form of growing pain or even an identity crisis.

In the early days, when Labview was a competitor for software like HPVee, the attraction of Labview's G-language was that it was so simple (for programmers and non-programmers alike). You took some (very powerful) blocks, wired them together and in a matter of minutes you had a powerful, nice looking, working program that interacted with your equipment. The hierarchy of the program lay a few levels above programming languages like C and that was it's strength.

These days, Labview has evolved into a very powerful programming language, with a focus on 'everything is possible'. Unfortunately, with it, the hierarchy has almost dropped to the hierarchy of C++. Take a look at the 'call library function' for an example. And then the question becomes; if you don't get the benefit of the higher hierarchy anymore, why put up with all the drawback's like the cost, the proprietary format, the frequent version changes, the required activation, etc. ...

The many remarks that are so called 'related to not knowing how to properly use Labview' seem to support this remark.

Ratecrash (talk) 05:22, 29 September 2008 (UTC)[reply]

Recursion

"Critics point to a lack of features, common in most other programming languages, such as, until version 2009, native recursion..." This is another one of those 'related to not knowing how to properly use Labview' or understand how LabView code works comments. Since very early days LabView includes shift registers and feedback nodes for loops that allow the developer to pass the data multiple times through the same subVIs or routines. It is true that recursion in the "classic" sense of including a function into itself was not supported, but my guess is that it was not supported simply because it is actually not needed! Trough shift register one can achieve exactly the same result from DATA point of view which is achieved trough "classic" recursive call. If we take the classic example of calculation of n! for instance, normally this is achieved trough recursive call because this is the only sensible way available in languages like C/C++ etc. However in dataflow environment the same result can be computed without any need for explicit recursion. In short - the explicit recursion is simply not needed in well written LabView code due to the structure of the code. —Preceding unsigned comment added by 193.229.191.5 (talk) 13:36, 12 August 2010 (UTC)[reply]

I think your comment could be classified as 'related to not knowing what recursion is or how to used it'. Your comment that recursion is the only "sensible" way to calculate n! in C/C++ is just wrong. You can just as easily write it iteratively. The point is that recursion is a tool that exists in other languages as doesn't exist in LabVIEW. Nobody "needs" to use recursion just like nobody "needs" a FOR loop if you have a WHILE loop (and vice-versa). In fact, you don't need either if you have IF...THEN and GOTO. It's a feature that makes some problems easier to code and/or easier to think about. Therefore, by not having it, LabVIEW is harder for that particular class of problems. Wjousts (talk) 16:53, 12 August 2010 (UTC)[reply]

Fair use rationale for Image:LabVIEW 8dot20 Splash Screen.jpg

Image:LabVIEW 8dot20 Splash Screen.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 02:25, 6 September 2007 (UTC)[reply]

Price

LabVIEW is also relatively expensive compared to other development suites. LabVIEW starts at $1199 (2007 pricing) for the base version and runs up to $4299 for the NI Developer Suite. The professional edition, which is the cheapest package that bundles the application builder, costs $4099. This compares to Visual Studio which starts at $299 (2007 pricing) for the standard edition.

The validity of this criticism is questionable. Comparing LabVIEW to Visual Studio seem like comparing apples to oranges. A more accurate comparaison would be to Vee, which runs for about 1500$. Cochonfou 09:24, 8 October 2007 (UTC)[reply]

A fairer comparison might be Visual Studio + Measurement Studio ($499 for standard edition) which is still cheaper than LabVIEW. Either way, LabVIEW is expensive and that creates a barrier for entry which keeps LabVIEW a niche product. Wjousts 15:19, 8 October 2007 (UTC)[reply]

LabVIEW is far from a niche product. In the electronics testing and development and industrial automation businesses it's one of the de facto tools. It was never meant to be an application development tool and comparing it to visual studio is, as stated before, pointless. Jhuuskon (talk) 15:22, 7 October 2008 (UTC)[reply]

Name of “G” language

It appears that NI no longer calls the programming language “G”, but calls it “LabVIEW programming language”. A quick check of the NI website confirms that, e.g., see this FAQ item. The change probably reflects the fact that virtually nobody in the research community has been using the “G” name but always referred to the language as "LabVIEW" in research papers. Vadim Makarov 05:24, 18 October 2007 (UTC)[reply]

There is another aspect and that is that the term G for a sort of programming language already exists and even predates LabVIEW. It is G code, or RS-274D and is the recommended standard for numerically controlled machines developed by the Electronic Industry Association in the early 1960's. See G-code RolfK (talk) 20:57, 30 March 2008 (UTC)[reply]

Outcome of LabVIEW's compiler

With help from the article I do not understand a basic feature of Labview. What is the outcome of Labviews Compiler? Does it produce C-code and thus runable on Microcontrollers? -- 84.132.87.172 14:40, 3 November 2007 (UTC)[reply]

LabVIEW is basically a combination of a development environment where you write code and an interpreter which actually executes the code. With the Application Builder you can compile LabVIEW code to an executable (which requires the Run-Time Engine libraries to be installed). I'm not sure what you mean by producing C "code." LabVIEW is it's own programming language. eaolson 16:41, 3 November 2007 (UTC)[reply]

Labview code compiles down to machine language I believe. 128.95.141.35 (talk) 02:26, 16 May 2008 (UTC)[reply]

The LabVIEW core runtime engine is (as of LabVIEW 2009) only available for Windows, Linux, and Mac OS. The Windows version of LabVIEW has an add on module (LabVIEW Embedded) that converts VIs to C code that can then be sent into compilers targeted for microcontrollers. —Preceding unsigned comment added by Seyon (talk • contribs) 00:16, 4 September 2009 (UTC)[reply]

Does a "Benefit" section belong in WikiPedia?

The word "benefit" by itself smells like a sales brochure, and the first sentence of the section confirms this: "One benefit of LabVIEW over other development environments ..." Other development environments? Development of what? Food? Software? Hardware? I believe that this article should get a "rewrite because of objectivity" tag until this section has been turned into a comparison section. --Pmg 06:25, 9 November 2007 (UTC)[reply]

I kind of agree. Especially since in this article it seems like the comparisons are cherry-picked and never defined. They want to state the benefit over other development environments (without naming which ones), but complain if you make an unfavorable comparison with other development environment(see price). The article really needs to state clearly what LabVIEW is and what it isn't. It isn't a general purpose programming environment. You could try and write something like a word processor with it, but you'd be mad to try it. Wjousts 13:51, 9 November 2007 (UTC)[reply]

Fair use rationale for Image:LabVIEW 8dot20 Splash Screen.jpg

Image:LabVIEW 8dot20 Splash Screen.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to ensure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 23:08, 13 February 2008 (UTC)[reply]

FORTRAN

I removed this from the article:

On the other hand, there exist (or have existed) programming languages lacking recursion capability or object-oriented features. Standard FORTRAN, for example, did not support recursion in versions up to and including FORTRAN 77^[1], and even through FORTRAN 90, does not fully support object-oriented programming.^[2]

Because the article already qualifies it's comment about what features LabVIEW lacks with "most" programming languages. I don't think adding FORTRAN, an old and mostly out-of-date language, as a counter example adds anything to the article. —Preceding unsigned comment added by Wjousts (talk • contribs) 16:51, 22 May 2008 (UTC)[reply]

National Instruments claims [1] that LabVIEW does support recursion (reentrant execution). Perhaps the particular criticism of lacking recursion needs to be removed or at least clarified that while it may have been true in the past, it does not appear to be true at present. Some quick searches as well as my past experience suggests that LabVIEW has been capable of this since version 5. 71.236.215.87 (talk) 21:40, 1 June 2009 (UTC)[reply]

Reentrant execution is not the same as recursion. Recursion requires that a VI be able to call itself. Re-entrant execution allows other VI's to call multiple instances of the reentrant VI simultaneously. I believe recursion is available in class methods with some qualification, in version 8.6 at least. Recursion for regular VI's is not available yet(as of version 8.6.1). —Preceding unsigned comment added by 66.25.183.241 (talk) 03:11, 2 June 2009 (UTC)[reply]

References

Alternative Open Source Existis?

do you know any alternative open source project/product to Labview? Are there such attempts?--Infestor (talk) 10:30, 29 October 2008 (UTC)[reply]

MyOpenLab is supposedly a alternative to LabVIEW. (I have not used myopenlab myself) There is a page at myopenlab.org . I'll put the answer here and let you guys decide if it should be referenced on the main page. (2019-11-11) — Preceding unsigned comment added by 70.225.236.130 (talk) 21:15, 11 November 2019 (UTC)[reply]

AFAIK, there are no alternative open source projects similar to LabVIEW. LabVIEW is patented and every approach to create similar environment is attacked by NI. Kupsztal (talk) 12:51, 24 November 2008 (UTC)[reply]

Try Python GPIB etc. support with PyVISA on sourceforge — Preceding unsigned comment added by 134.95.66.160 (talk) 14:06, 8 November 2011 (UTC)[reply]

This is not really appropriate for an article talk page, but while there's not really any close analog to LV, pretty much anything you could do in LabWINDOWS/CVI can be done just as easily in c++ using Qt or similar. a13ean (talk) 20:25, 15 November 2014 (UTC)[reply]

Need for section on using LabVIEW with Excel?

While the information in this section is correct to a certain degree, the purpose of this page is not to show application-specific 'how-to' for the LabVIEW programming language. I believe this section should be deleted. Timothynolan (talk) 15:00, 13 November 2008 (UTC)[reply]

Alternatives

LabVIEW seems to combine instrument control, data acquisition, data display and analysis. Anyone who wants to conduct experiments needs this combination.

What alternatives are there? The list at the end of the article:

Numerical software - Open source

ADMB · FreeMat · GNU Octave · gretl · R · Scilab

does not seem very on-point. Do any of those offer control and acquisition functions? Does any other software combine these? -96.233.27.159 (talk) 18:24, 10 June 2009 (UTC)[reply]

SciLAB at least has some DAQ support. Most notably, DAQ Toolbox seems to provide a bridge between SciLAB and NI-DAQmx 2.x. —Preceding unsigned comment added by 93.32.134.10 (talk) 17:57, 22 June 2009 (UTC)[reply]

LabVIEW internals

Some other software-related articles contain a section on the programming that created that software - number of lines of code, languages used, etc. I believe LabVIEW is written in C++, but I imagine that with its humongous growth other languages might be used as well. Any resources available for what LabVIEW is made of and how big it is? Rob Hingle (talk) 20:23, 28 October 2010 (UTC)[reply]

Dates

The dates listed in the release history are in mixed format, and many of them are in MM/DD/YYYY format which is contrary to wikipedia policy: [2]

Formal testing section

For an environment targeted for repetitive application, especially in process automation, LabVIEW includes no built-in functions for formally testing limits, reading a limits file, and conveniently tracking the passing or failing results.

Due to such constraints in effect with formal and dynamic testing, the recommended usage potentially will not cover the required scope for production or therapy processes, especially when these are subject of risk and security auditing, e.g. according to FDA 21 C.F.R. §820 et seq.[5]

Companies tend to build their own proprietary functions for this basic feature if they choose not to use National Instruments' product line TestStand.

This section is very unclear. it sounds like a very specific application and has some passive-agressive sounding language in it (ex. ..."this basic feature"). If this is a well documented shortcoming, it needs to have more explanation and also links to better references.--70.187.190.211 (talk) 03:56, 10 March 2013 (UTC)[reply]

Adding Programming Techniques?

Would it be beneficial to add links to pages like State Machine, Producer consumer, or master slave LabVIEW programming techniques? I was planning on adding a page about the State machine (LabVIEW programming) would this be a good idea to expand on? (Sorry, I am very new to Wikipedia editing but know a lot about LabVIEW and want to help) — Preceding unsigned comment added by Smith Pohl (talk • contribs) 22:27, 14 April 2014 (UTC)[reply]

Question and comments

1a. The "Graphical programming" section uses "Functions palette."

Does it have to be capitalized? I don't think so.

1b. The last paragraph in the "Graphical programming" section points out the necessity for a programmer to know and do right. I would suggest to separate this and make a subsection and maybe list good programming approaches like state-machine and master-slave.

2a. The "Criticism" section sounds quite biased. Some statements are debatable. Others are even false.

2b. "Due to its thorough adoption of a data-flow programming model as opposed to the sequential ordering of arbitrary commands like most other (usually text-based) languages there is a very real barrier to many people who attempt to apply already-learned principles from other programming approaches to LabVIEW. The inherent parallel nature of the execution of LabVIEW code is a perennial source of confusion among those who are accustomed to other approaches. Due to this, most opinions tend to be highly polarised with people either being extremely fond of it or being extremely hostile to it."

This is a completely biased opinion. Personally, with a background in C++, Java and some C programming as well as assembly language, when I embraced LabVIEW I thought it was the best thing since sliced bread. In fact, I'm not a fan of high-level languages and I find the dataflow programming model smart and less painful when it comes to debugging.

2c. "Compiled executables produced by version 6.0 and later of the Application Builder are not truly standalone in that they also require the LabVIEW run-time engine be installed on any target computer which runs the application."

This is a completely false and outdated information (the sournce points to a note from LabVIEW 8.2 dated August 2006). I used the application builder and deployed truly standalone executable applications that did not need anything else with LabVIEW 2011 and 2013. Things changed since 2006.

2d. "However, the run-time required for LabVIEW is not supplied with any operating system and has to be specifically installed by the administrator or user."

I don't see any problem with this. Java requires the same thing.

3. The article should really have an image of the front panel and the block diagram.

4. It would be nice to mention the duality of the front panel and the block diagram as well as add the modularity of the environment that allows you to have a VI inside a VI somewhat like a box inside a box. Also, I think the article should at least include a few applications and mention the cDAQ, the modules and instrumentation control through GPIB.

ICE77 (talk) 04:11, 5 August 2015 (UTC)[reply]

History section

An article about program that exists for 30 years+ could for sure use some paragraphs about its history.--95.91.181.199 (talk) 14:40, 10 August 2016 (UTC)[reply]

Widely accepted design patterns

The source documents that are listed in this section are all from National Instruments. That they are being used will further aggravate the warning at the beginning of the LabVIEW article. That is, that the article relies on sources too closely associated with the subject. Also, no source is listed for the claim that "Applications in LabVIEW are usually designed using well-known architectures ..." Rgwagner888 (talk) 21:28, 2 October 2017 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on LabVIEW. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive http://arquivo.pt/wayback/20091228082756/http%3A//zone.ni.com/devzone/cda/tut/p/id/5053 to http://www.ni.com/labviewzone
Added archive https://web.archive.org/web/20100324105833/http://www.labviewportal.eu/ to http://www.labviewportal.eu/
Added archive https://web.archive.org/web/20120419000754/http://lab-view.com/ to http://www.lab-view.com/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:15, 15 December 2017 (UTC)[reply]

[1] Recursion Not Supported by FORTRAN

[2] Object-oriented programming using the Fortran 90 programming language

[1]

[2]