Talk:LabVIEW

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] 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)

[edit] 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)

See also http://rohitbhargava.typepad.com/weblog/2006/03/using_wikipedia.html --Baikonur 13:36, 7 March 2006 (UTC)

[edit] 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.—The preceding unsigned comment was 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)

[edit] 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).

[edit] 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)

  • Can you verify it? eaolson 23:37, 14 August 2006 (UTC)
  • I am on the licensing team at National Instruments, and I personally worked on the aforementioned tools. — kentyman 20:15, 16 August 2006 (UTC)
  • 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)
  • 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)
  • 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)
  • Sorry, this legalalistic analysis is off, see below...

[edit] 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. —The preceding unsigned comment was added by 74.12.163.45 (talk • contribs).

[edit] 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?

[edit] 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.

[edit] Criticism

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)
  • 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)
  • 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).
  • 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)
  • 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)
  • 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)

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))

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)
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
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)
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)
Retrieved from "http://en.wikipedia.org../../../l/a/b/Talk%7ELabVIEW_88aa.html"