Call a C-built DLLS in LabVIEW

Similar Questions

• Programming a c application that calls a *.so built by LabVIEW.

  Hi all

  This question has probably been asked, but I can't find the answer.  So here's my question:

  I built a *.so LabVIEW under Linux and I would like to call from a 'c' application  The *.so LabVIEW returns a set of strings, and I want to know how to call from my c (memory allocation?) application.

  Here's the *.so source code, the function is named "testvi":

  

  Here is the source code of my c application:

  #include 
  #include 
  #include "testclusterofstrings.h"
  
  int main()
  {
      Cluster_Of_Strings clusterofstrings;
  
      Testvi(&clusterofstrings);
  
      printf("-------------\n");
      printf("String_A: %s", (*clusterofstrings.String_A)->str);
      printf("-------------\n");
  
      return 0;
  }
  

  I am getting the output when calling my next application:

  LabVIEW caught fatal signal
  13.0 - received SIGSEGV
  Reason: address not mapped to the object
  Try to reference the address: 0x0x19f5c381
  Segmentation fault (core dumped)

  So, what is the right way to do it?

  Thank you

  Michel

  smithd wrote:

  If it is a dll built labview and you pass parameters by reference, I'm not too surprised to initialize (although I expect labview to be kind enough to allocate the data structures for you). Maybe if you spent it a pointer to null instead it would work? Since your original post, maybe try this:

  int main() {}

  Cluster_Of_Strings * clusterofstrings = NULL;

  Testvi(clusterofstrings);
  .... }

  For some reason, I remember reading that labview will interpret the null as a sign that it must allocate the structure, but I could be completely crazy on this point.

  If it does not, then Yes you will have to allocate all the handles according to the case. Of \cintools\extcode.h you can see that a string is defined as follows:

  typedef struct {}
  Int32 cnt; / * number of bytes following * /.
  uChar str [1]; / * cnt bytes * /.
  } LStr, * LStrPtr, * LStrHandle;

  Since you have arrays of size-0 I think you really need to call DSNewHClr(sizeof (int32)) which will allocate a handle with all 0, and 0 is what you want. End result would be...

  int main()
  {
  
      Cluster_Of_Strings MeasInfo;
  
      MeasInfo.String_A = (LStrHandle)DSNewHClr(sizeof(int32));
      MeasInfo.String_B = (LStrHandle)DSNewHClr(sizeof(int32));
  
      Testvi(&MeasInfo);
  ....
  }
  

  Oh and for string functions, make sure that you look at the built-in functions first before making your own.

  In fact, all this is as well a little easier and more complicated at the same time. LabVIEW is entirely managed with its data types, but you must follow this management contract when you interface LabVIEW C code.

  First of all, the first attempt to assign a string handle with sizeof (int32) + sizeof (uChar) bytes without initialization of the length element is bad. This element of length can contain any value and cause LabVIEW wrongly that the handle is already large enough to fill its data and not to do anything and then by writing over the end of the allocated buffer.

  Also equipped to initialize the structure with the value NULL is not going to work. This group should be provided by the appellant that this is a region of data of fixed size passed as a pointer. However, initialization of the string inside the cluster with NULL handles should work fine, since LabVIEW considers NULL manages as the canonical zero length handle.

  However after calling the LabVIEW DLL function you are the owner of all memory that is allocated by this function and comes back to you, just as you would be if you had allocated those manages yourself before the call. So label correct is also deallocate it and it is not an option, but a requirement or you create memory leaks. He isn't getting noticed here since your test program ends in any case just after, but he bite you bad in a larger application if you forgot it.

  The code would then look like this:

  int main()
  {
      Cluster_Of_Strings MeasInfo;
  
      MeasInfo.String_A = NULL;
      MeasInfo.String_B = NULL;
  
      Testvi(&MeasInfo);
  
      printf("-------------\n");
      printf("String_A: %s\n", LV_str_to_C_str(MeasInfo.String_A));
      printf("String_B: %s\n", LV_str_to_C_str(MeasInfo.String_B));
      printf("size %d", (sizeof(int32) + sizeof(uChar)));
      printf("-------------\n");
       if (MeasInfo.String_A)            DSDisposeHandle(MeasInfo.String_A);        if (MeasInfo.String_B)       DSDisposeHandle(MeasInfo.String_B);   return 0;
  }
  // Returns the pointer to the string buffer in a LabVIEW string handle that has been made// sure to be zero terminated.char *LV_str_to_C_str(LStrHandle lv_str){    if (lv_str && !NumericArrayResize(uB, 1, (UHandle*)&lv_str, LStrLen(*lv_str) + 1))    {        LStrBuf(*lv_str)[LStrLen(*lv_str)] = 0;        return LStrBuf(*lv_str);    }    return NULL;}
  

• Create dllmain for labview built dll

  I have a lot of labview code I want to turn it into a DLL. The dll will require some global state initialization after cleaning on process_attach and process_detach. If I was building the C code DLL, that I would create a DLLMain function to take care of this, however when I look in the properties of specifications of generation of a DLL in the LabVIEW Project Explorer, I can't find an option to set my initialsation code and stop. Note that I use LabVIEW 8.6.

  On another note, in looking at the docs for the Call library function node we're talking reminders for the reserve, cancel and abort. What does mean to 'reserve' and 'Cancel '? The description suggests that these reminders can be used for initialization and cleanup but I see not how make use of this in a context where my labview built DLL could be described as some other environment (e.g. an exe written in C).

  I'm still fairly new to LabVIEW so I apologize if I missed something obvious.

  DLLMain is VERY limited in what it can do without causing a charger global potentional lock in Windows System. The execution of LabVIEW VIs is something requiring an infrastructure that is not safe for DLLMain initialization already almost 100%. So there is no way that I can see, LabVIEW could allow you to run a specific VI at load time. And change DLLMain yourself isn't an option either, given that LabVIEW that creates on the fly for each DLL and the code is quite tricky.

  What is the problem about the design of your DLL in such a way that the user must call an initialization function explicitly before using other features in it? After all there is no global state in a LabVIEW DLL, except by functions that are loaded into memory and remain in memory for as long as you want to maintain global state. Once function initialized global X() a memory of leaves before the Y() function that references global was loaded into memory, the enitre a global state is lost and reset to the default state when loading function Y().

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

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

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

• 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

• Cannot use MATLAB MCR DLLS in LabVIEW

  General information:

  We would like to call a Matlab compiled DLL, which is based on the duration of the compiler Matlab (MCR), LabVIEW. We also want to use the LabVIEW Vision of data collection software. Use a map OR frame grabber is installed, and a camera is connected to the card. We were using an evaluation version of LabVIEW to see if you can solve this problem. We tried two versions of LabVIEW 8.6 and 2010.

  The problem:

  The installation program of LabVIEW place dll in the system32 folder. The names of some of these DLLs are generic enough. LabVIEW vision software includes tbb.dll in the System32 folder. Execution of the Matlab compiler also includes a tbb.dll, not in system32, but in it's own application directory. LabVIEW DLL / so everybody, which is kind of rude, but little matter which at the present time. The biggest problem is when I try to use Matlab in the same process as LabVIEW Vision. It is not possible to do so, because the names of DLL in conflict between them, and I have no control over the source or Matlab and LabVIEW code to allow them to be charged with the full path name.

  For this reason, we can use the LabVIEW software to solve our specific application.

  Hi marcus,

  R & D is aware of this problem and it has already been established as part of the Corrective Action that requires #245249. You can watch the future versions of LabVIEW release notes to see when it is fixed.

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

• 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

• 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

• DLL Interop.LabVIEW

  Where can I get a copy of the DLL Interop.LabVIEW for use with c#, or do I have to write my own?

  
  

• String of DLLS in LabView in two strange characters

  Hello. I pass a string of DLLS in Labview and the result is correct, but there are two characters strange everytime "Gn".

  If the character that I spend is 'a', then the result is «a LARP»

  My DLL code is:

  void massiv_int(char *lv_ptr);

  _declspec (dllexport) void f_massiv (char hello []);

  _declspec (dllexport) void f_massiv (char hello []) {}

  char lv_str [10];
  char * lv_ptr;
  lv_ptr = & lv_str [0];

  massiv_int (lv_ptr);
  * Hello = lv_str [1];

  }

  void massiv_int(char *lv_ptr) {}

  char lv_local [10] = "abcdefg";
  memcpy (lv_ptr, lv_local, 10);
  }

  Could you tell me, what could be wrong?

  Thanks in advance.

  Try this:

  void massiv_int(char *lv_ptr);
  void massiv_int_NextLine(char *lv_ptr);

  LVSTR_API void f_massiv (char hello []) {}

  char lv_str [10];
  char * lv_ptr;
  lv_ptr = & lv_str [0];

  massiv_int (Hello);

  massiv_int (lv_ptr);
  * Hello = lv_str [1];
  }

  void massiv_int(char *lv_ptr) {}

  do lv_local as long as necessary (no extra characters)
  Char [] lv_local = "abcdefg";

  copies all of the characters in lv_local to lv_ptr
  strcpy (lv_ptr, lv_local);

  Add the following line
  massiv_int_NextLine (lv_ptr + strlen (lv_ptr));
  }

  void massiv_int_NextLine(char *lv_ptr) {}

  do lv_local as long as necessary (no extra characters, including LF)
  Char [] lv_local = "\nqwerty";

  copies all of the characters in lv_local to lv_ptr
  strcpy (lv_ptr, lv_local);

  }

  But make sure that the external string buffer allocated by LV is long enough to contain all the characters!