Community version of LabVIEW coming

[xrunner]

November 2019: National Instruments is working on a Community version of LabVIEW that will be free for personal and non-academic use. This includes an updated version of the LINX toolkit. If you are interested in beta testing this version, go to this Beta Page to sign up.

Community version of LabVIEW

[RoGeorge]

Told you NI, told you about 6 years ago!   
Better late than never, thank you.

That's great news for everybody.

[floobydust]

This is many years late! I can't see anything being "free" with National Instruments.

"Students can get started with an extended 6-month evaluation period and have the option to purchase LabVIEW Student Edition or the LabVIEW Student Edition Suite." Students have so much money.

I found LabVIEW way overpriced, I ditched it a long time ago. It's only usable (affordable) in a corporate environment for a test fixture, or anywhere the boss can dole out a $5,000 P.O. for it and you have people who are fanboys of graphical programming. Some people love it, others hate it.

[xrunner]

I found LabVIEW way overpriced, I ditched it a long time ago. It's only usable (affordable) in a corporate environment for a test fixture, or anywhere the boss can dole out a $5,000 P.O. for it and you have people who are fanboys of graphical programming. Some people love it, others hate it.

That's where I used it, in a large corporate environment. They had plenty of cash to throw around and once I evaluated it and found it useful they bought it (more than one copy) along with the NI PC data acquisition cards and I put together all the data acquisition programs we used in the lab. I found it to be a very useful suite and I want to get the free copy so I can use it at home.

[VK3DRB]

It is good news and along overdue strategic initiative by NI. I guess the community version won't compile to an exe. In any case, hopefully it will increase the popularity of this language (which is really based on C and C++). I have 30 years' experience with it and have done a lot of programming with Labview, Labwindows/CVI, C#, and C. Too bad they don't lower the price for professional use.

Most people who complain about Labview have minimal experience with it or do not understand good programming practices. I can say this about Labview, based on my own observations:

- It is not suitable for extremely complicated systems.
- It produces very stable programs.
- It is very powerful, but it has some quirky limitations that C# does not have (eg: reading a CLI-based batch file output midstream).
- Its debug tools are generally superior to most languages.
- It is generally much quicker to write and debug a program in Labview than C++, C# or C.
- Parallel processes, queuing and semaphores are much easier to do in Labview. 
- It is way too expensive.
- Its installation is a dog's breakfast. A bit of a debacle, where just to have a PC RS-232 port working, you need to load a massive amount of drivers, as Labview (generally) does not use .NET, but its own libraries.
- Like all languages, discipline and education is needed to write a good program.
- Like any other language, there is nothing worse than inheriting some mess that some less-than-competent engineer has written in Labview.

[EEVblog]

I found LabVIEW way overpriced, I ditched it a long time ago. It's only usable (affordable) in a corporate environment for a test fixture, or anywhere the boss can dole out a $5,000 P.O. for it and you have people who are fanboys of graphical programming. Some people love it, others hate it.

That's where I used it, in a large corporate environment. They had plenty of cash to throw around and once I evaluated it and found it useful they bought it (more than one copy) along with the NI PC data acquisition cards and I put together all the data acquisition programs we used in the lab. I found it to be a very useful suite and I want to get the free copy so I can use it at home.

Yep, I worked in this industry for more than decade, money was no major barrier. We make test jigs out of all NI cards and high end Agilent gear, and then duplicate them dozens of times for production environments.

[EEVblog]

- Like any other language, there is nothing worse than inheriting some mess that some less-than-competent engineer has written in Labview.

We got stuck with that, and the Labview contractor got a contract with no end date...
Unlike Visual Basic and even Labwindows CVI, we could take existing code and modify it, but no one knew Labview well enough to untangle the contractors spaghetti 

[Caliaxy]

I’ve been using Labview for about 17 years now (since version 4, if I remember correctly; now I’m using version 2019). It’s a great piece of software for data acquisition and real time processing. Over these years, I accumulated a large library of programs (vi’s) that I’m recycling in my new projects. My chief complaint is poor compatibility across versions. Although you can run a vi developed on a Mac almost without issues on a Windows computer running the same Labview release (and viceversa), vis created in older versions of Labview might not run on newer versions (sometimes you can’t even open them to edit or update anymore, they are gone for good). Also, a vi developed on a 32 bit computer does not run directly on a 64 bit computer, you have to manually update lots of sub-vis. Labview is one of those pieces of software you might not always want to keep upgrading to the newest release (or think thoroughly before doing so). 

Having said that, I believe a free community version for hobbyists is great news, even if the application builder (or the capability of creating stand alone executable files) is not included. If a free version of Labview is available to everybody, there is no actual need for that. There are lots of old (but great) NI boards on the second hand market, which are relatively cheap because big companies don’t need them anymore (they upgraded) and hobbyists can’t use them, because Labview is prohibitively expensive. Maybe we should get some before the prices go up. Also, we might want to keep our old motherboards that still have PCI slots running 

[ChunkyPastaSauce]

This is many years late! I can't see anything being "free" with National Instruments.

"Students can get started with an extended 6-month evaluation period and have the option to purchase LabVIEW Student Edition or the LabVIEW Student Edition Suite." Students have so much money.

Having said that, I believe a free community version for hobbyists is great news, even if the application builder (or the capability of creating stand alone executable files) is not included.

Supposedly community version is labview professional, has the ability to build executables, and will be free for noncommercial and nonedu use.
It is different from the student edition which is labview full, does not have application builder, is not free.

https://forums.ni.com/t5/LabVIEW/LabVIEW-Community-Edition/td-p/3962226?profile.language=en

[joeqsmith]

It will be interesting to see how much has changed.  I've been reading about NXG and it seems like a big step backwards.    I too have been using Labview since 4.x.  Bought it for home use at 5x and it turned out to be one of my better investments in my hobby.  The only NI hardware I own is my Ethernet GPIB controllers.   

- It is not suitable for extremely complicated systems.
- It produces very stable programs.

Just a quick question and comment.   I've seen people post about how LabView is very unstable.  Like any language, it doesn't make a bad coder into a good one.   

Your comment about "extremely complicated systems" has me intrigued and I wonder if you could give your thoughts on what this means.   Maybe provide an example along with describing what prevents LabView from being used.   Size of the software, execution speed.....   Even for my hobby I have written what I would consider some fairly complex programs in LabView and have now abandoned using C to interface with it.   It would be interesting to get your perspective on it. 

[Daixiwen]

I have mixed feelings about Labview. On one side it makes it easy to so simple tests and try things quickly, but on the other hand I agree that complicated systems tend to generate actual spaghetti code, no matter how much you try to make it look neat.
We have an adaptive test bench that reads the configuration of the device under test from an XML file, and reading XML in Labview is an absolute nightmare (at least with 4.x, I don't know if they improved it since)

[VK3DRB]

- It is not suitable for extremely complicated systems.
- It produces very stable programs.

Just a quick question and comment.   I've seen people post about how LabView is very unstable.  Like any language, it doesn't make a bad coder into a good one.   

Your comment about "extremely complicated systems" has me intrigued and I wonder if you could give your thoughts on what this means.   Maybe provide an example along with describing what prevents LabView from being used.   Size of the software, execution speed.....   Even for my hobby I have written what I would consider some fairly complex programs in LabView and have now abandoned using C to interface with it.   It would be interesting to get your perspective on it.

Execution speed - no problem. I know a company which did some fairly comprehensive speed benchmark tests in C or C++ and they reported there was not much difference. I only heard this from the CEO at a NI conference; I had not looked at the result myself and what the code was. I personally have had no problem with speed.

Examples where Labview has "its limits"...

About 8 years ago, I wrote a Labview program to control a semiconductor wafer doping test machine. It drove various NI cards - matrix switches, power sources and measurement cards, and a PID algorithm to heat up a power zener diode silicon wafer anode, insulation foil and qty 525 special Ingun test probes to precisely 72 +-1 deg C using a very long time constant PID algorithm (the anode had a large thermal mass and lag). I would then test and map the characteristics of 525 zeners though a matrix. The results were recorded and various characteristics colour mapped onto multiple Excel spreadsheets, thereby enabling the customer to modify the doping of the silicon according to the characteristic pattern shown the colour map. The Labview code was quite complicated, but manageable with efficient use of sub vi's and putting extra effort into layout.

About 17 years ago, I developed a B2B system in LabWindows/CVI (a C version of Labview). This was really complicated in that customers could put in an order for a fully configurable smart office exchange (Internet, BIR/PRI ISDN, FAX, smart phones/POTS phones, trunk lines for different countries etc) via the Internet. The system would check stock levels, configure the order with all its option cards (build-to-order), instruct the assembler how to assemble it, and then start testing the system. The system programmed in heaps of PGP licences (timed or permanent) to enable different features. Everything would be verified and tracked and a full machine record with serial numbers etc would be stored on a server. The system would then print out the packing list, address labels etc. Any RMA's system would be tracked with a full history, including warranty data. I reckon it was better than using SAP, because SAP does not test systems deep down (and it has a crappy user interface). There is no way one would write such a system in just a G language like Labview. Labwindows/CVI was a great solution. However today, one could write subsystems (eg: test) in Labview and the rest written in .NET or CVI or whatever.

I once did a medical product in Labview (but for the PCBA, I used embedded C). The Labview worked well and was stable, but I was the only one in the company that knew Labview and the driver and runtime libraries were bigger than Texas, so after a few years I rewrote it in C#.  Lesson learnt there.

I consider making the community edition will make Labview be used for all sorts of applications though - not just test and measurement.   

[VK3DRB]

Another fun Labview project was a look-a-like GUI for a product we were developing. The Labview was a wrapped around a C interface that connected to code generated by Simulink which had a fairly complicated state machine in it. Using this, we were able to simulate a new product and modify the requirements and get them right prior to cutting any code or hardware in the final product. I transposed PNG images for the buttons and LED's that were realistic in the final product, even simulating the button depression.

Even though Labview has a state machine ability (an add-on), Simulink is a far better tool for this sort of thing and it runs in an RTOS as well on a old PC. It was blisteringly fast (ie: realtime for all intents and purposes). Unfortunately, Simulink is damned expensive, especially if you want to generate a .hex file for the state machine inside a microcontroller. I believe aeroplane and high-end auto manufacturers use Simulink for the obvious reasons (not sure about Boeing!).

One thing NI has that is a real winner is the Requirements Gateway tool. Its a couple of $K per seat but it is smart and links Labview VI's to requirements. It is smart enough to interrogate Word, Excel and other documents internally and highlight upstream and dowstream changes dynamically. In some ways it is superior to Atlassian tools like Jira for testing.

[joeqsmith]

Thanks for taking the time to write this up.   

After playing around with XCOS (simulinkish),  I was going to try to use XtoC (real time workshopish) to interface with Labview.   By now, I wouldn't be surprised to see people using it. 

If I looked at Labview code I wrote 17 years ago, I wouldn't be impressed.  Even 10 years ago, my code was pretty poor.   ....  Some things never change.  

[xrunner]

If I looked at Labview code I wrote 17 years ago, I wouldn't be impressed.  Even 10 years ago, my code was pretty poor.   ....  Some things never change.

I have a bunch of LabVIEW programs I wrote still on a CD, like from more than 20 years ago, while working in the lab (it had to do with electronic warfare testing). Had to do with interfacing to GPIB meters like Tek and hp instruments, NI DAQ cards, controlling some external rate tables, and controlling and getting the data back from the units under test. I have some screen shots in a notebook somewhere around here, of both the program diagrams and the user interface. Maybe I'll dig it out and scan a few screen shots for old time's sake.

Some of the stuff I wrote was pretty scary, I wouldn't want to try to reproduce it today LOL. 

[floobydust]

I can't code graphically any more, no way to stop me from laughing hysterically doing a Case statement. That is a classic dog's breakfast in LabView.
The zillion little tiles of graphical programming with miles of spaghetti interconnecting it all. 

Are LabView releases well-behaved now? The constant updates that would kill a test fixture were terrible in production. People would "just leave it alone", no upgrades to the test fixture PC  for years. Small changes here and there to the core functions that made your vi misbehave I remember were hard to track down.

[Gribo]

I am using LabVIEW for my day job, and as posted above, it can't make a bad programmer good, and I saw some horrible samples out there, including some of mine.
As for spaghetti code and extra large VIs, if you follow the style guide (as with any other language out there), refactor occasionally and run the VI analyzer your code will be more readable and maintainable.

[VK3DRB]

I created a set of coding standards for Labview in a previous job.

For example, the icon for a locally written VI had to have the background as black. NI never made icons with a black background. I tended to use graphical icons too (one of the few opportunities for an engineer to use any artistic abilities). One former colleague said he cannot make graphical icons because he has no artistic ability. The reality was he was plain lazy, which came to light by his aversion to doing any documentation. Having the background black allows anyone can easily see what is a locally written VI and what is a standard library VI. I did this because some idiot predecessor was modifying Labview standard VIs, and when the next NI update happened, the VIs broke. He should have been sentenced to installing Windows 95 diskette version during his lunch hour each day for one year.

Coding standards should be mandatory in every professional organisation developing code, whether it be C, C++, C#, BASIC, Pascal, Labview, or Labwindows. Having documented and adhered to coding standards should be part of IEC 62304.

They are also important for anyone doing professional PCB development in Altium. eg: library standards, layout standards for the company, schematic standards etc. These would be called, for example, "Altium PCBA Development Standards". I have also created these in the past. Library standards are extremely important, else you end up with KAOS rather than being in CONTROL.

[macboy]

Does anyone remember that a "Home" version was released 5 years ago for $50? While not free, the cost barrier has been mostly not an issue for some time, for non-professional use at least.

[joeqsmith]

Does anyone remember that a "Home" version was released 5 years ago for $50? While not free, the cost barrier has been mostly not an issue for some time, for non-professional use at least.

The last version I bought for home was in 2011.   $3000/8 years or $375/yr.    Prior to that, I had LV6.   I bought the Home edition when they offered 2014.  As I understand it, the Community version includes the application builder and won't be watermarked. 

vis created in older versions of Labview might not run on newer versions (sometimes you can’t even open them to edit or update anymore, they are gone for good).

Assuming you have the older versions of Labview archived, I would imagine you could port the code to the latest.    If you have an example that you care to attach, I can give it a try.   

[xrunner]

Assuming you have the older versions of Labview archived, I would imagine you could port the code to the latest.    If you have an example that you care to attach, I can give it a try.

Try this one Joe. It's one of mine from 2002. Has to do with calibrating a laser but I can't open it so I don't remember any more about it. 

[joeqsmith]

Assuming you have the older versions of Labview archived, I would imagine you could port the code to the latest.    If you have an example that you care to attach, I can give it a try.

Try this one Joe. It's one of mine from 2002. Has to do with calibrating a laser but I can't open it so I don't remember any more about it. 

Looks like it was LV 6.   If you supplied all of the files, I could easily port this to LV 2020 if you wanted.   

[joeqsmith]

Here you can see attempting to read Color Table Gen with the 2014 Home edition fails and so does 2011.   Still, version 6.x can import 5.x and once it's in 6, we can port to 2011 then to 2014 and up.  Again, it's not a big deal but EVERY file required would need to be included to port it. 

[joeqsmith]

A while back I came across this link:
https://xdevs.com/review/ti_ads1262_p1/

LabView often is tricky and not very reliable in operation, as even after just ~10 minutes of fiddling with various tool settings I got it to crash with error:
...
No further operation was possible until application was closed and reopen again. Sometimes it was just hanging without any error message.
Anyhow, let’s see what software allows us to do, when it works. Configuration of ADC and capturing data is simple and intuitive. For data analysis three main “tests” are available:

I suspect that this is fairly typical.  Someone supplies some poorly written code (in LabView or any other language) and the person trying to use it jumps to the conclusion that the language is the problem.  Again, LabView can't turn a bad programmer into a good one.    This person sidesteps the problem by rolling their own interface to the ADC.   

I ended up using LabView an ran it a bit over 10 minutes without any problems.

[xrunner]

Looks like it was LV 6.   If you supplied all of the files, I could easily port this to LV 2020 if you wanted.

Looks good - haven't looked at that for a long time. Appreciate you checking that it can still be opened!