64-bit LabVIEW for Linux? (Any word?)

[Jeff2]

Hi everyone,

I know this has been discussed before but I thought I would check in and see if there is any news of a 64-bit version of LabVIEW for Linux under development.  I've taken the advice here and notified our local rep of our interest, although he didn't seem very interested to hear anything about Linux.  Hopefully it filtered back to the right people.   Thanks.

[AdamKemp]

Not much has changed. We are still interested in hearing about compelling use cases, but any decision to move forward on it will have to be based on how much demand there is.

[larshana]

have a dll that i want to convert it to .so file so that i can use it in Suse Linux by calling it through Call library function.Suse linux version  that i use is 64 bit.so is there labview version of linux for 64 bit?cos i will be compiling the c program in linux which creates a .so file of 64 bit format, but i think i have labview of 32 bit,so can i call the 64 bit .so file in 32 labview linux version?

[AdamKemp]

As Rolf pointed out in another thread, 32-bit LabVIEW can only use 32-bit shared libraries. You should compile your .so on Linux as a 32-bit .so. If it comes from a 3rd party then see if they have a 32-bit version. Most likely they do because not everyone uses 64-bit Linux.

[kentyman]

Additionally, if you need a way to communicate with a 64-bit shared library today you could run a 64-bit process that loads the 64-bit library, then communicate to this process through any inter-process communication (IPC) technique, such as shared memory.

[larshana]

so is there no 64 bit version of Labview linux? cos my system works on 64 bit linux only,some features are not available on 32 bit..thats the reason..

[AdamKemp]

No, there is only a 32-bit version of LabVIEW for Linux.

[Jeff2]

I'm not sure what would make a compelling case, but I can give you my situation.  We process data sets that are larger than the 4Gb limit placed by 32-bit applications.  It's necessary to load our data into memory at which time we operate on it.  We are at the point where we are looking at other software packages to do the job, something I would rather not do as I prefer LabVIEW.  However, many offer 64-bit versions of their Linux software.  I can see from the data acquisition side that 32-bit would be fine, but is seems LabVIEW can do much more than that, e.g, modeling, image processing, and displaying complex and large data sets.  These areas are often memory intensive.  As our lab has moved into these areas, I can see how the memory limitation of 32-bit software becomes a major problem.  Maybe I'm an isolated case, but I have a feeling I'm not.  I would think as time passes, larger data sets will be more common as computers can easily handle them and people have a choice to use them. 

[Curt_Corum]

Looks like this thread has died down.

I will second Jeff2's last post. I use LabVIEW for some very large datasets (3d and now 4d) for MRI image reconstruction and signal processing. Up until now I have been happy with the capabilities of Linux LabVIEW. Recently I am moving into processing larger matrix sizes and multiple channels of data, and running out of memory. A 64-bit Linux LabVIEW would solve these issues, and open up another market for LabVIEW in high performance numerical computing.

In addition I would like to call 64 bit .so files directly (many seem to want this feature, especially academic users, in other posts/forums). This would again greatly add to the flexibility of Linux LabVIEW as a high performance numerical platform.

Unfortunately system stability and interfacing to other code bases makes it highly undersirable to switch to vista just for 64-bit LabVIEW and I am being driven toward abandoning. The functionality is worth enough to me to pay a premium (64 bit Toolbox?) for Linux labview in order for NI to make the investment...

[rolfk]

The most compelling case for NI would be a "significant" number of users telling them I will buy so many 100 LabVIEW for Linux licenses if a 64 Bit version is available. And no, 10 or 20 professional licenses (at the full price not the discounted educational price) won't likely be considered compelling. Eventhough the LabVIEW source code is written with multiplatform in mind, it's a large source code base which takes quite a lot resources to make sure it will work on a new platform. That is not something to be done in a few days of reviewing the source code for problematic areas and then adding a few more days for testing.

Another problem would be the fact that even a 64 bit LabVIEW version would be of limited value to many users, without an according 64 bit DAQmx, NI-488.2 and NI-VISA driver,