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

Tags: NI Software

Similar Questions

  • 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.

  • Calling DLLS in LabVIEW

    Hello

    Below is the code written in LabWindows in which dynamically access a Dll using Windows API LoadLibrary(), GetProcAddress(), and FreeLibrary().

    Successfully, I could load the library and get the procedure address using library calls node in LabVIEW. But got stuck after that.

    As I am not good in C/C++ coding, ask someone to really help me to write the same thing in LabVIEW.

    Kindly do the needful.

    #include   // Function prototypes.
    #include     // CVI Active X definitions.
    #include 
    #include    /* Needed if linking in external compiler; harmless otherwise */
    #include 
    #include 
    
    typedef long __stdcall( *OLECREATEOBJECT)(char*);
    static  HINSTANCE  Hinstlib;
    static  long  gvntISystem;
    
    long CviCreateFastObjects (void)
     {
    OLECREATEOBJECT procAdd;
        pStrTempmem      = (char*)CA_AllocMemory(1);
        Hinstlib = LoadLibrary("FastTrio");
        if( Hinstlib != NULL)
    {
            procAdd = (OLECREATEOBJECT) GetProcAddress(Hinstlib, "OLECreateObject");
            if(fRunTimeLinkSucess = (procAdd != NULL))
    {
            gvntISystem = (procAdd)("FAST.IMFASTSystemInterface");
            return 0;
            }
            else
            return 1;
            }
        else
            {
    return 1;
            }
    }
    

    All the information you need are in the C code.

    • OLECREATEOBJECT is typedefed just after all the #includes at the top.  It returns a long integer (typically I32 in LabVIEW, but could be I64 on a 64-bit operating system) and takes a string as input.  It uses the standard windows calling conventions, not the C calling convention.
    • LoadLibrary and GetProcAddress are used to get a pointer to the function (procAdd).  This is handled in LabVIEW, by filling in the location of the library and the function in the call library node.
    • The library of appeal in LabVIEW node must also be set to the standard calling convention and return value (I32) and list of parameters (a string) must be set.
    • the function is used to set gvntISystem with a constant of entry 'FAST. IMFASTSystemInterface ".  In LabVIEW, a constant string of wire at the entrance and read the return value.
    • You can implement the audit, thus using the call library errors node error output.

    Good luck!

  • Error 1097 when calling DLLS in LabView

    I get an error 1097 when calling the LabVIEW provider library. Curiously, the error, the DLL routines still seem to do what is asked of them.  This is the test code.  It opens an Ethernet connection to a controller of axes Galil, he asks (possibly) the value of its internal clock, and then closes the connection.  Each call library function returns error 1097 but "valve function" I32 error number is always zero. Open function causes the connection to be opened, the command function causes the send command and receives a reasonable answer, narrow funtion seems to cause the connection to be closed.

    Here is what I see when I run the test:

    Also directly configure call-library functions, as I did in this VI, I also tried using the import-shared-library Wizard to create a vilib of functions of the DLL and I get the same behavior and errors when I use these functions.  I tried to tweak some of the data types in my configured manually call library functions to see if I could find a combination that worked better with the library, but had no luck there.

    I use the x 86 version of the DLL with v2014 LabVIEW 32-bit on a 64 bit windows system 7.  I see that the error on the two computer systems of different work configured in this way. I see a similar error on a home computer with just the RTE of 2014 installed. The manufacturer says they can not reproduce the error. I always saw the error over multiple versions of their library DLL.

    In the attachment ZIP it has a link to the DLL library on the manufacturer's website. There is also a copy of the VI, the DLL and a large part of how-to-use documentation that accompanies the DLL.

    I was hoping that someone who was familiar with the use of the call-library function might take a peek at what I do and see if an error could be spotted.

    Unable to find an error, I did, I would be happy to suggestions on how I could solve this. Little seems to me like there may be a problem with the library. The manufacturer, Galil, said that they have opened a log with OR to see if NEITHER could help but since Galil said they can not reproduce the problem and provide an example of the NC, it really went anywhere.

    Given the decoration of symbol names as exported by the DLL I "m convinced that you must change the stdcall calling convention.

  • 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 dll ActiveX in Labview

    Hello

    I'm a new starter in c# .net.  I have a control dll ActiveX (control of vision of NOR -> CWIMAQ). I need to call dll functions in Labview. I searched for articles on this subject. Everyone talks about single thread and register the dll.  I have no idea about these things. Can any body give me a helping hand. How does it work?

    Thanks for any info

    Best regards.

    To use an ActiveX control in LabVIEW, you place an ActiveX container on the front panel and locate the control to put it in. Then use the nodes property and/or call nodes of the ActiveX palette to set properties and call methods.

    To register a DLL open a command prompt, navigate to the folder where your ActiveX control is normally the Windows system32 folder and type

    regsvr32 .

    In LabVIEW use help > type in the search and find examples... tab ActiveX.

  • error 1097 after the call dll function that allocates memory inside

    Hello!

    When a one call my duties in my dll of LabView, I get an error 1097. My function takes a few arguments, and then allocates memory for the measure.

    He doesn't have pointers to this memory area, it's just allocates this memory for himself. I don't know what could be the problem, no doubt, I'm missing something.

    Could you please help?

    Best regards

    Tamas


  • call dll issue

    Hello

    now I need to call a dll named SajetConnect.dll, this dll will create logfile and ini file automatically when I call.

    Attached VI call this dll, there is no log file and ini file created, but the exe file that I'm building this VI work well for her.

    I also call thie dll using c# and it still work fine.

    So it seems that some path setting question went from me, thanks for your help to take a look for my trouble, thank you!

    attached list

    2. without title vi VI

    New Folder\123\Application.exe create JOURNAL SAJET. INI SajetConnect.ini when you run this exe to call DLLs

    Without seeing the source code of the DLL there is very little we can do, but shooting in blue. And I have no balls to spare in this at the moment, except maybe the DLL tries to create these files in the directory where the executable. This would be the directory where the labview.exe deveopment environment. But given that Windows Vista users don't have write access to this directory more. Some features of the INI file are virtualized in these versions of Windows and redirected to a specific shade of the user location, but only if your application uses files INI of Windows API functions. Otherwise write access fails just and you won't see them unless you manage these errors in some way and proceed to the appellant.

  • Open VB6 dll on labview COM type libraries

    Hi all

    I have a third party DLL generated from VB6 and I try to access its functions using the block "call library function.

    When I select the library path, I do not see the function I want on the field 'Function name' but if I type the name of the function, it automatically generates

    the parameters as defined in the VB6 file, but I keep seeing the broken arrow and the error "not found in the function library.

    I know that the function is defined as a COM type library because I tested it on a visualization of the Dll called "DLL Export Viewer" software.

    Do you know guys a way to access this function? Thank you.

    Hi Dennis,

    I am new to use the LabView dll, thanks for your response.

    To solve my problem, I created a "refnum automation control" on my front and then traveled to the DLL file. After that I just used nodes Invoke/property for ActiveX files as you said to access my functions.

    Thanks for your attention!

  • DLL crashes LabView 2013 Pro, but good to EXE

    Hello

    I started having a problem older "degenerate." I had a previous post about a dll which plays a role of interface between a program running under Windows and LabView. The details are here:

    http://forums.NI.com/T5/LabVIEW/installed-program-no-Comm-with-driver/m-p/2659765/highlight/true#M79...

    Note that this isn't a double post, I just mentioned my recent problem there, when he was not that common.

    (http://forums.ni.com/t5/LabVIEW/installed-program-no-comm-with-driver/m-p/2662503/highlight/true#M79...

    Today - unknown reason - after a win system restart I can not run my development environment LabView code. When I run the main VI, it blocks all of the LabView environment during the first call of dll. This problem we had before also, but the 2nd of the 3rd test he ran OK. Today, I tried like 30 times, too many system restart. The native software spectroscope works very well too.

    Strange, if I run the exe to build, everything works fine. The problem appears only when I run LabVIEW. There is no error code, only a window appeared the first time, as I can send the error report to NOR. I can dig into some logs tomorrow at the lab, I just need to know where I can get.

    It seems that someone has also experienced similar behavior with external dll call:

    http://forums.NI.com/T5/LabVIEW/problem-DLL-crashes-LabVIEW/m-p/2562667/highlight/true#M773565

    "In the application resulting (Exe), it seems to work very well."

    What is the difference between when the dll is built in the exe file, and when it is executed from the LabView dev environment?

    Thanks for any idea and help!

    (if nothing helps, I just re - build the exe after changes to the program, but it slows down some coding)

    The last time, we have no comments from the company that created this dll, I'll try to contact again...)

    Hello

    you said that you have read the discussion in the following link:

    http://forums.NI.com/T5/LabVIEW/problem-DLL-crashes-LabVIEW/m-p/2562667/highlight/true#M773565

    Are you facing exactly the same problem?

    If Yes, then there is not much we can do. LV is an access contradication with your included DLL unless you have access to its source. You do not experience these problems with the exe since that only works on the run-time engine while the LV environment executes the code in a different way (why LV reserve this special memory on which your DLL is also trying to access.

  • Return the execution of DLLS in Labview data table

    Hi all

    I have a DLL C++ which should run continuously collect new data of some hardware.

    I can call the DLL without any problem of Labview, but I wish I had access to some digital table data in the DLL in Labview (the appellant or an another VI) during its execution.

    Working in this direction, I've already got the event validation works, i.e. trigger messages to the DLLS running in VI of the caller using PostLVUserEvent().  This would solve my problem (maybe bad) if I need only a scalar or string of each event (which works fine).

    Then I tried passing a few paintings of small integers via the event (properly by changing the input type to create the user in LV event), but it did not work (empty tables or falls down... oops!).  Perhaps events are not the way to send large paintings (say 10 ^ 4-10 ^ 5 integers) anyway...

    Can anyone suggest a way to do this?  There are functions to manipulate the values in a control of LV/indicator of the DLL running?

    Thanks a lot for any assistance, MT


  • Effective way to make and receive pointers with C/C++ DLLs in LabVIEW

    What is the best way to pass a handle using the dll programmed in Labwindows/CVI between call node of the Labview library?

    I read a very useful on post

    https://decibel.NI.com/content/docs/doc-9080/version/5 on and the reception of pointers with dll C in Labview.

    However, my request is for the Labview interface with a camera.  In the camera API, it defines

    #define void * CameraHandle

    And then a CamHandle variable should be used by a lot of other functions.

    In CVI, if not used as DLLs in Labview, I would

    Sub OpenCamera()

    {CameraHandle ;} CamHandle

    Sub SetParameter (CameraHandle CamHandle)

    {

    }

    void CloseCamera (CameraHandle CamHandle)

    {

    }

    If CamHandle is a type void *, how can I make it since one node/function in Labview when I use the Setup to call a library function?  In the post I read, it say how to get the value of the arrow tip using a pointer to the value, and then dereferencing pointer.  However, what I need, is to pass the pointer itself.

    Thank you very much!

    Best,

    Charles


  • DLL of LabVIEW with arrays of strings in c ++

    I'm looking to use labview to retrieve a list of gas to a txt file and then transfer this list to gas in a C++ program.

    I thought it would be easier to just list the gas transfer a string array of the DLLs in labview to my C++ program.  However, I am not able to output the list of gas using tables; I am only able to output the pointer, not the chain that makes reference to the needle.  Of course, I have a syntactic problem with my method of output.

    I have no problem out of the list of gas via a simple string.  However, the approach of single string requires multiple calls to the relevant dll.

    My code is based on the labview dll for C++ routines example titled call of Labview DLL in Visual C++ this Passes table manages in reference (http://zone.ni.com/devzone/cda/epd/p/id/1518).

    I am sure that what I'm trying to make is simple enough for an experienced programmer to Labview.  However, my labview, C/C++ and experience is limited.

    Thank you in advance for your help.

    My labview and C code is found in the attached zip file.  However, the basic C code and output resulting are:

    // Call DLL.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "Array_Multiply.h" #include  #include  #include  #include  #include  using namespace std; int main(int argc, char* argv[]) { TD1Hdl handle_var3; long temp; char stringout[25]; temp=25; handle_var3 = (TD1**)DSNewHandle(sizeof(TD1)); // initialize sizes (*handle_var3)->dimSize = 1; // // Gasstring is a function that outputs a Labview array of strings. // However, I can't make this work. All I am doing is outputting // memory addresses. // Gasstring(&handle_var3); cout << "\n gasstring " << *handle_var3; cout << "\n gasstring " << handle_var3; cout << "\n gasstring " << (*handle_var3)->String[0]; //cout << "\n gasstring " << (*handle_var4)->Numeric[0]); // // Gasstring3 is just a single string. There are no issues outputting // this string. // Gasstring3(stringout,temp); cout << "\n gasstring3 " << stringout; cout << " \n enter in number "; cin >> temp ; return 0; }
    

    The output of my source code is:

    I think I understood something :-)

    cost < "\n="" gasstring ="" "=""> < lstrbuf(*(*handle_var3)-=""> String [0]);

    There are some macros useful for LStrHandles in "extcode.h", LStrBuf is one of them.

    It seems that there are no problems with memory management, you did it right.

  • Named Instance/Application DLL and LabVIEW FIFO

    Hi all

    I'm working on a logging of sensor application in LabVIEW 8.5.

    Each driver (written in LabVIEW) sensor has its own loop and a named FIFO correspondent the latest read values written in. One of the pilots use VISA for RS - 232 and another DLL call to a library that is interface with a USB - I2C converter.

    The main recorder reads all the of the FIFO, concatenates the data in chronological order they are sampled from the FIFO and writes in a combined log file.

    The third recorder that I add now must be written in C the nature of the sensor with it's interface. Each new data set that comes in will be written to the file. I would like to send a message in the C program to the main recorder that includes the name and the position of all writes data; This information will be concatenated in the main newspaper for purposes of time synchronization.

    My intuition first easy synchronization is to write a VI (compiled into a DLL by using the LabVIEW application builder and called from C) who will use a FIFO named to pass a string to the C recorder for the main recorder. But I don't know how the appointed FIFOs are shared between instances of the application.

    In other words, if I have a reference to FIFO named 'test' in a VI compiled and called as a DLL and a FIFO named "test" in reference to the Application Instance main (or specific application instance to the project running on the same Windows computer), point to the same structure? Alternatively, they are specific to each instance? If they are specific to each instance, what do you suggest me as a method to be less hassle to get data between instances of the application?

    Thanks in advance!

    Bradley Hughes

    My intuition first easy synchronization is to write a VI (compiled into a DLL by using the LabVIEW application builder and called from C) who will use a FIFO named to pass a string to the C recorder for the main recorder. But I don't know how the appointed FIFOs are shared between instances of the application.

    In other words, if I have a reference to FIFO named 'test' in a VI compiled and called as a DLL and a FIFO named "test" in reference to the Application Instance main (or specific application instance to the project running on the same Windows computer), point to the same structure? Alternatively, they are specific to each instance? If they are specific to each instance, what do you suggest me as a method to be less hassle to get data between instances of the application?

    Thanks in advance!

    Bradley Hughes

    Queues, semaphores etc. are not shared between all instances of the application (although they were in LabVIEW 8.0, but it really was a bug). But just because you call a DLL that uses a DLL of LabVIEW with a queue does not necessarily mean that you work in two different application instances. If however you intende to write an independent C program that runs in a separate way of the process you can certainly not connect to a queue of LabVIEW in this way. The LabVIEW DLL will be loaded in the runtime LabVIEW according to but part of your C program process.

    Even if it would make you a C DLL that you call your LabVIEW application and calls said LabVIEW DLL to communicate through the queue, you can be problem. This will not work unless the DLL of LabVIEW and the LabVIEW application that calls your DLL is written in the same version of LabVIEW. In this case, the DLL is loaded into the LabVIEW development system already running or in the case of a DBMS built in the running system. Once your main application LabVIEW and the LabVIEW DLL are not the same version, the DLL will be launched out of process in the enforcement system according to itself, that it really run in its own process.

    Rolf Kalbermatter

  • Load a complex DLLs in Labview

    Hi guys:

    I need to load a dll into labview, the prototype is:

    running long (const char a [],
    const double b,
    const int c,
    double d [5] [23],)
    Double e [4],
    );

    I put the prototype in labview is:

    Uint64_t function (const CStr has,

    const double b,

    const int32_t c,

    Array2DDouble * d,.

    Double * e);

    but the function does not work, I suppose that it maybe some concern to the parameter d, the attached file is the config box,.

    Someone tell me where is the problem?

    Thank you

    Good news. I have fix

Maybe you are looking for