LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can LabVIEW call a DLL built with VS(2005) C++ with /CLR and Without an Entry Point

My project requires me to convert a C++ program to a DLL and having it called by LabVIEW. Due to the complexity of this C++ program (converted from fortran using f2c -C++ option), it cannot be compiled without using /clr option.  I did build the application standalone (/clr), and it functioned fine.  When I build it into DLL using VS2005, I was forced to use No Entry point option and without using DllMain in the C++ code. Eventually the DLL was built without error.  But after I call it from LabVIEW, I was not getting calculated results as expected.  I added a testing function to the C++ code of the DLL and just try to modify a parameter, it will not, but only return the input numbers.  I was passing data by pointer and not by value, so I expect this parameter output be modified.  I suspect that the DLL didnt get executed at all as it has no entry point specified.

 

Am I on the right track to approach this task, or I am heading to totally wrong direction here?   I believe due to the fact that my C++ was from f2c and use vsf2c.lib and so on, the code is managed code, so that a regular DLL cannot be built from it with an entry point. How can LabVIEW call such a DLL? Am I right on that?  I really need your advice here for a right approach to this problem and possible implementation "watch outs"...Thanks!

 

Bryan

0 Kudos
Message 1 of 11
(4,635 Views)

Without an entry point I'm not sure how you would get a DLL to do anything very much useful. So a couple thoughts off the top of my head:

  1. Depending on how much data is being passed back and forth, you could build the code into an executable and pass data to and from it via the command line. Messy, but it sounds like you might already be largely there.
  2. Depending on the complexity of the code you might be ahead of the game to start with the original FORTRAN version and recode it in LV. A longer term solution that would ensure the code's maintainability.

Anybody else have any ideas?

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 11
(4,626 Views)

Hi Mike,

 

Thanks for looking into this problem.  Since I intend to pass data arrays in and out the DLL in a while loop, using an executable may not be practical for performance and speed, as the executable I built will be read and write files to disk, unless there is another more efficient way of passing data using command line.  I agree with your suggestion 2 that manually translate Fortran will be a much better long term solution. I will need to still call some library functions for FFT and so on to increase the performance..but I dont know how easy and how much work is involved to do FFT in LabVIEW assumming there is already C libraries there to do this (FFT)?

 

For the short term, I still hope to built a usable DLL from my C++ code...so any other suggestions and thoughts are greatly appreciated!

 

Best,

Bryan.

0 Kudos
Message 3 of 11
(4,616 Views)

In LV you will not need to call external code to do standard analysis operations like FFTs. LV comes with a wide variety of analysis functions. What does this FORTRAN code do exactly?

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 4 of 11
(4,607 Views)

Hi Mike,

 

The code was for a custom curve fitting routine that emloys functions such as FFT and so on, we intend to keep it in C or C++ so that it can be later used by other plateforms besides LabVIEW. Since the DLL I built with VS2005 employed /clr, it must need be run under /clr, and as a result the conventional DLL calling in LabVIEW must not working...instead I need to use the .NET connectivity in LabVIEW, which however is still not clear to me how the DLL can be called there. Hope someone can confirm this understanding, or better yet pointing out the correct approach for my original problem: either how to build a conventional DLL in managed code without using /CLR or on how to use .NET in LabVIEW to call the DLL built with /clr.

 

Thanks again,

Bryan. 

0 Kudos
Message 5 of 11
(4,587 Views)

Wanting to reuse the code in a C or C++ environment wouldn't preclude converting it to LV. For reuse outside of LV you could compile the function into a DLL.

 

Mike...

Message Edited by mikeporter on 03-01-2009 10:28 PM

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 6 of 11
(4,567 Views)
another concern we have is that this rountine must be running high speed inside the loop at 1kHz minimum, generally a DLL of C/C++ maybe preferred than DLL of LV? Bryan.
0 Kudos
Message 7 of 11
(4,544 Views)

That I can't really address - and I'm not sure if anyone could. There are so many variables involved in writing a DLL that I'm not sure how you would go about saying a DLL created in C++ is faster or slower than one created in LV.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 8 of 11
(4,525 Views)

Hi...Finally I was able to compile my code with an entry point defined and without using /clr.  I can also call this DLL from LV and got back a variable from a little test function added to the DLL.  But the function that was used for my main application in the DLL crashed LV and I got a pop up box from Microsoft Visual C++ Runtime Library: Runtime Error! "This application has requested the Runtime to terminate it in an unusual way, please contact the application's support team for more information".  In Visual Studio I also got the following message: (I eliminated most of the "No symbols loaded" messages that are not errors but just info.)  I would apprciate if someone can take to look with your more "experienced eyes", many thanks! Bryan.

 


'LabVIEW.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was not built with debug information.

'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\Shared\nicont.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\Shared\NICONTDT.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\nitaglv.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\lkbrow.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\lkrealt.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvdaq.mxx', No symbols loaded.

'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvdesktop.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvfp.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\mfc71.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\MFC71ENU.DLL', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\vi.lib\FieldPoint\SubVIs\FPLVMgr.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvfprt.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LvProjectProxy.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LvRealTimeCoreProvider.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\MVEProvider.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtCore4.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtXml4.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtGui4.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\mxLvProvider.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\nimxlcpp.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\nimxlc.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\variable.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\lvMax.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\MAX\UI Providers\FieldPoint71.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\MathScriptParser.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'Z:\bli\development\projects\galfitDLL\Debug\galfitDLL.dll', Symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\mesa.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\mscms.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\icm32.dll', No symbols loaded.
The thread 'Win32 Thread' (0xf94) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x90c) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xfd0) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x284) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xdac) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xa98) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x528) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x614) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xa5c) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xebc) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x5cc) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x700) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xcf0) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xc7c) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x4c8) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xa4) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x52c) has exited with code 3 (0x3).
The program '[804] LabVIEW.exe: Native' has exited with code 3 (0x3).

0 Kudos
Message 9 of 11
(4,517 Views)

I wonder if anyone knows about the following error (and how to debug it ) generated when debugging DLL with a labview application (with built in C++ DLL):

 

First-chance exception at 0x7c81eb33 in curvfitLV.exe: Microsoft C++ exception: ni::dsc::exception::InvalidArgument at memory location 0x0012d7d8.. 

 

Thanks for your help in advance!

Bryan 

0 Kudos
Message 10 of 11
(4,477 Views)