GetExternalModuleAddr library function error - 10 CVI 2010SP1

Function GetExternalModuleAddr (certainly marked obsolete - but key to one of our older but much loved by the software plots) utility library fails with error code in 2010SP1 CVI (W7)

The suggested alternative Win32 GetProcAddress API does not work with source or obj files (so is not an alternative to all)

Also tried CVI 8.1.1 on XP - code works very well

I think it has worked well on ICB 9.1.0 with W7 (before that I've updated) - but can not be sure

Suggestions (code compiles OK anyway)?

C two modules (in this simplified version of the actual code) of the project as follows:

File 'Main.c '.

#include

int main (void)
{
void (* funcPtr) (void);
moduleID int;
State int;
 
moduleID = LoadExternalModule ("Test.c");

funcPtr = GetExternalModuleAddr (moduleID, "test_function", & status);

(* funcPtr) ();

return 0;
}
______________________________

File "Test.c".

Sub test_function (void)
{
 
 
}

Make sure you have enable LoadExternalModule enabled in the settings of your target.

Tags: NI Software

Similar Questions

  • [HELP] Call library function node...

    I have a DLL that has a function as follows:

    int GetMessageNameNumber (char * messageName [], const int MessageNumber);

     

    The function is used thus:

    char * MessageName = NULL;
    int MessageNumber = 0;
    ...

    error = HL1553API_GetMessageNumberName (& MessageName, MessageNumber);

    MessageName will contain the name of the message as a string.

    I saw the Devils own job trying to wrap this in a Labview module.  I have a knot of library function to call the above function, but I'm not sure what to set the parameter "MessageName" also!  I tried array of integers 8 signed bits, adapted to the Type of pointer to data in the table and then passed in an array of strings.  Whatever I do translates into LabView crash.  I know HL1553API_GetMessageNumberName works, because if I call it directly in TestStand it works fine.  I need LabView well!

    Any ideas?

    C a pointer to a string or an array of strings are completely ambiguous.

    char * something = char * something [].

    You can't tell the two apart from the syntax, but only from the documentation or an example of how the function is called. A C compiler treats the equal in terms of access (but a C++ compiler will do a syntactic differentiation when code syntax checking, with the possible result compile warnings when you are prompted to use a sufficiently high level of warning).

    The example shows that it is not a string array gets allocated by the caller and passed to the function, but a string pointer that is passed by reference. So the function will allocate a pointer and return it (a very atypical C practice at least for strings). This automatically raises the question when and how this pointer will be released? The documentation for this function should document the call from Manager memory allows to allocate this pointer and also point to the function to call to release. Ideally the library (DLL) provides an exported function for this purpose.

    Assume that everything I spoke so far is clear and available you need to cheat a bit LabVIEW. You need to configer a pointer size whole that is passed by reference. Now this whole in the diagram IS actually your channel. If you only need to pass this pointer to other library functions call that you're already doing. Otherwise if you need access to the contents of this string from the diagram LabVIEW, you will need to copy the information from this string to a real string of LabVIEW pointer.

    One way to do that is to use the export of the MoveBlock() C function that LabVIEW exports itself. I have explained this several times here on this forum and the MoveBlock research will no doubt find out these positions.

    Another slightly better way is to use the LStrPrintf() function which also exports of LabVIEW. To do this, you configure a library function call as follows:

    Library name: LabVIEW

    Function name: LStrPrintf

    Calling Convention: C

    Thread: both are possible, but the function is thread safe, so just use environment

    return parameter: int32 (there is a possible LabVIEW Manager error code)

    1st parameter: handle string of LabVIEW, passed by value

    parameter 2: C string pointer

    3rd parameter: integer pointer size, passed by valu

    Wire an empty string in the first parameter constant.

    Wire a constant containing the text '%s' without the quotes on the 2nd.

    The pointer to your thread on the 3rd string

    The function will return 0 as a return value and the content of the string on the side of the exit of the 1st parameter or a zero value indicating that a mistake to return back.

  • Call library function node

    When using a call library function node, and the program came out, I get an error "has encountered a problem and needs to close" having to do with ntdll.  It does not stop the program from running properly, but it's annoying.  Any ideas?

    You should NOT specify the full path to a DLL system in the configuration dial the node of the library. This mess something in the newer versions of Windows. Instead just enter the name of the DLL only. It is sort of a bug in LabVIEW not automatically detect the system paths and shorten the path accordingly in itself, but this is how things have been for a long time and you just need to be a little careful.

    Also the return value must be really set up to be an integer of size of pointer, since a HANDFUL is really a pointer under Windows and that the first parameter is also better configured as such. The way you did works very well for LabVIEW 32 Bit but will misbehave in LabVIEW 64 Bit.

  • Despite indicating to the path, still have manually pointing DLL every time LV works using the library function node call

    I use the node of the library function call in LV 8.6. I checked the path to specify the box diagram and made directly in the DLL file that I use. Whenever I have started with Labview, I have to go to the diagram and physically find the DLL in one of my calls to make it work properly. Once I have do this everything seems to work as expected. Anyone else see this issue? Any suggestion would be appreciated.

    Thank you

    Steckman wrote:

    I use the node of the library function call in LV 8.6. I checked the path to specify the box diagram and made directly in the DLL file that I use. Whenever I have started with Labview, I have to go to the diagram and physically find the DLL in one of my calls to make it work properly. Once I have do this everything seems to work as expected. Anyone else see this issue? Any suggestion would be appreciated.

    Thank you

    Probably that DLL does not depend on other DLLs that reside in the same directory you point to in the configuration node dialog box call library. What is happening is this:

    Without going into this directory:

    LabVIEW applications Windows to load the DLL, Windows detects that it needs to load other DLLs and can not find in its standard search sites:

    (1) already loaded into memory

    (2) in the application directory (where the exe that began the current process resides in the LabVIEW IDE would be where is LabVIEW.exe)

    (3) in the system directory

    (4) in the Windows directory

    (5) any directory in the PATH environment variable contains

    (6) in the directory 'active '.

    Because Windows cannot find a person to load DLL he abandoned the main DLL loading and returns an error to LabVIEW.

    Now, you go to the configuration dialog box and point to the DLL. The dialog box browse file in LabVIEW uses the standard OS dialog box and this dialog box has the behavior obnoxious always update the "current" directory in the directory where a file got selected in. LabVIEW sees now that the path has "changed" and asks again to load the DLL. Yet once, Windows detects that it needs to load other DLLs too for this DLL but this time going over the search order, it will actually hit the DLL in the same directory and that's all fine.

    It is certainly NOT a problem of LabVIEW. LabVIEW does not and should not really need to know that a DLL needs other DLL loaded and more importantly should never try to think he can do better than Windows, it probably could, but is simply not his task of dependency DLL loading.

    It is your responsibility as a programmer and user of this DLL to know its dependencie, and if you did not write the DLL, to hit the original on his head programmer, if it has not documented these dependencies and make sure that these dependencies are actually properly resolved for Windows placing them in one of the places mentioned above

    ((2) is generally the best location for applications applications because it will not pollute the Windows directory or the user of the application system and 5) is the best for the development machine as you can add a directory to your PATH environment variable where you put the dll you need to develop a specific application.

    Rolf Kalbermatter

  • help with call library function node

    I have problem with node function call library that I try to use velleman k8061 dll file to get this working labview

    all I'm trying to get the same problem

    but I chose one to explain it

    SetDigitalChannel
    Syntax
    PROCEDURE SetDigitalChannel (CardAddress: Longint;) Channel: Longint);
    Parameters
    CardAddress: The address of the previously opened card.
    Channel: Value between 1 and 8, which corresponds to the output channel to be resolved.
    Description
    The selected digital output channel is activated.
    Example of
    BEGIN
    SetDigitalChannel (0, 1);

    now, when I try to call the function of library in k8061.dll node and set up 2 a card address and one for the channel

    address of card type: type numeric & statistics: signed 32 bit intger

    channel type: numeric type & data: signed 32 bit intger

    function prototype

    void setdigitalchannel (int32_t, intg32_t channel address);

    I also configure error call library function node checking up

    now that I run it, I get error 1517 produced and tell me this mismatch between the calling conventions?

    problem solved

    thanx

  • import the shared library function name change

    Hello

    I used 'Import Shared Library' to create a lvlib, but he changed function name, for example to Z2onj() on(), so created VI does not work.

    It has this error:

    Call library function node "libname.": Z2onj: function not found in the library

    Details:

    The name of the function specified for this node is not found in the library. Click the node to call a library function and select Configure, and then choose the name to function properly.

    How can I solve?

    Thank you.

    Hi Salvo,

    you need to create again the lvlib with the new name.

    Kind regards.

  • Loading of the DLL string using the Code Library function node

    I experience now with the element of Code Library function node... what I wanted to do are, for example, I have compiled a. DLL file... which has a function that returns the pointer to string... function looks like:

    / * This function returns a pointer to the character string * /.

    char * pchar (int n)

    {

    char * str [] = {"error", "String1" and "Word2", "3"};

    Return ((n! = 1) & (n! = 2) & (n! = 3))? Str [0]: str [n];

    }

    but when I load into LabView DLL, a part of the chain on the screens to Panel frontal trash... any ideas why?

    p.s. when I do even with integer values... say my job is like int x = 5; Return x; and then I load in LabView to the digital indicator... it works great!

    So any ideas?

    thanx

    Cyrax says:

    I experience now with the element of Code Library function node... what I wanted to do are, for example, I have compiled a. DLL file... which has a function that returns the pointer to string... function looks like:

    / * This function returns a pointer to the character string * /.

    char * pchar (int n)

    {

    char * str [] = {"error", "String1" and "Word2", "3"};

    Return ((n! = 1) & (n! = 2) & (n! = 3))? Str [0]: str [n];

    }

    but when I load into LabView DLL, a part of the chain on the screens to Panel frontal trash... any ideas why?

    p.s. when I do even with integer values... say my job is like int x = 5; Return x; and then I load in LabView to the digital indicator... it works great!

    So any ideas?

    thanx

    You cannot return a pointer to the data stored on the stack. At the time when the function returns, the stack is reset to the State before the call to the function and in a multithreaded as LabVIEW environment probably long reused for other things when LabVIEW gets around to actually copy the returned pointer data.

    Since it is a read-only variable, you could create a permanent memory for string storage by declaring your variable static. This will create a memory area allocated globally for the string data (and also cause a compile error when you try to write in this area somewhere in your code, which is a good thing).

  • VI Analyzer: the wire under the test object fails with call library function nodes

    Hello

    If I have a knot of function call with an ErrorIn and an ErrorOut library, the VI thread Test Analyzer "Thread under object" always fails with two hits in a library function node call.

    Double click to the salient facts occurrence lines error related to the call... node.

    The test fails, if the error lines are not connected.

    Thank you!

    H

    Sorry, created the CAR number is #208992.

    Kind regards

    Michael

  • call library function node - function not found

    When you create a DLL, I get a error Labview "node"LabviewReceiverDLL.dll:readDataJ1939Data "function not found." call library function Everything looks good to me and cela used to work, even if I changed computers since then.

    This is the beginning of my C++ code just to show my name of the function. I've also attached the function of the library calls window to show my setup.

    Thanks in advance for your help.

    #include "StdAfx.h"

    #include

    / * Call library source file * /.

    extern "C" __declspec (dllexport) unsignedint readDataJ1939Data (unsignedint, unsignedint, unsignedchar, unsignedchar * canData, unsignedchar path);

    unsigned int readDataJ1939Data (ulTimeStamp, ulIdentifier, unsignedchar uiDataCount, unsigned char unsignedint unsignedint * canData, constchar path)

    {

    I've recreated the DLL and Labview library node call and now it works.

  • Call the library function does not find the DLL in the directory where are my LLBs

    I'm using LabVIEW 8.6.  I have a set of screws in several LLBs.  All LLBs located in a directory.  Most of my screws is wrappers for the functions in a DLL.  I was told to put my DLL in the directory where are the LLBs, and apparently this is how the previous programmer has worked (using an earlier version of LabView).

    In the configuration of the library call, I've specified .dll without path.  (This is how we want our screws are an API that will integrate other programmers, so I don't know where they put things and I can't use absolute paths).

    When I insert the VIs in LabVIEW, LabVIEW can not find the DLL and wonder of spotted.  It's just that here 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 library to call configuration, and we don't want that.

    Does anyone know how to make this work?  I guess the location of the screw (or LLBs, in this case) should be the current directory and thus Windows search there for the DLL.  However, it seems that this is not the case (in the least, in the latest version of LabVIEW).

    Thank you.

    Batya

    Well someone using your library should not have to dig into your screws and do it all on his own. Instead your library must wrap that and hide disorders it altogether.

    The cluster of error has been added when the dynamic path option has been added. It is not useful hide this error output, so it's always there. As well as the dynamic path, there was the improved error handling added the CLN. One of them is that the level of verification when calling function errors (exception handling) can be specified. I guess that some of these options may generate an error code instead of bring up a dialog box, as they did before and that the output of error code can be useful even in the case of static calls.

    As to what you want to do, I would have long managed that with a DLL that has essentially the same functions as your other wrapper DLLs and an initiliasation function that returns a pointer to a structure of functional distribution based on the actual DLL you want to call. Quite like what an object-oriented function dispatch table is. Then, when your interface initilising you call initialize function and specify the device interface/type that you want to use and after that all other functions take a pointer extra function parameter expedition as the first parameter, in addition to the parameters of the real function. This dispatch function pointer would be just a pointer to a structure that contains the table of function for this interface pointers and the sake of LabVIEW would simply be an integer of size pointer.

    The wrapper function then checks the pointer structure validity send feature and call the actual function with the remaining parameters. It is a C programming and may require a planning and desigining the different interfaces to facilitate this kind of technique of the expedition, but it will certainly pay to long-term and make your library even can be used in previous versions of LabVIEW, so that VB etc. without delicate dynamic loading in the level high, programming environment.

    Rolf Kalbermatter

  • How to read / write to a HID device with call a library function?

    I had tons of problems to read from a device USB HID in VISA. I had no problem make a driver for him and write it in LabVIEW. However, whenever I try to read using Read Visa, Visa USB Control In or interrupt USB event get different types of error messages.

    I decided to give up this route and talk to the device through hid.dll, setupapi.dll and any other .dll that I need to use. The problem is that I'm not sure I correctly use the nodes to call a library function... I've seen several KB articles that explain how to set up the nodes call library feature, but I need more information. I can configure stuff and sometimes get things to work, but I don't always know what each specific selections in Settings tab is doing. Can someone give me more detailed information on what do the settings tab and all of its components?

    Thank you

    Matt

    Have you looked HERE?

    Shane.

  • Microsoft Visual C++ Runtime library runtime error, core program: C:\Program Files\MSN\MSN files\msn.exe

    Original title: Microsoft Visual

    Get the following message, then computer: "Microsoft Visual C++ Runtime Library Runtime Error, appeal of pure virtual function for files\msn.exe, R6025, core program: C:\Program Files\MSN\MSN.

    Anyone know what this means?

    Hello

    · You receive this error message when you work with internet explore?

    · If so, what is the version of internet explore installed?

    · Do you remember all the recent changes on the computer before the show?

    You can check the link below: correction of errors in Internet Explorer: http://support.microsoft.com/kb/822521

  • How does the library function call Labview? Can I emulate using C++?

    Hi all. I recently finished writing a dll CUDA for LabView, and now I'm in the steps of optimization of code, memory management, etc. BUT since my code depends on the entries of Labview (lots of data under types of specific data as table manages and Clusters labview) I can't use the CUDA Profiler or the Profiler VC ++ on the DLL. What I intend to do runs labview and then out of all data entry for the DLL in a binary file and then add an additional function in my code that will read in the binary file, allocate and assign variables to their respective positions, and then call the specific DLL function in Labview. In the end, this miniature function will act as the library function call to my specific group of data entries.

    In any case, I started to make this purchase all my data entry of cluster and it comes out in a binary file. And then I started the initialization of the handles of labview, allocating memory and begins to write the binary data in the memory and it works for integers (ints), floats, etc., but I'm confused on how it works with table handles!

    Some examples of code:

    Sets the Handle for table 1 d for INT
    typedef struct {}
    int length;
    int val [1];
    to access the value in a row-online val [Online]
    } Array1dInt, * Array1dIntHandle;

    int main()
    {
    Array1dIntHandle x = new Array1dInt *;
    (* x) = new Array1dInt;

    ifstream file ('TESTDATAIN.dat', ios: in | ios::binary);

    If (file.is_open ())
    {
    file ((char *) &(*x)-> length, sizeof;)
    file ((char *) &(*x)-> val [0], sizeof (int) *(*x)-> length);

    LabviewSpecificFunction (x);
    leader. Close();
    } else
    {
    < "file="" did="" not="" open!"=""><>
    }
    return 0;
    }

    __declspec(dllexport) LabviewSpecificFunction (Array1dIntHandle x)
    {
    ...
    }

    However, my program crashes when the table is nominally big, and it is expected, because if we look at the Array1dHandle, it has allocated only enough memory to 1 item of value! YET, somehow, in its magical and mysterious labview is capable of making val [1] be val [HOWEVERMANYYOUWANT], even if C++ 101 says that val [1] is a constant pointer, and even if I dynamically allocated memory another somwhere, I would never be able to put these data in this round!

    Can you explain, or maybe even write example on how I can fool my program into thinking that the binary code comes from labview, so I can then run my program independent of allowing me to profile the functions inside labview?

    I hope that this question is clear and my sample code is also clear, but I'm happy to answer any questions that relate to this.

    Thank you all!

    I think that I thought about it.

    Array1dIntHandle x = new Array1dInt *;
    int tempsize;
    file ((char *) & tempsize, sizeof;)
    (* x) = (Array1dInt *) malloc (sizeof (int) + sizeof (int) * tempsize);
    (* x)-> length = tempsize;
    file ((char *) &(*x)-> val [0], sizeof (int) *(*x)-> length);

    Well enough, you will need to make the handle, and then make a new Array1dInt * for him, then read in the length of the array in a temporary variable. Then use this information to then malloc memoery quantity you need for the table and pass this place on the handle. Now the handle will point to the size of the memory and you will be able to access the memory in the format, you've done the handle. Badabing badaboom

  • Disable the use of structure in a lead time library function node increases

    I found that if I use a stureture disable to disable one of the outputs of a library function node call, the run time will be greatly increased. Can someone explain this?

    You can read this thread and benchmarking, I did there.

    Turn off debugging and check if the loss of performance you MENTION (but not quantified) is still there.

  • What is the right way to specify the location of the shared library in an a .lvlib function call library function node?

    I'll have a bit of a problem with how to specify the location of library shared in a call library function node it is a VI that is part of a library of LV. Here's a little background which may help.

    I do a lot of measures using spectrometers photo from several manufacturers.  Someone in my company developed a C DLL library, which provides a simple API for all the different spectrometers. To facilitate this DLL to use in LabVIEW, I wrote a .lvlib that wraps all the functions.  When I want to use the API, I simply include the .lvlib file in my project that allows me to drag and drop the wrapper s VI on my block diagram. When I created the .lvlib of VI, I specified the path in the call library node. /. * so it will always look in the local application to the DLL directory when I run.

    The problem is, when I load demand, LabVIEW you asks for the location of the DLL even if it's just there in the local directory! I tried to put copies of the DLL in the directory with the .lvlib, but he still refuses to find the DLL loading.  What I am doing wrong?

    You should in this simple case enter the full path to the DLL by navigating to it. If the DLL is on the same volume/drive that the VI containing the call library node LabVIEW will be internally store the relative path from the VI to the DLL (but still show the absolute path). If you move the DLL and screw together (so the relative location of the DLL to the VI remains the same) LabVIEW will always find the DLL.

    I don't think that the lvlib would add nothing to that.

Maybe you are looking for