calling 64-bit dll from labview 8.2 on Windows7

[albartp]

Hello,

I have tried the LABview driver from the OMNIDRIVER (OceanOptics) package. But when calling functions from the “OmniDriver32.dll” , LABView is crashing and  says that the memory is corrupted.

I am using LABVIEW 8.2 (32-bit) running on Windows 7 (64-bit).  I have tried some LABView code examples given for LABview 7.1 and 8.0. These example are using the OmniDriver32.dll (not the OmniDriver64.dll).

But maybe these example are assuming that you are on a 32-bit operating system, which is not my case.

So I have tried calling the OmniDriver64.dll. but LABView seems not to recognised the dll and can’t read the included functions.

Is there a way to call some 64-bit dll from LABview 8.2 ?

Or do I need to buy a new license for LABVIEW 64-bit ?

Thanks,

Pierre

[Rob65]

Pierre,

you can not call a 64 bits DLL from a 32 bits application.

In 64 bits windows 7 application are either running in 64 bits mode, using 64 bits DLLs or in 32 bits mode using 32 bits DLL.

So 32 bits LabView will only be able to use 32 bits DLL.

Don't get confused by looking at the system DLLs: For backwards compatibility the system stores its own 64 bits DLLs in the \Windows\System32 folder. When a 32 bits application opens e.g. \Windows\System32\mfc42.dll (the 64 bits DLL), windows will instead use \Windows\SysWow64\mfc42.dll (the 32 bits version).

I'm not sure how this works when using your own libraries with LabView - Although I am running 64 bits Windows, I am still using 32 bits LabView using our own 32 bits libraries.

Rob

[rolfk]

There is no virtualization support for DLL bitness issues outside of the Windows standard directories. The Windows and System directories that an application "sees" depends on its bitness. All other directories are not mapped depending on the calling process' bitness.

So if you have installed 32 Bit LabVIEW and are not calling one of the system DLLs, you have to point the path of the DLL to the real 32 bit DLL. Pointing it to a 64 bit DLL should not even be able to get the VI compilable, since Windows will refuse to load the DLL into the 32 bit process as being an unknown file format, and that should make the VI broken.

If you need to call a system DLL you simply enter the DLL name without path and Windows will find the according DLL for LabVIEW.

[ThiCop]

Hello Rob and Pierre,

A few important things to keep in mind:

- LabVIEW 8.2 does not support the Windows 7 (64 bit or 32 bit) OS.

The reason for this is that version 8.2 predates the release of Windows 7 (second half 2009).

- Since LabVIEW 2009 SP1 Windows 7 (32 and 64 bit is officially supported).

- Since LabVIEW 2009 there exists a 32-bit and a 64-bit version of LabVIEW.

To answer your question, this gives an easy summary:

http://digital.ni.com/public.nsf/allkb/6C2CEE5925B8C1B08625721A00731B5E

Regarding the need to upgrade or not I cannot tell this at this moment.

I need some more information:

Which active licenses do you currently hold? (don't post the serial number on the public forum)

Do you have a valid license that contains LabVIEW 2009? (SP1 preferably)

[albartp]

Dear Thierry,

I have a licence for:

Product:                   LabVIEW Full Development System
  Version:                   8.2

Can you give a quote for the upgrade to LABVIEW 64-bit ?

Pierre

[ThiCop]

Hello Pierre,

I cannot give a quote, because I'm not part of the sales department.

The best (fastest) thing you can do is call our local branch office (info at ni.com/contact) and my colleagues will be able to help you further.

If you prefer this, then you can of course also e-mail us.

Are you able to find the right contact information?

If not, then please let me know about your location.

This way I can provide you with the correct phone number.

[DFGray]

Getting back to your original problem, you should be able to call a 32-bit DLL from LabVIEW 8.2, even if using a 64-bit OS (even though it is not officially supported).  The most common cause for the problem you describe is not setting the call library node up correctly.  Double check all your data types in the call library node to verify that they are correct.  It only takes one to crash LabVIEW.  Note that this can be harder than it seems.  Many times, the root data type of a variable is buried behind multiple #defines (or the equivalent) in the original code.  I have mistaken 64-bit integers for 32-bit integers - and the code worked... sometimes - then crashed.  Good luck.

[Rob65]

I agree with DFGray.

I am using 32 bits labview 2007 - 2011 on Windows 7 64 bits and use (32-bits) DLLs all the time.

I did however come upon this post in the NI forum about the omnidriver package where some users mention it is unstable.

LabView does a nice job in catching errors in DLLs and this sometimes means that an error that is not caught in a standard windows application is resulting in an error situation in LabView.

Please note that this is due to an error in the DLL and not in LabView - and yes, I found a nice problems in one of the DLLs that I wrote ...

Rob