Problem calling seconday DLLs in labview

Hello

I'm using Labview 8.6 for my application. The application calls a dll developed in vc ++ (main dll).  During execution of the application, the main dll(vc++) calls another (secondary dll) developed in vb 6.0 dll.

During the process, the main dll sends data to secondary dll to display data in a pop-up window. After getting the user recognize the display, the vi application stops.

When the application runs first time (the vi running first time after labview open), the data sent by the main dll are updated in view of the secondary DLLs. But, for the second time from new data of the main dll not are not updated in view of the secondary DLLs.

Once again, after the closure of the vi and quit labview, if I open and run the vi, then the data of the main dll are updated in dll secodary display. But the maindll data must be updated in the secondary dll without leaving labview.

I use "Function Call Library" to call the maindll.

Can someone please give the remody to this problem...

Thanks in advance.

Swamy.

Is - this two dll to reside in the same physical directory as your main vi? They are included in your project?

-AK2DM

Tags: NI Software

Similar Questions

  • Call a dll for Labview: function not found in the library

    Hello

    I try to call a form very simple .dll Labview. I have compiled .dll file for x 64 by using Visual Studio 2010, because I'm using Labview(64-bit). I did everything exactly as I have read in several tutorials. But the "call library function node" does not create a menu with functions avalible as it is supposed to do. The Import Wizard found no function either. What is the problem with my .dll?

    I added a block marked 'extern "C" ' file in my source, but it still doesn't work.

    Thank you

    Matthias

    You have not read the article properly. Read step 3. In the .cpp file, you add '__declspec(dllexport)' to the body of the function. In the header file, you add extern 'C' at the beginning of the prototype. It comes to dealing with the name decoration than the C++ compilers.

  • File not found when you try to call a dll on LabVIEW Real Time machine

    I have a dll called "DLLRTTEST" that I wrote, and claim successfully on my host.  Now, I try to call this dll from a vi that is on my computer in real time.  Currently, I get a message 'error 7 occurred at the crux of library DLLRTTEST.vi. call function' when running

    In the attached screenshot, I try to ensure that the vi that I am running is indeed on the system in real time.  I then use a 'check if file or folder Exists.vi' to confirm that the dll that I'm about to call exists on the system in real time as well.  However, I always get an error "error 7 file not found" from the node call library feature.

    Any help is appreciated.

    Thanks again for all the responses.  As I said earlier, I had already met and solved the problem identified in the link provided by Nathand.  I had to go down to Visual Studio 2008 to go beyond this particular error, after which the app of auditor of the dll in real-time reported my dll needs to run successfully.

    I just got the phone with Jack in charge NEITHER well, and it turns out that I simply had to compile my dll in release mode.  Decommissioning of VS 2008 I got the correct version of dll (msvcr90.dll), but since I am compiling in debug mode, I found myself using msvcr90d.dll (d for debug) who doesn't have my computer in real time.

  • do not call the dll of Labview in CVI

    I have a Labview dll should call for the CVI. but it always shows error.

    void __cdecl Idx_RW_Reg (uint16_t registry, int32_t RegLength,
    [LVBoolean Data_in], uint8_t OperationRd1Wr0, TD1Hdl * read_reg_table_in,.
    uint16_t PortAddress, TD1Hdl * Table_of_reg_out, LVBoolean ControlFrame [],.
    uint16_t * PortAddressOut, int32_t len2, int32_t len);

    TD1Hdl * read_reg_table_in: what is it, who can tell me

    typedef struct {}
    int32_t dimSizes [2];
    LVBoolean Boolean [1];
    } TD1;
    typedef TD1 * TD1Hdl;

    Any help is greatly appreciated.

    Thank you.

    Hello

    What is your calling code?

    I suggest you read: call a LabVIEW DLL in a CVI or other C/C++ project

    Kind regards

  • Call the dll in BT (usbm.dll)

    Hi all

    I'm having a hard time finding how to call a DLL in Labview. I read a little bit on this subject but am still a beginner. The DLL in question is usbm.dll (http://www.usbmicro.com/, the list of functions & types is documented here). I use the call library node to call the DLL.

    So I call things with no input argument functions work well (for example my first 2 calls check for the presence of the device and the number of devices and work ok returning the correct output)

    Then I try to use functions with arguments (3rd stage of the VI) and Labview does not have them (error 1097). I'll for function "int USBm_DeviceValid (unsigned char device)", in my opinion, that argument must be of type uint8 and output type int8... I tried all numeric types, does not.

    In addition, if I skip the VI 3 and go to step 4 (calling a function that takes 2 parameters and sends a command to my device): the function is executed (for example the unit move), but then Labview block (exits without error message). Is it because of calling the function?

    Any suggestions would be welcome, thanks!

    Hi lvrat, thanks for your suggestions.

    I had the problem. I got an older version of this DLL usbm (as well as some example of LV files) which works very well. Looks like the DLL most recent that I was using has some issue with Labview...

    I enclose these files (they were not easy to find), in case someone else tries to interface to a USBmicro device.

  • Problem calling LabVIEW DLL with c#

    Dear all,

    I compiled a few DLLs in LabVIEW and called these DLLs using c#.
    I'm having trouble passing in strings and arrays as input and output of the DLL.

    Whenever I try to view the string I have entered in a dialog box (this part is written in LabVIEW DLL), a LabVIEW message dialog box appears and the program just stuck there.

    Whenever I try to enter a string or an array to the dll, Microsoft Visual Studio would display "attempt read or write protected memory. It is often an indication that other memory has been corrupted. »

    I attached the vi and also the c# .sln file.

    Can you guys please advise where am I wrong?

    Thank you very much.

    You must allocate strings and arrays of output!

    private void button1_Click (object sender, EventArgs e)
    {
    output string;
    int [] value;
    StringOutput ("A", "B", exit, 3, value, 4);
    }
    }

    Your variable output and value must be preallocated to ensure storage of 3 items respectively. 4. and since you want to receive the C string that you need to increase this to 4 characters terminated by a NULL value.

    String in c# is also a not a C string of object pointer. You must declare the StringOutput() function as follows:

    [DllImport("SharedLib.dll",CallingConvention=CallingConvention.StdCall, Charset=CharSet.Ansi]internal static extern int StringOutput(StringBuilder A, StringBuilder B, out StringBuilder StringOutput, int sizeString, out int[] output, int sizeArray);
    

    Then call like this:

    StringBuilder output = new StringBuilder(4);int[4] array = new int[4];
    
    StringOutput("A", "B", output, output.Capacity, value, value.Length);
    

    Please note that I'm not a pro in c# and usually do not do much in it. Also that this code has not been tested or updated at all, so probably contains some errors. He however point you in the direction of where to look further.

    What you need to understand, is that the C DLL that you created in LabVIEW has a so-called unmanaged interface. This means c# is not able to know how to manage the memory for the parameters at all and you have to do everything yourself, where the obligation to explicitedly initialize variables output and table with a block of memory préallouée.

  • problems in C++ dll call

    Hi, I compiled a dll in C++ to write data in a shared data segment, and it works well in Labview. Then I try to call the Dll in C++, it can be built successfully, but will break in the end. I have this problem since almost a whole day and could not find the solution.

    Here are the source files for my Dll and the program calling dynamically.

    DLL:

    Calling program.

    Problem solved.  The work for Labview and C++ dll must be like that. The shared data segment must also be declared as funtion and with 'extern 'C' ' coming. In addition, Labview can read only pointers from dll.

  • Call a C-built DLLS in LabVIEW

    Hello!

    I try to get knowledge on how to call DLLs in Labview.

    I found a very good example on this site:

    http://zone.NI.com/DevZone/CDA/EPD/p/ID/1513

    I downloaded and extracted the call_c_dll_in_lvnew.zipfile.

    When you try to open the sample file GenSortRandC.vi in the folder LabVIEW_code_and_DLL

    I get the following error message.

    "The procedure entry point not found RebootRTSystem in the library cvirte.dll dynamics."

    I searched on the Internet and some forums but so far without success.

    Could you please let me know if you have the same problem the example whith?

    I have the following configuration:

    -Labview 8.5.1 FDS (default installation)

    -Windows XP sp3

    Best regards

    Mattias

    Sweden

    Mattias salvation,

    I have no problem with this example. I can't run without error.

    It's maybe because I installed the CVI Run Time engine.

    Mike

  • Call the function in LabView from a DLL, and then access the global variable of DLL

    I've created a DLL in LabWindows with a function and structure.  I want to call the function from LabView and then access the overall structure.  I am able to call the function in the DLL with a "call library function node" and has access to the return value, but I can't understand how to access the overall structure.  The structure is declared in the header DLL with __declspec (dllimport) struct parameters file.

    Is it possible to access this structure without using the library of network variables?

    My guess is that you need two bytes of padding after "in_out" and another to two bytes of padding after "anin."  The reason being that ints are 4 bytes, and most of them C compilers will align on 4-byte boundaries.  The struct will naturally start to such a limit (in fact, in Windows, it will probably start to an 8 byte boundary).  If you then count bytes in your structure, you are 70 byte after "in_out."  70 is not divisible by 4, so you need 2 bytes more to reach the next 4 byte boundary.  You can also you could reorganize your struct so that "anin" follows "in_out" and this is probably the best option if it won't cause you other problems.

    Unlike most C compilers, LabVIEW compressed structures as closely as possible, without filling.  I don't know enough about the history of LabVIEW and internal parts to explain the reasons and to do this performance penalty, but, as choice of LabVIEW "endianness", it is probably a remnant of the first versions of LabVIEW that were running on the Mac.

    If for some reason you want to force your C struct to match package LabVIEW, you can use the #pragma pack (x) directive, but I wouldn't recommend that here because you can control the C and LabVIEW.

    EDIT: in the cases where it was not clear, add padding to your cluster of LabVIEW, insert appropriate size or items at the place desired in the cluster.

  • Call a dll built with Labview in Digital Micrograph

    Hello everyone,

    I am faced with a difficult problem. I use Digital Micrograph that run the DLL of enforcement. This DLL must be built with a structure of library written in C. In this C code, I can call a built with Labview VI. If the Vi is simple, Digital Micrograph is happy. But, if I include a graph in the VI, C code builds and create a dll but Digital Micrograph falls down. Of course, DM is unclear the type Labview graph. I can do what I want in my VI and how can I solve the problem?

    Thank you.

    Gautier

    gautierdufourcq wrote:

    I solved part of the problem, DM do not plant more but the Labview graph is not displayed. Do you have a solution? THX

    Is not a problem of LabVIEW.

    It's their DLL. Talk to DM.

  • Efficiency call DLLS in Labview

    Hello

    I'm working on a labview program for the treatment of the data in real time.  Thus, code running efficiency will be critical.  I wonder how about the cost of calling DLLs.  Similarly, what the call cost of the subprogrammes.

    To implement the same function, the call of a Subvi will be faster than calling a DLL?

    If I can develop all screws Sub in the main program and delete all the calls, which will be much faster?

    Can someone give me any clue or guideline?

    Thank you.

    CRXX wrote: [...]

    I'm working on a labview program for the treatment of the data in real time. [...]

    What is the OS you are using?

    Since you ask in general, I answer in general:

    This question cannot be ansered. This is a case-by-case-thing and must be assessed individually.

    Most of the effect will be the memory management: which allocates the amount of memory? When it's done?

    Memory of ESP. allocation mess up determinism, if a DLL can perform worse than pure code LV (given a BONE of RT LV). But it might be preferable for some algorithms encapsulated... no one can say in general.

    Perhaps the most important question is:

    How many times is that the code (DLL vs Sub - VI) called and how short is its runtime? If the load of execution: calling code relationship is very low (-online 1:1), it is best to "solve" the subcode. SubVI Inling is a valid way in pure BT (from 2010).

    If the code is called rarely, this whole discussion is somehow obsolete as the overload of calls will be negligible, even if it would be quite high...

    And no, C is not faster as LV by definition. It also depends on the task and how you implement it...

    hope this helps,

    Norbert

  • Python, call DLLs in LabVIEW: Fatal internal error when accessing output String Cluster

    Hello

    We have compiled a DLL in LabVIEW (TestError.dll) and tried to call it from Python.

    TestError.dll includes 2 functions:

    1 testErreur: cluster 1 entry string, 1 channel indicator

    2 TestError2: 1 channel input, 1 bunch of output string

    What we try to do in Python is actually something like this:

    1 provide values to controls in the functions of the DLL.

    2. call the DLL.

    3 get the values of the indicators.

    What we have seen are:

    1 read/write operations on normal data types (string, digital) indicators/controls are OK

    2. write operation on the Cluster string entry is OK

    3. read operation on the Cluster output string is not OK. The following error is still prompted for:

    «Unrecoverable internal error: 'MemoryManager.cpp', line 437.» LabVIEW version 8.6... »

    Also joined the TestError.prj and python code.

    Grateful if someone can help to explain why we get this error and how to overcome?

    Thank you

    howmean

    What we have seen are:

    1 read/write operations on normal data types (string, digital) indicators/controls are OK

    2. write operation on the Cluster string entry is OK

    3. read operation on the Cluster output string is not OK. The following error is still prompted for:

    «Unrecoverable internal error: 'MemoryManager.cpp', line 437.» LabVIEW version 8.6... »

    Also joined the TestError.prj and python code.

    It is very logical that it does not, and the bad news is, it cannot really be implemented reliable of a process not LabVIEW.

    LabVIEW channels (and tables) are very specific species. They are then called handles, which are pointers to a pointer to a block of memory. If you have a control or indicator on its own, the Prototype configuration allows you to configure this setting as a C. LabVIEW data pointer, when creating the DLL, create heels C for each exported function and place the code to do the translation between the past C pointer to and necessary LabVIEW data handle. For strings and arrays within the cluster, there is no configuration option and the DLL is expected to pass a structure with data handles native LabVIEW in there.

    You may say that creating handles data in your calling process enough to trick LabVIEW. For the input variables that actually CAN sometimes work (but is a delicate and dangerous generally to handle this). There is no way to make it work for output variables. LabVIEW will try to resize handle to fill data in that he wants to make. This resizing is done using internal memory manager of LabVIEW. This will work only if it had been allocated by EXACTLY the same instance of the memory manager. Otherwise, it refers to a different memory segment and catastophally fail. The only way to make this work perhaps, with luck, taking your heart and prayer to the gods, is to lvrt.dll to allocate a handle that you must pass to the DLL. Still find the good lvrt.dll, which will execute your DLL LabVIEW is a major challenge.

  • Problem of memory, then I import a DLL on LabView 2010

    Hello

    I have a lot of problems with importing a file .dll on labview.

    The blocks of import to the third of fourth function and sometimes a textbox appear (as you can see in attachment).

    I tried with the import node, but it does not work (so maybe it's that I don't know how to use it really).

    I don't really know how to import the entire library, and I am really stuck.

    There is also the header and the dll as an attachment.

    Thanks for your interest.

    I didn't say it's impossible, but it is very likely well above your head. You probably have two options:

    (1) to abandon this material and get a part that has a good support for LabVIEW.

    (2) hire someone with a very good understanding about LabVIEW C interfacing and allow them to create a VI library and interface DLL for you.

    Good luck

  • LabVIEW 2010 crash when calling user32.dll

    Interesting LabVIEW 2010 'characteristic', I discovered this morning.

    Attached are two identical screws, a registered in 2010 and a registered in 2009.  These screws have been written specifically to demonstrate the bug, I came across this afternoon.  Each VI when it is run needs you to find a specific program (window) opened in Microsoft Windows and bring it to the foreground.  It is based on 'user32.dll' to perform this operation.  It also allows you to specify the calling convention for the function call.

    LV 2009, calling convention works without error.  However, in LV 2010 the calling convention of the function must be "stdcall (WINAPI)" and not the default value of 'C '.  If the calling convention is 'C' LabVIEW hangs and then closes without warning.

    If you happen to have LV 2009 and 2010 LV on your computer, I would like to hear if this phenomenon is duplicated so that I can identify if the bug is LV 2010 related or is more specific to my personal configuration.

    Thank you

    ~ David

    221113

    Return

    COLD LAKE with the calling convention incorrect siliently crash LabVIEW can.
    LabVIEW 8.5 2009 could adjust the convention to call at run time if the user has selected the wrong option. In 2010, it is no longer a case. More information is located in the 59KB14WI knowledge base

    Workaround: Use the correct calling convention

    Reported Version: 2010 32-bit    Solved Version: N/A    Added the: 2010-07-23

    Release notes for 2010.

  • call a dll 8.2 in Labview 7.0

    Hello

    I have a lot of applications written in Labview 7.0.  I need to add a little update of these applications, using some of the features of the 8.2.1.  I have compiled the functions in a dll and you want to call it in my labview 7.0 application.  I have the runtime installed and work 8.2.1 example but when I just tried the same code in Labview 7.0 I get an exception to do with memory.dll, line 342 in the 8.2.1 runtime.  I guess my first question is whether or not it is possible to call a 8.2.1 lavbiew dll 7.0?

    Thank you

    Simon

    sbosanquet wrote:

    Hello

    I have a lot of applications written in Labview 7.0.  I need to add a little update of these applications, using some of the features of the 8.2.1.  I have compiled the functions in a dll and you want to call it in my labview 7.0 application.  I have the runtime installed and work 8.2.1 example but when I just tried the same code in Labview 7.0 I get an exception to do with memory.dll, line 342 in the 8.2.1 runtime.  I guess my first question is whether or not it is possible to call a 8.2.1 lavbiew dll 7.0?

    Thank you

    Simon

Maybe you are looking for