Why use LabVIEW on Linux?

[DFGray]

CERN runs its new accelerator on Scientific Linux using LabVIEW.

[Yamaeda]

With Win XP shutting down, i take it Embedded is soon to follow? So, are companies gonna switch to some W8 embedded or a linux version? With Steam also using Linux in their box i guess it'll reach alot higher acceptance.

In my first job we used Unix servers and windows clients. It's not very common to see mixed systems today, but it's fairly common to have mixed systems "under the hood", as many virtual servers are run on BSD/Unix boxes.

/Y

[Yamaeda]

So, basically you're asking the wrong question; It's not about "Why use LV on linux?" but rather "Why use Linux?", since if you're using Linux and want to use LV that's the solution. 😄

/Y

[rolfk]

The major Linux user base for LabVIEW are universities and university related research projects. Even CERN falls basically in this area. They have great Linux experience, and can handle the problem of having to startup a command line shell if something needs to be changed. And they are mostly on special license deals with NI either on educational licenses or on special site licenses. This is also the weak point about LabVIEW for Linux since the pure sales figures look not that great. The revenue compared to the number of installed seats is a lot lower that way than under Windows. So there is always an uphill battle to have the necessary resources allocated.

LabVIEW for Linux started as an internal project way back around LabVIEW 5 mainly as an exercise to see how portable the LabVIEW source code base was. They had the X Windows interface from the Solaris version, Posix/Unix interfaces from both Solaris and HP Unix and a lot was basically written on top of those interfaces in a platform independent manner. Trying to see how much effort it took to compile and make it run on Linux was an interesting proof of the portablity of the code. It was fairly easy to get it running but turns out to be fairly expensive to maintain it and keep it working with the ever changing Linux environments, especially a complex project like the DAQmx kernel driver environment. Once the internal LabVIEW for Linux prototype was running NI had a tough time to decide what to do with it. They initially denied even it's existence everywhere despite having it running internally. Eventually they released it but it has always stayed a side project that was mostly maintained because of the strong educational demand, not because of direct commercial considerations.

And due to the somewhat complicated license issues with Linux, and the changing architecture of the kernel, driver support turned out to be quite a nightmare. This makes LabVIEW for Linux even more of a problem since LabVIEW was traditionally always an enabling technology for NI to sell hardware.

With LabVIEW for Linux RT it is likely that we will see more and quicker changes of the whole LabVIEW for Linux system, but it will likely stay a small fraction of the overall LabVIEW sales, though with the cRIO platforms bringing in hardware sales the allocation for resources for support of LabVIEW for Linux will likely turn out to be easier.

However even if we will see DQAmx and similar support for LabVIEW for Linux RT on their cRIO controllers, it does not have to mean that it would change much about general support of these drivers for mainstream Linux. The monolithic Linux kernel with its open source requirements and various variations across different distributions makes it rather hard to have a good DAQmx or other driver that will work on all major distributions without open sourcing the entire driver, which NI seems to have no intentions to do. And even open source DAQmx won't make the situation much better as most users are not in the business of adapting any open source project to their own environment, especially a whole kernel driver environment like DAQmx. On NI Linux RT they have control over the entire system and can much more easily develop a driver that will simply work out of the box, as the user or a distribution builder can't go and make all kinds of changes to the NI Linux RT system itself.

[PaulG.]

---

@NIquist wrote:

---

@MrQuestion wrote:

If NI is selling LabVIEW for Linux who are their cusotmers?

---

Perhaps foreign companies who don't want an OS with a backdoor the NSA can open any time they want???

---

I sometimes email a PDF copy of the US Constitution to myself on the off chance the NSA might read it.

[MarcoMauri]

The company I used to work with used to sold status displays for photovoltaic plants based on Linux.

We chose Linux for the following reasons:

-  no licence fees

-  very limited hardware requirements (->system cost reduction)

-  very stable and secure OS

The SW was developed with Labview for Windows and then ported with no effort on the Linux box.

Regards,

Marco

[ramktamu]

Open Source is way to go

[rolfk]

It's not a nirvana at all. There is a lot of Open Source in the LabVIEW world already but there are many who want to consume and much less who are willing to contribute. That takes out all the momentum of any Open Source initiative.

[MarcoMauri]

---

rolfk ha scritto:

That takes out all the momentum of any Open Source initiative.

---

This is not true, and there are a lot of examples out there.

We are not speaking (only) about single indipendent developers but about companies (it's often cheaper and more effective to contribute to an Open Source project then starting from scratch with a closed source approach).

And don't forget that among the ones that "want to consume" there are the contributors of the future.

Marco

[thoult]

There's one obvious reason why NI are switching to Linux RT: cost.

Every time NI sells an embedded system running VxWorks, they have to pay a license for each one, plus seats for a development system. No such issues with LinuxRT.

Another benefit I can see is portability, for the reasons MrQuestion outlines - a greater number of development tools, ability to run a wider range of code on the target.

From an end-user point of view, we will upgrade cRIOs and sbRIOs to LinuxRT versions when available because of the increase in DMA channels. We use DMA FIFOs a lot, and would always love to see more, rather than having to consolidate channels for mixed use into a single one and then sort it out at the host end afterwards. We've got from ~3 channels to >10 (can't remember, but I think it's 13 or 15 or something) when upgrading to the new cRIO system.

(Also, the controller in it is physically tiny now!)