DLL labview

Similar Questions

• Return value of DLL LabVIEW Build to the Prototype of the function

  Hi all

  I know LabVIEW can generate a DLL with return value with a function like prototype

  Sub nomfonction (arguments);

  We could define the return value to arguments.

  However, LabVIEW build a DLL with return value instead of "null" in the United States

  int nomfonction (arguments);

  In fact, I could achieve this when my part of connector VI has a 1 linked indicator.

  I could get my prototype of function dll in the application as Builder

  Double functioname (void); or well functioname (void); or some

  Although I could do above, this applies only when my VI has 1 single output.  If the VI

  1 more arguments, I still get

  Sub nomfonction (arguments);

  So I missed something? Or is this a limit of LabVIEW?

  Please don't get angry if this question has been asked before, I'm lack of subject

  LabVIEW to communicate with other languages.

  Thank you

  Jean Cyril

  You can.  In the construction specifications, under source files, go to set your prototype.  on the right, there is a drop down 'Output VI' which is what you want.  Note that I only saw him able to return numeric values.

• Functions of DLL Labview only each returns 0 when it is called in C

  Hey guys. I'm having a problem using a dll built in labview in my code C. I did a labview program that read the current analog signals 7 analog pins and them stored in a table. Then I have a variable that corresponds to the index that you want to localize (whenever the function is called I don't read only one current value of the table) and then put this value into a digital indicator that is the result I want.

  It has worked well in labview, but after I generate a DLL to it and call the function in my c code it always returns 0 instead of reading of the axis. Even when I put constant values in the table, when I call the function I always get 0. I also did a labview program who just returned a constant number by pressing, and when I built as a DLL and calls the function in my C code it issued yet only 0.

  I am very confused how this happens. I have connected the digital indicator to the connector and component when I build the DLL it claims that I'm a function that is:

  Double Test1 (double Index)

  Where "double index" is the index of the table that I want to read, and the return value is the digital indicator that contains the value at this level.

  I call the funcition in my C code as follows:

  #include "SharedLib.h" //This is the header for the DLL file. I also include .lib, .dll, .ini, and .alias files
  #pragma how (lib, "SharedLib.lib")

  Double i = 0;   just for an example, I'm access at index 0 of the table, which I set to a constant value

  values = Test1 (i);  It will always return 0, regardless of what the index is

  I guess my big question is how is it possible to get the labview function built DLL to run C code but only eery return 0? I can show you all my Labview code, but as I tried several functions to try to get a value not zero to not think availI miss me something else which isn't regardng real labview code. Thank you very much!

  Indexing by a double seems to be ok in Labview. I understand the problem however. The labview functions actually worked, I was just incorrect printing. I was really stupid and my printf statement was printf ("%d", value) printf ("% lf, value) which is what you need for the double rooms, and he did print always 0. Thanks for your help though guys.

• LabView VB6 Dll interface causes memory leak

  Hello

  We use a large written in vb6 in our laboratory measurement built house software. Recently, we have added a new detector that is read using a labview vi that is called using a dll directly from vb6. Here, we call the function for example of read_detector which starts the collection of data and in a next step writes the data to a string. When you have finished the called function returns a pointer to the string and its length. VB6, we read this pointer and process data.

  This is a memory leak. This could be the case because we presets not memory for labview to write in and so just writing lab data in memory without releasing again? In the current configuration, the function of the dll is just called again and again and each lab view creates a variable outputstring.

  If we allocate the memory. How can we achieve for vb6?

  Best,

  Julian

  Well first of all, a handful of string LabVIEW is a very specific type of data LabVIEW. Not only is only LabVIEW himself knows exactly how to allocate and deallocate, but you must also allocate and deallocate in exactly the same instance of LabVIEW. Given that your LabVIEW DLL is executed for this purpose inside the DLL to run LabVIEW, you must also recover the LabVIEW memory manager functions according to DSDisposeHandle() of the lvrt.dll and call it after you are finished with the strings returned by the DLL function. This is however made very complicated since there are circumstances where not lvrt.dll is actually used by your DLL but another LabVIEW runtime system. And if you happen to have two DLLs created with different versions of LabVIEW LabVIEW, each of them will load and use its enforcement LabVIEW system according to DLL load next. Believe me, you don't want to know how next dll works and how to make this opportunity to work in an application. This is the way for Microsoft to create a monster to manage the hell of the DLL and in this way, rather to create exponential version of hell.

  You create just two memory leaks for each call of DLL function at the moment. LabVIEW creates a new handle of string for each of the parameters string at each call, you dereference the pointer, and then copy the contents into a SysString. But you let the chain handles LabVIEW blow created around the stack and the next your function call, you initialize the new variables of the battery which is initialized to null and LabVIEW creates two new handles. Also you need to do is to define an "Integer DSDisposeHandle(LStrHandle As Long)" exported lvrt.dll function and call it once you have copied the data of the handle in your SysString for both of these handles.

  But basically calling a DLL LabVIEW from no LabVIEW code and using LabVIEW handles string or array as parameters is several times more trouble that it's worth. The easiest would be fair, allocate a large enough buffer beforehand and pass those to the Configuration of the service DLL LabVIEW function to not accept a handful of string LabVIEW but a pointer to a string C instead. Do you work around the problem on the memory allocated by someone else to worry about your own program of VB and duty he properly release. The disadvantage of this approach is, that you should make sure that the memory allocated buffer is large enough for the maximum possible length that your DLL function may never return.

  But another approach might be to leave out LabVIEW total here and call the DAQmx APIs directly from VB.

• LabVIEW created DLL that uses Labview live integrated Toolbox "DFD" (Digital Filter Design)

  We were using a Labview created the DLL file that uses the screws of the DFD Toolbox, but were not able to operate at all. Now, we have replaced the DFD screws with screws that built us, and the DLL file works fine. Is there a reason for this?

  Even if it works, this process is medium long and it's a waste of time because the DFD screws are already being implemented, so we need a quick fix for this, any suggestions.

  When you use the DLL that uses the DFD screws, it always seems to be a failure when loading the DLL file specific screws, anyone know why? Screw looking for Labview is in a way that looks at "DllFileLocation.dll------Labview 2009------vi.lib------...» "

  Thank you

  Walid Farid

  
  

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

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

• can I create a DLL file for labview that has DLL library with inside?

  Hello everyone,

  I am developing an application for the cards PCI devicenet in labview (beginner to labview) environment.  Is there a DLL file for the PCI card from the provider. But it's too complicated for a beginner to call each function in the DLL of labview. Therefore, I'm trying to re - use a VC ++ program (working properly) that calls some sellers DLL library functions.    To do this, I created the DLL file which includes all headers and libraries the provider DLL, as indicated in the attached figure. But I couln can't see the effect on the device. is it possible to create a DLL file for labview that has DLL library with inside? If this is not the case, how can I implement the program shown in figure?

  I would like to wish a huge as to advance.

  It is not something I have a lot of experience in so I don't know all the details of the restrictions or requirements etc - but it is certainly possible to create wrappers for the dll and then use them in LabVIEW - this is sometimes necessary to convert some native types/data structures in C/C++ into something that you can switch to your other DLL LabVIEW.

  There is a link here: http://digital.ni.com/public.nsf/allkb/06ECDC689DDA0F3D862574440074CD95

• LabVIEW built of DLL in an application multi-threaded C++, need help!

  I'm working on a software application which is developed mainly in C++. There is a component of this larger application, however, develop in LabVIEW (for several reasons that I dive in here). This LabVIEW code is therefore run in a C++ wrapper class that calls a built DLLS LabVIEW.

  All this was fine and dandy, until we decided to multi-threaded, our C++ application for an increase in performance. Accordingly, the LabVIEW DLL now is called from multiple threads simultaneously. While this works on a functional level, it seems to create a bottleneck.  All my tests, it is resource locking occurs, such that only one thread has access to the .dll at a time. If I do the .vi used to define the dll as a non-reentrant function prototype so it's what we see. For example, say we have 3 sons all calling the same .dll method call. Thread 1, 2, 3 and all call the .dll file in a few milliseconds of each other. Thread 1 has completed the call .dll after X milliseconds. Thread 2 has finished the .dll call after 2 X milliseconds, and wire 3 full after 3 x milliseconds.

  Now, changing the vi home and runs the same test, we see wire 1, 2, 3 and all end them the call of .dll in 3 x milliseconds. While the fact that they are now the same amount of time to complete you would lead to believe they are spend at the same time, the fact that it takes 3 x milliseconds as opposed to X milliseconds means that they are not.

  Has anyone ever dealt with these issues before? Is it possible to play with the "delivery system" for the vi will have an effect? What happens if .dll methods while remaining attached to the same .dll are called from different threads? Same behavior? Is it a lost cause? Is there any way to make the code in a DLL only built LabVIEW run in two different threads at the same? What I understand is easily achievable with a normal (non - built LV) .dll.

  Please, if anyone has any advice in this area, let me know!

  Much appreciated,
  Jesse Hurdus

  Hi jhurdus,

  I know that you are working with an engineer OR this question, but I wanted to post a reply to one of your last questions.

  When you use the function node library call in LabVIEW, there is the possibility to select 'Run in the user interface thread' or 'run in any thread '.  This option, according to the help file for LabVIEW (dialog box call library functions), allows the developer to pass thread library function node call from the (default) user interface thread to the thread that the VI is running.  Additional details of when you want to switch the thread of execution are in the help file.

  Kevin S.

  Technical sales engineer

  National Instruments

• Unable to get the element of the array by LabVIEW table Handle in DLL

  vc code follows:

  #include "extcode.h".

  / * LabVIEW created typedef * /.
  typedef struct {}
  dimSize of Int32;
  Double elt [1];
  } TD1;
  typedef TD1 * TD1Hdl;

  extern "C".
  {
  _declspec (dllexport) void CINRun (TD1Hdl input, double * output);
  };

  _declspec (dllexport) void CINRun (TD1Hdl input, double * output)
  {
  Failed to get the first element of the array passed to DLL LabVIEW
  * Output =(*Input)-> elt [0];

  If change the above code as follows
  * Output =(*Input)-> dimSize;
  It is then managed to get the size of a dimension table.
  So, what's the problem?
  }

  the labview vc and program project are attached.

  the problem is: run the program labview, can not get the good result of the table

  Thank you

  Chen

  You have made two errors:

  Error 1 (alignment!):

  

  Error 2: passing parameters:

  

  Change it as above, and it should be OK.

  Andrey.

• LabVIEW.lib or labviewv.lib?

  Hello

  I'm writing a C++ DLL that interacts with the LabVIEW code, which uses features of LabVIEW Manager. The linked article says I should link against labviewc.lib, but there is another similar library called labview.lib

  What is the difference between them? Which should I use?

  JKSH wrote:

  Hello

  I'm writing a C++ DLL that interacts with the LabVIEW code, which uses features of LabVIEW Manager. The linked article says I should link against labviewc.lib, but there is another similar library called labview.lib

  What is the difference between them? Which should I use?

  It's labviewv.lib not labviewc.lib! Generally, you should use labviewv.lib for all new development. It handles better on the right the LabVIEW core binding when you have complex situations such as a DLL LabVIEW (screw of LabVIEW compiled into a DLL) that uses the DLL and when that LabVIEW DLL is called from a LabVIEW system which is a different version of which was used to create the DLL of LabVIEW. With labview.lib, this scenario is very likely create a chaos he is trying to link to the system LabVIEW calling instead of runtime DLL runs under.

• LabVIEW C code

  I was wondering if there is any means possible to convert my LabVIEW VI (build with call loops and its case) in a C code based, or anything like that which are closely related to the C code. The reason is that most of our measuring instruments are controlled with C code base and we must integrate labview c.

  see you soon

  Add: be aware that if you create a DLL LabVIEW the target machine must installed LabVIEW runtime engine. For the same reason that you need Java installed to run Java code, or the runtime Matlab installed to use Matlab dll or .NET installed to use .NET assemblies, or...

• call LabVIEW screws in Visual Studio Express

  Hi, I have LabVIEW 2013 and I create a Vi in which I control some signals input and output for a NI PCIe. This VI must be integrated into a larger program developed in C++ in Visual Studio community 2015. Searching the net I found a lot of topics on the use of Visual Studio DLLs in LabVIEW, but I think in this case, I do the reverse process, because the main program runs in Visual Studio and I should call the LabVIEW VI from there. So my question is: which are the steps to do this? Any suggestions would be very helpful!

  If you have the Application Builder or professional development system you can not only create LabVIEW code executables but also dll. Turn your VI in a DLL and call your application Visual Studio. Alternatively you can also select to create a .net assembly and call it as such. For C++ but I would choose the path of the DLL.

  A few notes: a DLL LabVIEW requires the LabVIEW runtime to be installed on each computer that you want to use this DLL on. Also of course all drivers additional as DAQmx etc. If you use them in your screws. You can create an installer too when you have the Application Builder that includes all the dependencies, if you want.

  Last but not least LabVIEW dll (and executable files) are compiled for the target architecture CPU on which they are created, so if you use a LabVIEW 32 Bit in a 32-bit Windows process, the resulting DLL will be only executable. It is not a WinRT component which you can go from one platform to another platform.

• Sinc filter using the DLL implementation

  Dear all,

  I'm trying to implement a sinc filter to a data flow that I receive from card FPGA. The C code is already working and now I'm trying to do is to implement the same algo on LabVIEW or make DLL and use it and I'm doing the later approach (don't know which one is better, any ideas?). I use this tutorial and it works very well for me in the case of the same example IE multiplication please see the VI attached.

  I'm getting streams of raw data in the .csv file, and then I like to read this file. So what I have to do is apply a sinc filter so that every 32 points in this data set will be 1 sample for my position. I enclose you an example of a .csv file for data, a txt file of code C (for just to give you an idea of 3rd order) who work already, my dll and VI.

  More specifically I have problems about the selection of parameters for the DLL for example what should I choose in the settings of the DLL LabVIEW function that corresponds to "unsigned char * data" as well as for others, as written in the C code. If someone can provide me with some VI he created to implement the sinc function or some ideas it would be also great.
  Any help or advice you guys will be highly appreciated.

  Kind regards

  Kuhn

  There are a lot of discrepancies between what you do in your VI and that your text file watch is C code.

  (1) the order of the parameters is VERY different.

  (2) you are using int64 in the LabVIEW diagram, but int in C code. Under 32-bit Windows and 64-bit (and also Linux), an int type is ALWAYS a 32-bit value.

  (3) read you in a table 1 d of channels and proceed to the node library call as native data. This requires a handful of LabVIEW LabVIEW handles string table. Expect a VERY big difference to byte array pointer in C code.

  You convert the strings in a byte, and then configure the node library call to pass it as an array of integers not signed 8-bit, passed as a pointer of table data.

• Report to DENY using LV 2011 built dll crash

  I have an application that uses a built DLLs LabVIEW.  LV dll is called by a dll ActiveX component integrated into VS 2010.  The dll of the LV was origninally built using LV 2010 and worked well.  When we build the same application using LV 2011, everything works up until the closure of the top-level application.  We are then prompted with a dialog box telling us that a failure has been detected (journal text below).  The error occurs if we use static or dynamic linking to the dll.  If I disable DENY it to the application, there is no problem; If as we use a component ActiveX, I must create a for the calling application ini file or disable the DENY for the entire system.  None of these options is desirable, because we cannot know all applications that could use our ActiveX module and cannot control each system we will be deployed on.  If we do not find a work around that, we will have to go back to LV 2010.

  ####
  #Date: Thu, October 27, 2011 13:28:20
  #OSName: Windows 7 Professional
  #OSVers: 6.1
  #OSBuild: 7600
  #AppName: home page
  #Version: 11.0 32-bit
  #AppKind: AppLib
  Base address of #LabVIEW: 0 x 30000000

  27/10/2011 1:32:41.891 PM
  Crash 0 x 0: Crash taken to DENY
  File Unknown (0): Crash: Crash captured by DENYING
  Minidump ID: 6972c89d-ba7b-437a-9d41-d3df28550f98
  ExceptionCode: 0xc0020001y
  N

  I think I've solved my problem, which I will describe in the case where the same thing is happening to others.  The root of the problem, near as I can tell, had something to do with the appeal of the LV dll of in another dll. For some reason, when I linked statically to the dll, the DllUnload process caused this crash report.  I found evidence to suggest that this can occur when you unload a dll from in the process of unloading in another dll on the web; as is the case with static linking.  When I tried dynamic link, I initially tried to use a global instance of the HINSTANCE dll who got charged and discharged with the WinApp object, the result would have been basically the same.  If I connect dynamically to the unload dll event and explicitly the dll before the call dll being unloaded, the problem disappears.  My calling dll is an ActiveX application, I tied to the instance of the dll to the COM object rather than the object WinApp.

  Still don't know why it's a problem for LV 2011 and not 2010 LV.  Perhaps the 'crash' still past and just has not been reported significantly since the app was close anyway.  I'm not sure.  Anyway, hope this helps people out there.