Using call library function on a dll file created in an old version of labview

So I'm trying to update an old labview program to work in labview 2012. Everything converted over just fine but labview will always crashoverwrote some while using a library function in a DLL that was compiled using labview 8.5. Labview exits, stating that it vital memory area. It passes an array of data to the library call and an empty array for output. I thought I could get around this problem by changing my code to initialize the array being passed in so that it would be large enough to hold all the expected output. Now instead of overwritting areas of memory it shouldn't, I get a pop up message that says:
fatal internal error
memorymanager.cpp line 406
8.5.1.f5
So it appears because I don't have the ability to recompile the DLL file it runs off of the 8.5 runtime instead of the more recent one. Is there any thing I can do about this?

rjpierce wrote:
So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with.
Your problem most likely is that you try to pass native datatypes to the DLL function? That only can work if the caller and callee use the same LabVIEW runtime engine. Otherwise the memory block created in the memory manager of the caller will be accessed by the memory manager in the callee and bad things happen. Instead you should define the DLL function to use standard C datatypes (Pointer to C array) and also make sure to allocate the according buffer in the caller for all output array parameters.
An even more elegant way would be to completely abandon the DLL approach and call the according functions directly in LabVIEW. Then you won't have the problems about mismatched runtime engines. Passing C array pointers to a DLL is less performant than passing native datatypes, but if you use native datatypes you have to make sure the DLL is compiled in the same LabVIEW version as the one you call it from.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Call a special function in the dll using Call Library Function Node????

Dear all,
I am calling a special function in the dll using call library function node. There is a input parameter that it is a enum type in this function. I don't know how to deal this parameter for calling this function.Has anybody solved this problem?Please advise!
I am appreciated of you anytime.

Most of the times an enum is just a U8/U16/U32, internally so probably you can call it with just a U8/U16/U32 or something. For the correct value you have to look at the definition.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time it is called?

When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
I have a time critical real time application, in which I use a piece of DLL function developed by C++. It is OK? Could any senior developer assure me?
Thank you in advance.
Solved!
Go to Solution.

qing_shan61 wrote:
When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
Once
qing_shan61 wrote:
I have a time critical real time application, in which I use a piece of DLL function developed by C++. It is OK?
OK
Be sure that all DLL calls are thread safe (do not perform calls in UI thread).
Also for real-time application you need real-time OS.
Andrey.

Use call library function node

I try to use call library function node to call a function in DLL and retrieve info stored in the C structure data type, can I do it? If yes, how ? Thanks.

Have a look at the article Configuring the Call Library Function Node

Calling DLL using "Call library function"

I am trying to combine labview with my previous fortran functions using Intel Visual Fortran 12.1 and labview 2012 by below steps.
1. Compile Fortran functions as DLL file.
2. Call Fortran function from LabView via "Call library function"
In step 2, DLL file without linker option "/DLL delayimp.lib" cannot be loaded. That is "delay load" is needed for DLL file.
Are there any limitation or constraint in Call library function?

Hi Vishnu,
There's no problem using the Malloc function in C and call it as a DLL in LabVIEW.
But LabVIEW has a different memory management than C.
It is probably not recommended to allocate array memory in C for labVIEW arrays
You can use initialize array in LabVIEW instead.
Good luck
Van L
NI Applications Engineer

LabVIEW PDA reports COREDLL.DLL error when using Call Library Function Node

I'm trying to build a LV PDA app that calls an external DLL file built using embedded visual C. When configuring the Call Library Function node I select the stub DLL, configure the I/O parameters and select OK. When the configuration dialog closes I get the following error:
LabVIEW: LabVIEW.exe - Unable to Locate Component
This application has failed to start because COREDLL.DLL was not found. Re-installing the application may fix this problem.
I do not get this error when using the configuration dialog in the example VIs.
Any suggestions as to the cause and/or the solution?
Thanks,
Ryan

Hello -
When you create a PDA VI that calls a DLL, you must include the .c or .lib file that corresponds to the DLL. Take a look at these documents:
LabVIEW PDA Module Build Errors with VIs that Call DLLs
Why Do I Receive Errors When Calling a C++ DLL from a Call Library Node Using the LabVIEW PDA Module...
How To Call External Code in LabVIEW PDA for Palm OS
H
ow To Call External Code in LabVIEW PDA for Pocket PC
Hope this helps!
S Vences
Applications Engineer
National Instruments

How to use Call library function node for a function in dll with VOID data type

Hi All,
I would like to ask for your kind help,
I am facing an issue with the call library node.
I have a C++ function(stdcall), which has void as data type
error code XXXX(hwnd, lID, getValue, *void data1, *void data2)
the data1 and data2 types are always changing depending upoin the value of "getValue".
Primarily i can use call library node multiple times and adapt each node according to the data types of data1 and data2, and extract the values and use in the code. Here is no issue. Real question is:
My question:
How can i just use one time call library node and make a case depending upon the "getvalue", which will control the data type of data1 and data2. Here i really looking for solutions.
My trials:
i used varaints as input to the call libray node for data1 and data2, and selected Parameters in call libraby node as " Adapt to type". here labview just crashed.
i really appreciate your feedbackand suggestions.
Thanks
Kutbuddin
Solved!
Go to Solution.
Attachments:
Clipboard02.jpg ‏103 KB

A variant is a very specific LabVIEW datatype (really a C++ type object internally) and trying to pass that to a function, which excepts a flat memory pointer there, for sure will crash very quickly.
As to endianess, yes Unflatten will be able to adjust for endianess, which in this case however is most likely exectly NOT what you want. So make sure that the you select native type for the endianess input on Unflatten from String. LabVIEW internally works with whatever is the native endianess, as will most likely your C++ DLL. The platform independent big endian format does only come into play when you receive data streams over some streaming interface like a network connection. Here it is desirable to use an endian format that is independent from the actual platform that generates and consumes the data stream. LabVIEWs default endianes is big endian here.
But as long as you pass data directly to native components like DLLs there is no difference in endianess between what LabVIEW uses and what those components use.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Passing Variant to dll using call library function node

Hi,
Using LV2012
I have a dll that the following prototype:
SetTestResult(LPCTSTR Serial, int Test, int Result, VARIANT measuredValue);
How can I pass the Variant to this node when my variant can be either int or float.
I have tried "ToVariant" function but it is not sending data and gets error 1517 on LabView. For configuration parameters for variant I have used ActiveX type and datatype as activeX Variant Pointer.
So for call library function node my prototype looks like this:
int32_t SetTestResult(CStr Serial, int32_t Test, int32_t Result, VARIANT *measuredValue);
Can someone help me understanding What am I doing wrong here please?
Thank you,
Hiren
Hiren Patel

Hello Hiren,
Posting your code (even without the DLL) would definitely make it easier for people to point out potential issues. Here is an example that demonstrates passing an ActiveX variant to a DLL built in CVI, I would suggest cross-checking the way the Call Library Function Node has been configured.
Example:Transferring an ActiveX Reference Pointer to a CVI DLL
http://zone.ni.com/devzone/cda/epd/p/id/3343
Regards,
Tom L.

Using Call Library Function Node To Return C++ Structure Information

Hi everyone. This question is for all you LabVIEW gurus out there.
I am trying to call a function from a .dll to get information from a structure about a device (FT232H chip). I am using the "Call Library Function Node" to do this in LabVIEW. My issue is I do not know how to set up the "Call LIbrary Function Node" parameter for a C++ structure. How do I set up the pointer to FT_DEVICE_LIST_INFO_NODE structure using the "Call Library Function Node" so that I can read back the device information?
The details of the C++ function and the structure are below.
Thanks for everyone's help!
The C++ function is the following:
FT_STATUS I2C_GetChannelInfo (uint32 index, FT_DEVICE_LIST_INFO_NODE *chanInfo)
In = index (Index of the channel)
Out = *chanInfo (Pointer to FT_DEVICE_LIST_INFO_NODE structure)
The pointer to the FT_DEVICE_LIST_INFO_NODE is defined as:
typedef struct _FT_DEVICE_LIST_INFO_NODE {
ULONG Flags;
ULONG Type;
ULONG ID;
DWORD LocId;
char SerialNumber[16];
char Description[64];
FT_HANDLE ftHandle;
} FT_DEVICE_LIST_INFO_NODE;

Dennis/Nathan,
I tried to set up the "Call Library Function Node (CLFN)" correctly in order to read out Device Information from a FTDI Chip (FT232H) but when I run the VI LabVIEW crashes on me always.
I have attached the code. For the FT_DEVICE_LIST_INFO_NODE structure I passed into the "CLFN" a constant cluster of all the structure elements and then I set up the node to:
Type: Adapt to Type
Data format: Handles by Value
I think LabVIEW crash may have something to do with the fact that the output of the dll function is using a pointer to a structure. With the Handles by value Data format I am unable to set the Pointer to structure.
Can you please take a quick look at the code to see if I am setting the CLFN up correctly?
Thanks!
Once again, here are the C++ Code Details:
FT_STATUS I2C_GetChannelInfo (uint32 index, FT_DEVICE_LIST_INFO_NODE *chanInfo)
In = index (Index of the channel)
Out = *chanInfo (Pointer to FT_DEVICE_LIST_INFO_NODE structure)
The pointer to the FT_DEVICE_LIST_INFO_NODE is defined as:
typedef struct _FT_DEVICE_LIST_INFO_NODE {
ULONG Flags;
ULONG Type;
ULONG ID;
DWORD LocId;
char SerialNumber[16];
char Description[64];
FT_HANDLE ftHandle;
} FT_DEVICE_LIST_INFO_NODE;
Attachments:
FT_I2C_GetChannelInfo.vi ‏14 KB

Failed to run parallel path when using call library function node in LV2009

I have a problem with two parallel paths not being run in parallel on LabView 2009.
See the image below.
This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.
The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.
This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.
Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.
Is there some limit on parallel threads that is different in 2009 than in other versions ?
Or is there some other problem in 2009 that might cause this problem ?
My labview version is 9.0f3 (32-bit).
Regards,
Rob

I've just installed the DETT tool and checked what the different versions of LabView do.
In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.
In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.
So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...
When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.
I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.
To answer Ben's question: "What thread does a modal VI run in?":
In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.
In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.
Thanks,
Rob

Call library function not finding DLL in directory where my LLBs are

I am using LabVIEW 8.6. I have a set of VIs in several LLBs. All the LLBs are in one directory. Most of my VIs are wrappers for the functions in one DLL. I was told to put my DLL in the directory where the LLBs are, and supposedly this is how the previous programmer worked (using an earlier version of LabView).
In the Call Library configuration, I have specified <dllname>.dll without a path. (This is how we want it as our VIs are an API which other programmers will integrate, so I don't know where they will put things and I can't use any absolute paths).
When I load the VIs in LabVIEW, LabVIEW can't find the DLL and asks me to located it. It is right there in the directory with the LLBs and when I double click on it everything works fine. However my absolute path to the DLL now appears in the Call library configuration, and we don't want that.
Does anyone know how to make this work? I would assume that the location of the VIs (or LLBs, in this case) would be the current directory and thus Windows would look there for the DLL. However, it seems that this is not the case (at least, in the current version of LabVIEW).
Thank you.
Batya
Solved!
Go to Solution.

rolfk wrote:
Well somebody using your library should not have to dig into your VIs and do all this on his own. Instead your library should wrap that and hide the troubles of this entirely.
That is EXACTLY what I want to do.
The error cluster was added when the dynamic path option was added. It is not useful to hide that error output so it is always there. Together with the dynamic path there was improved error handling added to the CLN. One of them is that the level of error checking during the function call (exception handling) can be specified. I would assume that some of those options can generate an error code instead of popping up a dialog as they did before and for that the error code output can be useful even in the static call case.
As to what you want to do, I would long ago
I would long ago have done a lot of things differently on this project -- but no one asked me then :-) (Good thing it wasn't me, or maybe I'd have taken offense ;-) )
have handled that with a wrapper DLL that has basically the same functions as your other DLLs and some initiliasation function that returns a pointer to a function dispatch structure based on the actual DLL you want to call.
OK, I am getting the feeling that this will be a brilliant and elegant solution when I fully understand it. I understand what a wrapper DLL is. But do you mean that each version of my product would include a different wrapper DLL (with the same name so that CLN would always work), or the same one and it would somehow be told which actual DLL I want to call? Who would decide which DLL, the VI or the wrapper DLL?
By a function dispatch structure do you mean a table of function pointers gotten by GetProcAddress, one such entry for each function?
Quite like what an object oriented function dispatch table is. Then when initilising your interface you call that initialise function and specify the interface/device type you want to use and after that all the other functions take one additional function dispatch pointer parameter as first parameter in addition to the parameters the actual function has. This function dispatch pointer would be just a pointer to a structure containing the table of function pointers for that interface and for the sake of LabVIEW would be simply a pointer sized integer.
The wrapper function then verifies the function dispatch structure pointer for validity and calls the actual function with the remaining parameters.
I think I understand what the wrapper functions need to do. But I am missing some pieces for the initialize function. It would have to do LoadLibrary and lots of GetProcAddresses -- that much I get. But I still don't understand who decides which DLL. Maybe you mean that the wrapper DLL's initialize function will get the DLL name and path from the registry, load it, try a different path if the load fails, etc. Is that what you mean? That could work very nicely. But from where would it get the registry key? From the VI? This is the part that would clearly be different for each product. I suppose that you had something in mind when you described your solution.
This is some C programming
Great! That's what I do for a living. At least I know how to do that! Hey, I should have thought of this idea!
and might require some planning and desigining of the different interfaces to facilitate this kind of dispatch technique but it will for sure pay of in the long run, and make your library even usable in earlier LabVIEW versions, as well as VB etc. without tricky dynamic loading in the high level programming environment.
Ah, see how much I don't know in LabVIEW? I didn't know this was a new feature...
Thank you for the great idea.
Batya Perlman

What are analogous shared libraries that can be called using a call library function to user32.dll and lvtoolbox.dll when using Linux and Mac?

I am wondering if anyone is familiar with how to get similar information with a LV program using a Linux shared library as well as the corrolate Mac library to the Windows user32.dll and lvtoolbox.dll. I specifically am trying to get system metrics such as screen resolution information and cursor information as well as being able to set mouse position. I am trying to convert a LV Windows program to these other operating systems and I am unfamiliar with these platforms.
Thanks for your time - I really appreciate it.

There is no simple answer to that. On Linux you will likely have to call into X Server, which would be a pain to do, due to various versions and implementations of that. On the Mac there would be the difficulty that you can't call into the native ObjectiveC API but would need to find a Carbon API or something like that to do what you want.
If you seriously want to do something like this for multiplatform, you should bite the bullet and start coding an intermediate shared library in C. This library would export a LabVIEW friendly C API and access whatever system API you need to have for the particular functions. But multiplatform programming on this level is a pain in the ass, no matter what.
Message Edited by rolfk on 04-21-2010 08:26 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Using variants in Call Library Function Node parameters

Can I use Call Library Function Node to send variant data?
Attached is a VI. Here's the C code:
int MM_FUNC mmDaqDll_407DB
    ( IN char *pcUdlPath
    , IN char *pcTableName
    , IN void *pvData
    int nStat = 1;
    //System:bject *varData = ((System:bject *)vData);
    MessageBox(NULL, pcUdlPath, pcTableName, 0);
    return nStat;
} // mmDaqDll_407DB()
I get the void pointer. I was hoping for a solution that did not use void*.
What is the best way to pass void data to a DLL?
Attachments:
DaqDllMon407DB.vi ‏18 KB

Hi Mefitzpatrick,
Here is a similar forum that addresses this issue:
http://forums.ni.com/ni/board/message?board.id=170&message.id=48886&requireLogin=False
They mention using the Adapt to Type property of the function node inputs, have you tried this?
Let me know if this doesn't answer your question.
Sappster

Problem in call library function

Hi,
I encountered some problems when using call library function node.
After i select the path in configuration of call library function node, an error message is shown as 1st attachment.
After i tick and the specified path on diagram, link the path name to the node, and run the program. Another error message is shown as 2nd attachment.
Is my dll file got problem? Or i have done a wrong setting?
Here i have attached my dll file.
The dll file is built by Microsoft Visual Studio 2008.
Please kindly advise.
Thank you.
Attachments:
picture1.JPG ‏14 KB
picture2.JPG ‏17 KB
CodeUtil.zip ‏152 KB

TanTan wrote:
Hi,
Is my dll file got problem? Or i have done a wrong setting?
It seems to be compiled for WinCE. Assumed that you have Win2000/XP/Vista/7. Check your MSVC build settings.
Andrey.

Call library function node - function not found

When creating a DLL I get a the Labview error "Call Library Function Node "LabviewReceiverDLL.dll:readDataJ1939Data' Function not found. Everything looks correct to me and this used to work, though I've changed computers since then.
This is the beginning of my C++ code just to show my function name. I've also attached the Call Library Function Window to show my setup.
Thank you in advance for your help.
#include"StdAfx.h"
#include<iostream>
/* Call Library source file */
extern"C"__declspec(dllexport)unsignedint readDataJ1939Data(unsignedint, unsignedint, unsignedchar, unsignedchar* canData, unsignedchar* path);
unsigned int readDataJ1939Data(unsignedint ulTimeStamp, unsignedint ulIdentifier, unsignedchar uiDataCount, unsigned char* canData, constchar* path)
Solved!
Go to Solution.
Attachments:
Call Library Function.png ‏192 KB

You mention that you have changed computers and that it used to work before.
Could it be that there is another (older) copy of the DLL on this computer, and LabVIEW is loading the wrong one?
The simplest way to check is to close your VI and delete the one you are expecting it to use. Then open the VI again; if LabVIEW doesn't ask you where the DLL is, it is loading it from somewhere else.
Batya

Using call library function on a dll file created in an old version of labview

Similar Messages

Maybe you are looking for