A long time ago, I learned a lot about UNIX — first, as a programmer at a well-run BSD shop, and later after joining NI, by becoming NI's system administrator for our lone Sun 3/160 workstation. (That was in addition to my real job of being a LabVIEW programmer.)
I've also been heavily involved in the UNIX/Linux flavors of LabVIEW... initially LabVIEW for Sun, and later, LabVIEW for HP-UX, LabVIEW for Concurrent PowerMAX, and LabVIEW for Linux.
So with great interest, I've noticed several new Application Notes from Agilent about Linux, the most recent of which is Using Linux to Control LXI Instruments Through TCP.
While these app notes provide some useful information, they typically show you how to do things the hard way. With NI software, things are much easier...
For example, in the above-mentioned application note, you get to learn about socket calls, network byte ordering, and Nagle's algorithm for packet consolidation. In another application note, Using Linux to Control LXI Instruments Through VXI-11, you get to learn how to program remote procedure calls and the XDR format for data representation.
NI and Linux
One of the benefits of National Instruments' software is that we actually have Linux versions of LabVIEW, the LabWindows/CVI Run-Time Module, our I/O Libraries such as NI-VISA and NI-488.2, and some of our other device drivers such as NI-DAQmx.
So instead of having to learn how to write your own I/O libraries, and how to use the GNU Compiler Collection and debugging tools, you can work at a much higher level in a graphical system design language.
Instrument Drivers
LabVIEW is a portable language, which means that the functions (VIs) that you write can be moved from one flavor of LabVIEW (e.g., LabVIEW for Windows) to another (e.g., LabVIEW for Linux, or Macintosh, or Real-Time) and function correctly. There are a few caveats to this... Not all real-time targets have hard disks, so the File I/O functions don't work there. Another example: VIs that use OS-dependent technology, such as IVI-COM drivers that depend on Microsoft's ActiveX technology, are not portable.
So what to do about instrument drivers? Agilent, in their application note Using Linux in Your Test Systems: Linux Basics suggests "in most situations you do not need an instrument driver." While true, it sidesteps the issue that instrument drivers are really valuable, since someone else has developed and debugged the code that deals with the nuances of specific instrument models.
Fortunately, the National Instruments Instrument Driver Network contains thousands of LabVIEW Plug and Play instrument drivers. These instrument drivers will work on Windows, Linux, MacOS X, and LabVIEW Real-time — anywhere you have both LabVIEW and VISA.
What about IVI? All IVI drivers are Windows only, but there's a way to get IVI-C drivers working on Linux. They're no longer officially "IVI", but it can be done. NI has an article entitled Porting IVI-C Specific Drivers and Applications to Linux that describes the steps.
So to summarize, if you like doing things the hard way, the Agilent application notes lay out a nice roadmap. The rest of you might want to consider NI's Linux products. To learn more, see ni.com/linux.
6 comments:
Hi Brian,
I think you missed the point. The point is that you can choose whatever environment you please and make whatever tradeoff of "program your own" vs. "buy vendors tools" you want. Not everyone wants to restrict themselves to the supported variants of Linux and the pricing and usage policies of an applications vendor. No one would argue that there are useful programming environments and tools from NI and others, but not everyone wants to follow that path. Furthermore, no vendor is willing to release versions of their application software for each build of Linux.
The article makes it clear that using TCP isn't the same as buying an off the shelf package. Customers who want to use an open environment and already know how to use the Linux developer tools have the alternative to choose whether they want to purchase their tools or develop their own.
Chris Van Woerkom
Agilent Technologies
Well, I guess we've heard that before, haven't we? LabVIEW is some kind of "world formula", no matter what your requirements are, you have to use it?
A lot of users decide not to use LabVIEW, especially those using Linux. Maybe it's because LabVIEW is not open source. Maybe it's because LabVIEW is not supported under their favorite distribution. Maybe it's because LabVIEW is not so easy to use after all.
Anyway... The average Linux user is not interested in ease-of-use alone. These people want openness, long-term stability, flexibility, freedom... If ease-of-use is your top concern, use Windows... And while you're at it, have a look at Agilent VEE.
If ease of use is your top concern, use a Mac, not Windows. LabVIEW and NI-VISA work on the Mac, too.
First of all, thanks Chris, Stefan, and our anonymous Mac friend for commenting. Specifically, I'm glad to hear the Agilent perspective from both Chris and Stefan.
I have to agree that if the point of the Agilent whitepapers was to present a balanced perspective on "off the shelf" vs. "do it yourself", I missed that point.
Chris, I went back and quickly skimmed those white papers again, and I still don't see where you suggest that there's an easier way, even if it costs money.
I did sit through Stefan's PowerPoint presentation a few weeks ago, and as I'm sure he'll recall from my questions, he didn't mention any commercial alternatives.
I didn't want users to come away thinking "support for Linux" meant a few white papers. There are commercial alternatives from NI that consist of real software, available now, and proven in the industry.
Hello there,
I know this article is old, it still pops up high on the search list for "LXI linux" though so I thought I'd add comments on the alternatives to LabVIEW for controlling LXI devices on Linux.
In June 2006 we bought a new oscilloscope and wanted to control it from Linux. We looked into using LabVIEW (on Linux) and found that (a) it only worked on PCs with 32-bit operating systems, and (b) there's a 2 second pause between starting a program and initialization completing (which makes it useless for scripting). (a) troubled us deeply. "64-bit PCs have been out for a few years," we thought (in 2006), "we don't want to limit ourselves to 32-bit, that's crazy! Well, maybe they'll do a 64-bit version soon, we'll reconsider then."
In late 2010 there is still no 64-bit version of LabVIEW on Linux.
So in 2006 I wrote a tiny, light-weight, open source VXI-11 protocol library for Linux. It has open, close, send and receive functions. If you have the programmer's manual for your instrument (detailing the SCPI/GPIB commands) you will be able to communicate with your instrument from Linux (I've done user libraries for a couple). The code is available at: http://optics.eee.nottingham.ac.uk/vxi11
Shortly after I wrote this, Stefan Kopp's excellent application notes appeared - these would have been really useful while I was writing it!
The code has been stable for a number of years, it works on 32 and 64 bit Linux systems. Someone wrote to me last week to say they'd successfully compiled it under Windows/Cygwin and provided a patch, which I posted the next day.
If you are looking for a Linux solution that is part way between working from scratch from the Agilent Application Notes, or purchasing LabVIEW (and putting up with crippling your PC to 32-bit) then the light-weight VXI-11 code might be a good starting point. It doesn't do nearly as much as LabVIEW does, but then there are, in total, less than 1000 lines of code, and a fair portion of that is comments.
I used your code... and nowadays it is harder each day to find SCPI compliant devices. They just give the driver for Windows and that's all... no GPIB commands, no SCPI commands, no way to refuse the proprietary code :(
Post a Comment