Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

Any news on 64-bit LabVIEW for Linux?

I've been really pleased with the Windows 64-bit LabVIEW running on Windows 7.  I'm working with mulitple digitizers that can generate 200MB/s at 100MS/s, so the extra memory cache is great for dealing with the system interrupts and not losing any data.  We've been able to achieve 4 streams (2 per thread), but it looks like it could handle more.  Unfortunately, many in the military domain are more comfortable with Linux like Fedora and CentOS so they would like my project to operate in one of those environments.  I have been able to get by with 2 streaming channels to operate on Windows XP 32-bit, but it was pushing the 4GB memory limit.  For DOD business, I would like to see National Instruments update the Linux LabVIEW for 64-bit shared object (SO) support.  Anyone heard if NI is working on a solution?

Message 1 of 22
(17,585 Views)

I have no new information about 64-bit LabVIEW on Linux. However, it sounds like your use case may be a better fit for a realtime system. Have you tried using LabVIEW RT for this application?

0 Kudos
Message 2 of 22
(5,956 Views)

I've heard from some inside sources at NI that they're re trying to push existing users to shift from Labview on Linux to Labview RT. I don't think Adam's comment is quite up to the spirit of this forum, on trying to push for Labview RT on a deployment which calls for a 64-bit version of Linux. The OP has clearly mentioned his and his customer's preference for a RHEL/CentOS based solution.

I would appreciate if Adam gave an honest answer on a 64-bit solution for Labview...rather than try to push a user towards RT.

Just my 2 cents

0 Kudos
Message 3 of 22
(5,956 Views)

AdamKemp wrote:

I have no new information about 64-bit LabVIEW on Linux. However, it sounds like your use case may be a better fit for a realtime system. Have you tried using LabVIEW RT for this application?

Adam, while I almost always appreciate you remarks very much I do think you missed the boat here a little. What would LabVIEW RT help here with a system that clearly pushes the 4GB memory limit? Is VxWorks or Pharlap ETS going to support >4GB of memory anytime soon? And in the case of VxWorks, does NI have a RT hardware platform that could make use of such a 64 Bit RT OS?

As to the original post, I wouldn't hold my breath for it. NI has a rather hard nut to crack before they will even think about releasing a 64 Bit version of LabVIEW for Linux (or MacOS X for that matter). I'm pretty sure that porting LabVIEW isn't even that much of a problem. Most of the work has been already done (x64 compiler support, Linux OS interfaces, 64 bit safety in the code base, etc). However LabVIEW without hardware drivers is definitely not interesting to enough people that it could make a business case for NI. And seeing the state of Linux support for different hardware for the 32Bit version, you know that NI has still some work to do, before they can think about adding a 64 bit version to it. They have come up with a driver architecture that worked initially fairly well, until the kernel guys decided that closed source kernal drivers are a violation of the GPL. That threw off the entire DAQmx and other hardware drivers to be a continous catch up race with the ongoing kernel changes. Opensourcing the kernel drivers is obviously something NI has a lot of troubles with, partly because it documents quite a lot of the hardware architecture, which does contain some precious technical knowledge. The data acquisition market may have changed a lot, but there are people around who in the past have taken blue prints of competitor hardware, copied them to the bit, and sold them for a fraction of the price, pointing their users to the driver download of the competitor when asked for software drivers. While some may find that legitimate business in the interest of low price products, I don't and NI has of course every right to try to prevent such a thing from happening.

So before they have solved the crisis in their hardware drivers for Linux, and non-Windows in general, I don't expect to see other LabVIEW platforms released anytime soon.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 22
(5,956 Views)

rolfk,

You've addressed some very important points in your second paragraph. Majority of the companies wanting to provide drivers for Linux have come up against the GPL license of the Linux kernel. However, there are a few like Nvidia which provide binary-only drivers which can be installed on pretty much *any* distro. They are also very quick at updating their drivers with their product releases. I believe NI can look into the Nvidia model of providing a single "*.bin" which will run under any Linux kernel.

The best solution is, of course, to open source the drivers. But I can understand business considerations behind them (licenses, IP, patents etc)

0 Kudos
Message 5 of 22
(5,956 Views)

By using a real time OS, I would be concerned about the hardware drivers such as for my digitizers.  It seems that vendors are struggling with maintaining shared libraries for Windows and Linux.  I do not hear about many of them using LabVIEW RT.  I'm experimenting with the TESLA GPU's.  Would LabVIEW RT work with the NIVIDIA CUDA libraries?

0 Kudos
Message 6 of 22
(5,956 Views)

My response was honest. I am not in sales. My goal here is not to sell you hardware. I don't personally benefit from that anyway.

The original post mentioned that they were struggling keeping up with more streams because of interrupts from the OS. A real-time OS would reduce that problem significantly. That's a legitimate reason to use RT. The reason he's pushing the memory limits is because he needs larger buffers to counter the potential hiccups caused by the interrupts. With a real-time OS you don't need buffers quite as large for each stream, so you actually end up using less memory.

Again, I'm not here just to sell you hardware, but the post described a problem that I honestly think could be solved better by an RT system than by a Linux system.

As for drivers, my assumption was that you were using hardware that NI supplied. If you're not then you do have to worry about driver support on RT.

Our abVIEW CUDA support is documented here, but it's currently only available on 32-bit Windows. That would be a problem for you on Linux as well unless you roll your own LabVIEW integration. In that case you could do the same for RT.

0 Kudos
Message 7 of 22
(5,956 Views)

I like NI hardware, but their PXI equipment lacked RF preselector filters and their RF channel bandwidth was only 20 MHz instantaneous.  I'm achieving over 40 MHz per PCIe digitizer channel married up with an external wideband tuner.  The PCIe dual digitizer cards can hit 180MS/s, which reduces me down to only one channel but makes a great radar measurement capability.  With the 16TB RAID array, I can record 11.6 hours for up to 500MB/s.  This is all common COTS equipment, so the price for a dual 40 MHz system is about $25K while a NI PXI setup costs around $100K.  As you can see, there's an economic advantage for my hardware selection.  I would love to see NI release a similar PCIe digitizer card married up with a user programmable FPGA, but they are staunchly sticking to their PXI form factor.  NI recently purchased the GNU Radio hardware from Ettus, but they are building LabVIEW libraries in Windows and just started releasing beta VI's so I'll keep an eye on its progress.

Back to the GPU, I implemented the 32-bit LabVIEW CUDA example and learned that the 64-bit libraries are different so as you mentioned I'm having to roll my own by using the Function Call tool to exercise the NVIDIA DLL's and SO's.  NI might consider creating these libraries and sell them as a separate tool box.  Because of all the work, I'd buy them if not too expensive.

For software defined radios, get prepared for a lot of data so that's why I'm pushing for a 64-bit LabVIEW solution in Linux.  I've seen millions of DOD dollars going to LabVIEW purchases, so I hope they are paying attention or MATLAB may start taking a bite out of their market share.

0 Kudos
Message 8 of 22
(5,956 Views)

Yes, Is there any more news on 64-bit Linux LabVIEW?

I am using LabVIEW 32 bit on linux, but am likely to have to get away from LabVIEW since it cannot handle large matrices for 3D and 4D (time seires) images. Our environment is academic, and Linux is the prefereed platform, especially for large memory, high core count servers.

Curt Corum, Ph.D.
Center for Magnetic Resonance Research
University of Minnesota
0 Kudos
Message 9 of 22
(5,952 Views)

LabVIEW has always had problems with large scale arrays, so I've had to build my own C/C++ libraries.  We have had some success with streaming blocks of arrays up to 4.096MBytes from a digitizer via an Altera Stratus FPGA.  I originally used MS Visual Studio 2008, but now I'm using GCC in Linux so hopefully it will not be a problem.  We recently loaded CENT OS 6 32-bit on a machine with 32GB of memory and it detected all of it.  I wonder if you created two different LABVIEW executable applications, I wonder if they would get assigned different memory allocations.  In cases where they share data, you may need to create virtual IP ports.  In any case, NI wants to stay in the market and many folks are shifting over to Linux so they eventually will have to support Linux in 64-bit.  Good luck and lets keep the pressure on NI.

Message 10 of 22
(5,951 Views)