National Instruments has incorporated off-the-shelf compiler technologies that execute code an average of 20 percent faster in LabVIEW 2010.It also adds access to a marketplace for evaluating and purchasing add-on toolkits for integrating custom functionality into the platform.
It is compatible with the Xilinx CORE Generator as result of a IP integration node that makes it possible to integrate any third-party FPGA IP into LabVIEW applications.
National Instruments has also implemented more than a dozen features suggested by lead users through the LabVIEW Idea Exchange.
Key to the productivity delivered by LabVIEW is the compiler, which abstracts tasks such as memory allocation and thread management. The compiler hierarchy has evolved over the lifetime of LabVIEW to become smarter and more optimized.
With LabVIEW 2010, the compiler data flow intermediate representation has been further optimized, and low-Level virtual machine (LLVM), an open source compiler infrastructure, has been added to the software’s compiler flow to accelerate code execution.
With the release of LabVIEW 2010, the LabVIEW Add-On Developer Program is being launched to give thousands of partners the opportunity to expand the platform and introduce custom functionality into LabVIEW.
The program establishes an online marketplace as part of the updated LabVIEW Tools Network for developers to offer their free and paid toolkits and a comprehensive location for LabVIEW users to browse, download, evaluate and purchase the add-ons.
More than 50 add-ons from NI and third-party developers are available, including code reuse libraries, templates, UI controls and connectors to other software packages.
Users can also use the VI Package Manager from JKI to connect directly to the LabVIEW Tools Network from their desktop and manage add-on installations and updates.
The company is working with technology providers such as Xilinx to further open up the LabVIEW environment. The IP Integration Node added in LabVIEW 2010 makes it possible for users to integrate any third-party FPGA IP into the LabVIEW FPGA Module and offers direct compatibility with cores created with the Xilinx CORE Generator.
NI says increasingly, engineers without FPGA
expertise want to use NI LabVIEW FPGA and NI FPGA-based custom hardware
for unique timing and triggering routines, ultrahigh-speed control,
interfacing to digital protocols, digital signal processing (DSP), RF
and communications and many other applications requiring high-speed
hardware reliability customization and tight determinism.
However, compiling FPGA code is an extremely long and
resource-intensive process that can take hours or days to complete. To
alleviate the need to dedicate a development machine to compiling FPGA
code, NI is working to help LabVIEW users offload FPGA compiling to the
cloud; in this process, LabVIEW users can seamlessly use powerful,
dedicated remote computers to compile their LabVIEW FPGA code, freeing
their development machines to be used for other purposes.
Fourteen popular submissions from the LabVIEW Idea Exchange were implemented in LabVIEW 2010 including many that improve code documentation and organisation. These include increasing the default maximum number of UNDO steps per virtual instruments from 8 to 99 and the automatic creation of wire labels as well as reducing the number of mouse clicks required to move switch items in the connector pane from 8 to 2.
LabVIEW now also provides a hardware configuration tool that makes it possible for users to access and configure their LabVIEW Real-Time targets remotely via a Web browser. Other features include a smart installer that automatically detects the software associated with a serial number for faster installation and an improved instrument driver finder that offers prebuilt project examples for specific instruments.
Interfaces have been improved to reusable code, group VIs and their hierarchy for faster build times and separate the VI source code from the compiled version to aid in source code management. These capabilities are suitable for large group development where code maintenance across many users, software versions and computer platforms is critical.
I would really like to see the FPGA capability opened up so that LabVIEW FPGA will work with ANY board containing a Xilinx FPGA. I could have really used it with the current project I'm on, but we're not going to buy the NI FPGA hardware to accomplish the relatively simple signal generation I'm needing for our test stations. I'm using $79 boards from Digilent for that. So, that forces me into doing low-level HDL coding. But, it's not all bad since it forces me to learn the language and low-level processes (which I've never done before).
National Instruments today announced LabVIEW 2010, the latest version of the graphical programming environment for design, test, measurement and control applications. This is great news for this company! If National Instruments want to really take off, it is recommended that management offer discounts to institutions of high education (since enrollment is up around the US) to use within programming classes. This sounds like one of National Instruments best product.
I find good use of Mathworks, but in most cases, you notice that you need LabView. But it all works out when these behemoth and dominant players in their sectors have to compete for my attention. It helps price. The whole concept of open source is great, but I always find out that the best of open source does not come free. Ask the people that support Linux and allow IBM to make billion dollar profits out of that.
I tend to use LabView when connections to breadboards or lab instruments are a priority. LabView makes it pretty easy to get up and going. I use MATLAB as a sort of FORTRAN on steroids, if I want to do an analysis suited to procedural code. I would also use Simulink if simulation is required. LabView can certainly do a lot of simulation; MATLAB and Simulink can be connected to hardware. Both will drop C-code. But my "division of labor" is much as I first stated. My typical projects are designing nondestructive ultrasonic testers, so controlling our own hardware and instruments is easiest with LabView. But I will often do the initial signal analysis in MATLAB, with a drop into Simulink for any simulation. If needed, I run both tools together, but that's usually overkill: I'm just being lazy, not translating something from the one to the other. If your project is very large, and you need to do hardware and software co-design, particularly with plants with mechanical components, then Simulink will do it. I don't have experience (yet) with LabView on larger co-design situations, but it seems that LabView has many of the features needed for large-scale architecture.
Bob: maybe you can elaborate on the nuanced differences. For instance, are certain applications better suited using NI tools and others using MathWorks tools; or is it a performance issue across most applications. Where do you use the NI tools and where the MathWorks tools?
It's rather fun to watch two behemoths, National Instruments and The Mathworks, position their products. You get the impression that they are motivated by two things at least: useful extension of their products' capabilities, and cutting into their competitor's market. (Profit, of course, goes without saying.) Both are good things. However, the application domain for these two companies overlaps: hence you see the curious relationship between the two: sometimes cooperative, sometimes competitive. It's fun to watch, and the result is a win-win for the user: each product becomes better for the competition. (For the record, I was a Mathworks employee for a short period, and I use both products constantly.)