Complete newbie: Linux, and writing drivers...

[Matthew Percival]

I have spent a bit of time searching this forum, and reading over a good deal of older posts to get an idea of things.  I am completely new to LabView --- I have not even used it yet --- but am looking to get to know it better in the near future.

My first questions relate to LabView on Linux.  I have read a few posts about the differences between the Linux and Windows versions, but these were fairly old.  Is the Linux version still lacking compared to the Windows one, or are the differences fairly small now?  In addition, there are a few pages which state that Debian is a supported distrobution, but the FAQ does not list it: is that a simple oversight?  My work system runs Ubuntu (a Debian-based distro), and I would like to stick with that if possible, but if I would be better off using the Windows version I can access a Windows system.

I have also been looking into writing LabView drivers for accessing dedicated hardware.  Most of what I have seen and read so far relates to drivers written in LabView, however, I have read a little about then being written in several other languages.  Is there anywhere I would be able to get the source for any drivers written in C, so I can see what exactly is involved in writing one.  I find it a lot easier to understand these kinds of things by looking at examples, rather than explanations (with is the bulk of what I have found so far).  If I can see examples written for both Windows and Linux, that would be even better --- that way I could understand the differences between drivers for these two operating systems.

[Norbert_B]

Matthew,

LabVIEW for Linux is quite the same as for Windows, except of course that OS-specific functions do not work (like registry-functions). All other features should be available in Linux as well, but i must confess that i have worked only a little with LV for Linux.
Regarding the distributions, Debian is not officially supported by NI. The supported distributions are SuSe, RedHat and Mandriva (formerly known as Mandrake). Debian was under discussion as to be supported, so i think this is the reason why it showed up in the pages. In fact, Debian seems to work for most applications with LV, but if there are problems, Debian is not a good choice.....
The question about drivers is not easy to answer since there are two possible circumstances. First, there are so called "instrument drivers" which work on VISA (Virtual Instrument Software Architecture), which is OS-independend and therefore you could use the same instrument driver in Windows as in Linux. These drivers are used to communicate with external instruments which are most commonly connected via RS232 or GPIB. They are written directly in LV.
Hardware-drivers for other hardware components are usually written in C/C++ and delievered as DLL in Windows. Since DLL is a OS-dependend technologie, this does not work in Linux. Linux has a similar method where the library is called "shared object"(so). You can call these so's in Linux in the same way as in DLLs in Windows: by a special function call node. You can connect the node to the shared object and call the appropriate function.
Sources for drivers written in C are most often not available.

Norbert B.
NI - Germany

[LV_Pro]

The key statement in the previous post is the one about Linux not having the Windows O/S specific functions. He glosses over that a bit to quickly. LabVIEW for Windows has a lot of features that aren't available in the Linux version, some that may be important to you or not. Obviously all of the ActiveX and presumably .NET functionality, the report generation features that expect MSOffice components, and some others that aren't coming readily to mind. If you are using instrumentation, writing drivers for them is not impossible, and in fact is fairly straightforward. National Instruments' support for their boards under Linux is growing, but I would really search closely whether your current or future hardware is/will be supported. I am not a great proponent of Windows vs OS-X, Linux, etc., but NI has devoted a lot more money in developing for the Windows platform. That being said, if you can do what you need to in the Linux environment it does bring all of the positives usually attributed to it, just with, as usual, a little more commitment in development work and knowledge.

P.M.

[LV_Pro]

One more thought. If the work is for your own "in-house customer" Linux may not be a problem, but if there is any expectation of an external distribution of the final product there are still a lot of companies that are Linux phobic so you might have to get LV for Windows to recompile for them.

P.M.

[Matthew Percival]

Thanks a lot for these replies: this clears up a lot of things I had been rather hazy on.  In regard to which OS, it sounds like I will need to have a Windows version on hand --- if only to compile things so they can run on Windows.  Now that I have worked this part out, I can actually get myself a copy now!

As to drivers, that there are two different kinds makes things a great deal clearer: I had been coming across both kinds, but thought there was only one, and this lead to a little confusion for me.  I have seen quite a number of these `instrument drivers', and once I get a copy of LabView I shall take a closer look at them.  I will need to get a better understanding of `device drivers', however.  Since the source to them is not generally available, are there any good guides to the creation of them that can be recommended?  Also, does anyone know if the differences between the code for a dll and the code for an so are numerous, or would writing both only be a fairly simple task?

Thanks again for the help, as I feel I have a much better understanding of these topics than I did before.

[LV_Pro]

A couple of things to clear up (or muddy up!). LabVIEW "compiles" its code the first time you run it after loading or changing code. It doesn't, at this point, create a file that can be executed on another computer without the development package. To do that you need to purchase the Professional Development package, or one of the lower versions and the Application builder toolkit. This toolkit creates an installation package that includes a ".exe" file. To run it you will need to install the LabVIEW runtime engine on the target machine. This can be done by the installation package created by the application builder, if so configured. The runtime engine is a fairly big package in version 7.1, and this causes a lot of comments by the VB and VC++/.NET folks, but the truth is they also have a runtime engine requirement, theirs is just automatically installed as part of Windows.

Instrument drivers, for standalone instruments (GPIB, serial, etc.), usually do include the source. In the current (this does not apply to IVI drivers, they are a whole different category) method of writing these types of drivers, calls are made to some LabVIEW resources that use what are called VISA functions. VISA is a technology that provides a level of abstraction between us and the actual hardware port (GPIB, serial, etc.) Most of these standalone instruments are setup, programmed, read, using commands that consist of ascii strings. So drivers in this case are functions that convert settings for instance into the appropriate string of commands, i.e. "RB 3000000HZ;VB 1000000HZ;VAVG OFF;VBR 0.300000;" sets the resolution bandwidth, video bandwith, video averaging and video bandwidth resolution on a HP859x series spectrum analyzer.

For the National Instruments cards LabVIEW comes with a bunch of tools to make talking to them easier, it still being at a relatively high level of abstraction, where a settings, etc. are passed to and from some built in function. The problem comes with boards from other vendors. There you are at the mercy of drivers they supply, as obviously National Instruments is not going to devote their development resources to drivers for hardware from competitors. The drivers from the other vendors range in quality from pretty good to what looks like it was written by the new hire engineer that had a copy of LabVIEW dropped on their desk and were told "we need some LabVIEW drivers for the biphase framistat by next Friday!".

P.M.