This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
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)
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)
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)
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)
See also http://rohitbhargava.typepad.com/weblog/2006/03/using_wikipedia.html -- Baikonur 13:36, 7 March 2006 (UTC)
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)
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)
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).
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)
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.
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?
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)
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)
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)
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 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))
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)
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)
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)
--- 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)
hemmerling 17:18, 3 October 2007 (UTC)
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)
"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)
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)
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)
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)
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)
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)
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)
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)
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)
I removed this from the article:
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)
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)
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)
References
do you know any alternative open source project/product to Labview? Are there such attempts?-- Infestor ( talk) 10:30, 29 October 2008 (UTC)
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)
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)
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)
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:
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)
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)
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]
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)
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)
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)
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)
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)
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:
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: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 03:15, 15 December 2017 (UTC)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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)
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)
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)
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)
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)
See also http://rohitbhargava.typepad.com/weblog/2006/03/using_wikipedia.html -- Baikonur 13:36, 7 March 2006 (UTC)
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)
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)
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).
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)
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.
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?
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)
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)
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)
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 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))
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)
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)
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)
--- 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)
hemmerling 17:18, 3 October 2007 (UTC)
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)
"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)
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)
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)
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)
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)
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)
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)
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)
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)
I removed this from the article:
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)
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)
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)
References
do you know any alternative open source project/product to Labview? Are there such attempts?-- Infestor ( talk) 10:30, 29 October 2008 (UTC)
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)
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)
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)
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:
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)
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)
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]
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)
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)
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)
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)
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)
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:
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: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 03:15, 15 December 2017 (UTC)