Shared library

Similar Questions

• shared library issues

  Hello

  I have a DLL to my amp and a help file and a header file, but when I try to import the shared library, it has all the functions... Now, I have some functions to a third party, but when I try to:

  getinstancelist-> opendevice-> getsignalformat->-> device nearby stopdevice

  Often, my entire LabVIEW program stops and gives an error. I wish I could do all the functions with the wizard, so that I can be shure that all is well done...

  In the room attached of the SDK, DLL and header files + getinstancelist, opendevice, getsignalformat, stopdevice, near the VI device

  Best regards

  Thijs Boeree

  Found!

  I only 'open' the device in my VI and then tried to 'stop' it (but it has not been started...) Resulting accidents!

  Best regards

  Thijs

• tables as input for the shared library function

  I played with the call of LV VI using matlab.

  So I built a simple VI which returns an integer as input and multiply it by 10, I then put in a shared library and named it MATLAB - well.

  Now, I tried to do the same thing with a table - I want to send a picture to the VI and multiplied it by 10, but when I build the .h file, it seems that the function expects get table of entry AND exit of table as inputs.

  so, how I can build a shared library VI who gets an array (of a constant size if this is important) and multiply it by 10?

  Thank you!

  A function in a DLL can only return a scalar value, not a table, no matter what languages are used. To return an array, instead calling it allocates the array pass a reference to the DLL and then after the function called the referenced table table contains the new data. This is why there are two parameters - the input array (actually a pointer to it) and a pointer (reference) to the output array. You must change your code in MATLAB, there is nothing you can do about it in LabVIEW. EDIT: Also note that it allows to re-use of the input as an output table, optionally passing a reference only to the table of entry and then by changing that. You can do it in LabVIEW by configuring the setting table as input and output.

• When you call a function in a shared library, are copied locally settings?

  I have a shared library with a function which the header is:

  void __cdecl nextevent (double entry [], int32_t len);

  When it is called it sends the values in [entry] to the input control:

  

  This vi is compiled into a DLL that uses the header above.

  Now, my question is: which of these operations is good:

  1. the input control is a reference to the entry in array [], no value is copied.

  2. the values of the Input [] array are copied into the input control, the local copy is used by the vi, then the values of the local copy is deleted/trimmed.

  It seems reasonable that 1 is good, but I can't be sure, and I see no way to check.

  For this particular case, option 2 is valid. The reason is that the tables of LabVIEW are not just pointers to a memory location but the handles. And there is no legal way to create valid LabVIEW handles of a runtime C allocated memory pointer. If LabVIEW transforms the table pointer entering a handle which is basically nothing else that allocate the handle with a sufficient size to contain all the data in the table and then copy the data from the table pointer in this handle. After the call, the handle is properly released.

• Get a precise timing in a C++ shared library in VxWorks

  Hello world

  I am developing a shared library for VxWorks for my compactRio access a «no massive strorage» usb device

  I work with gcc (see develop shared libraries for the cRIO-901 x and other targets of VxWorks for more details).

  The usb part works fine, but I now have to obtain a precise timing in one c++ shared library functions. I tried the functions clockLib (e.g. clock_gettime () - see page 8 of the http://www-ad.fnal.gov/controls/micro_p/manuals/vxworks_application_api_reference_6.6.pdf for more details), but they seem to have a resolution of 1 ms, which is not enough for me.

  There is a clock source faster on the cRio (at least 1 Mhz, one used for timed loops) but I do not know if such a source could be used in a shared library. If so, anyone knows what are the functions of call?

  Thank you very much

  Martin

  OK, I thought about it.  These functions are exported as C functions, so you should use extern 'C' instead of extern just by itself, as I did originally.  Once I did, I was able to compile the following code in its own. File AND it works fine:

  #include
  extern 'C' unsigned long niTimestamp32();

  extern 'C' Sub TimeTest()
  {
  unsigned long ts = niTimestamp32();
  printf ("niTimestamp32 () = 0x%08X\n", ts ");
  }

  Good luck and let me know if you have any problems and more.

• Unable to load the shared library LVASPT_WA.*

  Hello

  I have a hope that easy to fix the error: I want to use the function "WA Detrend' to the signal processing tool advanced in a real-time application running on a cRio 9030. When I try to run the VI I get the following error:

  ...

  Deployment NI_AdvSigProcWA.lvlib:WA decimation Filter.vi

  NI_AdvSigProcWA.lvlib:WA decimation Filter.vi loaded with errors on the target and was closed.
  LabVIEW: Unable to load the shared library LVASPT_WA.*ptDecimationFilterH:C. make sure that the library is present on the target of RT. Either MAX allows you to install software from OR or FTP to transfer custom RT target libraries.

  ...

  I reinstalled signals Advanced processing toolkit and linked things 'add new software' MAX, but the error persists.

  A picture of what the system looks like to the MAX is attached.

  Also, I Fund this post:

  http://forums.NI.com/T5/LabVIEW/problem-error-deploying-item-on-RT/m-p/3201345/highlight/true#M92822...

  could someone tell me what he means by "Please check the installation of the custom software all mode '?

  Can you telll me what I am doing wrong?

  Thank you very much in advance!

  I ran your situation in R & D, and the problem seems to be as a result of Advanced Signal Processing Toolkit is not not compatible on the x 64 under Linux RT OS in the 9030.  The product page could be clearer on this gap.  I am currently a web application to get this fixed!

  Best,

  David

• Create a shared library for NI Linux real-time

  I need to build a shared library for NI Linux time real (.so) which corresponds to a shared library, which I create on Windows (.dll).

  I have the C code that needs to call a function of VI. On Windows, I have a project that allows me to create and build a "Shared Library (DLL)", but I don't see the same option available in a real-time project targeting the cRIO-9068. Am I missing something, or is it not still possible?

  Hi Wayne,

  Using LabVIEW VIs in other programming only possible through dll environments. In LabVIEW there are options for creating libraries and source, but these distributions will be accessible in LabVIEW and not in other programming environments.

  Concerning

• Call to a shared library a VI on a target NI Linux RT (cRIO 9068)

  Hi, I wrote a very small shared library (.so) with Eclipse (toolchain 2014), which essentially serves as a wrapper for more complex, but I am having problems with the call go to in LabVIEW RT on a target Linux RT - specifically, the cRIO 9068. First: the library was copied in/usr/lib and ldconfig has been correctly implemented. More important yet, I have also written a C program (using Eclipse as well) that calls the single function currently implemented in the shared library: this works perfectly, both in Eclipse and you connecting directly on the cRIO with a Putty terminal. So I guess the shared library itself is ok and can be called from code/external programs. Now, dating back to LabVIEW (2014 here btw). Here's where things get difficult, I guess. Initially, I had the symptoms listed here--> http://forums.ni.com/t5/LabVIEW/How-to-create-a-c-shared-library-so-for-linux-real-time-for/td-p/302... who prevented me from actually run any code on the target of RT. Then I changed the call library function node: various tutorials suggest to put name_of_library.* in the path text box or the name of library, but unfortunately it doesn't seem to work, so I had to put the name and the extension too. But it still produces the error below ("the name of the function is not found" etc.) So I check the box 'specify path on diagram' and add/usr/lib as a parameter to the node library function call: now the VI can work and is actually transferred to the target of the RT... but the cluster of output error returns error 7, which is a kind of "File not found" error. However, I believe that this error message is misleading: indeed, if I try to debug remotely this library shared under Eclipse, I am actually able to pause it. and when I press the Pause button on the debugger, the goal of RT VI pauses, then continues as soon as I press the Resume button, I'm stuck... I tried searching forums and Google as well, but I have not yet found a solution. Any ideas on what's going on? Moreover, I can add more details if needed.

  Problem solved, it was a bad configuration of the node library function call which prevented the actual library (.so) to be called.

• myRIO can't find my shared library .so

  Hi all

  I have developed a shared .so library to run on a device myRIO. I moved my shared library for the path/usr/lib of the myRIO. When I run the .VI I get this error:

  Deployment RT.viRT.vi loaded with errors on the target and was closed.
  LabVIEW: Unable to load the shared library libsolve.so:solve:C. make sure that the library is present on the target of RT. Either MAX allows you to install software from OR or FTP to transfer custom RT target libraries.

  Any idea? I reinstalled the software on the myRIO but I still have this error (I comproved if the shared library is on the right track with filezilla and Eclipse).

  Thanks in advance

  Well lets try a little more detailed explanation:

  Firstly the soname parameter is a parameter of time to compile/link in the project of the shared library. I don't have a computer with a handy Eclipse installation but it's somewhere in the additional indicators in probably the settings of the linker where to a shared library named libfoo.so.1.3.6 add something like:

  -Wl,-soname,libfoo.so.1
  

  You would then copy the shared library resulting on the linux system.

  cp libfoo.* /usr/local/lib
  

  After that, you must do a few extra things:

  (1) change the access rights for the file, otherwise ldconfig may not recognize it as an executable file and simply ignore it:

• shared library problem MathScript

  I have a shared library of labview created in labview 8.2.1.  This labview dll contains a three functions, having to turn a number of mathscript embeded nodes inside of them.  The reason for their compilation in a shared library dll is because I want to call this dll of labview 7.0.  I have a test program of work created in labview 8.2.1 and labview 7.0.

  The problem I had is that these executables both run ok on my machine development, but when I move them to another machine with only the installed runtimes (7.0 and 8.2.1) labview dll function calls fail to do anything.  No errors appear, so it is very difficult to find where the problem occurs.    I have two different dll called in the example program.  The first dll just manages the file access and has not all the mathscript in bits, but the second, which is the one that I'm really interested in, has the mathscript node.  The memory usage in looking, I see it's the appeal of the file access dll but do not do the mathscript one.

  I have installed an evaluation version of labview 8.2.1 on this laptop with only the runtime, run the program and it works fine.  I think there must be something not in the dll but I don't see anything in the options to add something.  I have the mathscript check box selected in the build option.

  I know there are a number of functions that do not work with just running, but I'm not all there that use my program.

  Does anyone have advice?

  OK, I found the solution to my problem.  It was a problem with the version of the runtime that I used.  Labview CDs development is only a partial performance and include all of the files to run applications full (time to install it on his own).  Go to the website of national instruments, there is a period of standard edition which includes everything you need.  Download and install this version seem to have solved the problem.

• import the shared library function name change

  Hello

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

  It has this error:

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

  Details:

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

  How can I solve?

  Thank you.

  Hi Salvo,

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

  Kind regards.

• Is Linux - possible to build a shared library that calls other libraries shared without having to make a static link to them?

  Hello

  Operating system = Linux (Ubuntu 14.04 LTS 32-bit)

  I am building a shared library *. so.  This *.so should be used by LabVIEW.  This *.so is calling other functions in shared libraries.  In my case, the other library share is libxml2 and libz.  The only way I could compile my shared library and operate was a static link from libxml2.a and libz.a.  Is there a way to make a dynamic link?

  Here's the makefile file that I use.  The goal of 'TestValidateSchema' compiles the shared without the static link library and this shared library is called by an application to test 'c' and it works.  Now, to make it work in LabVIEW, I need to make a static link, as you can see in the target ' install: «otherwise the function "call library node" throws me a symbol unresolve...»»

  This is the only way to do it and if yes why?

  Thank you

  --------------------------------

  CC = gcc

  all: TestValidateSchema

  TestValidateSchema: testValidateSchema.c
  $(CC) o Release/validateschema.o - c - wall - Werror - fpic Src / validateschema.c - I. / Include-I/usr/include/libxml2
  $(CC) - shared-o./Release/libvalidateschema.so./Release/validateschema.o
  $(CC) - wall o ./release/testvalidateschema testValidateSchema.c./Release/validateschema.o-lxml2

  clean:
  $(RM) $(OBJS)./Release/testvalidateschema./Release/libvalidateschema.so./Release/validateschema.o /usr/include/validateschema.h /usr/lib/libvalidateschema.so

  install:
  $(CC) o Release/validateschema.o - c - wall - Werror - fpic Src / validateschema.c - I. / Include-I/usr/include/libxml2
  $(CC) - shared-o./Release/libvalidateschema.so./Release/validateschema.o Src/libxml2.a Src/libz.a

  --------------------------------------

  In addition to what said Daniel on the specification of an external shared library in the liaison stage of your version of the shared library, together with the - shared option, there is still one thing to consider:

  Your library of hello.so then contains references to functions in external shared libraries libxml.so and zlib.so. When LabVIEW calls dlopen ("/ path/dir/hello.so",...) it basically hands of any control in the linker Linux running, ld.so that takes care of the rest. LD.so then try to load the shared library, recognizing that there are external references and try to solve.

  First he tries to match the missing external references to any symbols that have been previously loaded into the current process already. If this is not successful for a particular system, it queries the ldcache for a library and a symbol. ldcache is updated with the ldconfig program. When you add a new shared library on the system that you want the linker ld.so runtime in order to find, run ldconfig.

  NOTE: Running ldconfig is not normally necessary to shared libraries that access you directly via the node call library, as you specify here the full access to your custom library shared already, so path ld.so will fail immediately if it is not the library specified in the given absolute position and will not attempt to query ldcache at all.

  If you are installing packages through your package manager platform update ldcache for all publicly accessible libraries shared in these packages is usually done automatically for you as part of the package installation script. If however you manually install the libraries you need to run ldconfig yourself. In your case, you could add the libxml.so and/usr/lib zlib.so and simply run ldconfig from the command-line as it default search/lib and/usr/lib for libraries shared and rebuilt the ldcache from that. If you add your new libraries in a different directory on your computer you need to run ldconfig with - n option, saying what directory the new shared libraries have been installed.

• How to create the shared library for linux real-time target in labVIEW Windows?

  I use myRIO running linux in real time. In my project, I need to pack some C code, so I tried the node library function call.

  I know that I should use the tools compile cross - compile linux on Eclipse to compile c code in linux .so library. But the problem is that call library function node does not recognize the .so file because my labVIEW runs on a Windows PC.

  What should I do to fix and how to combine C code with labVIEW during programming for devices shipped as myRIO?

  Basically, you must also create a Windows DLL that exports the same functions. These functions can be empty stubs if you do not want to run the code correctly on Windows, otherwise you will need to consider how to implement the equivalent functionality on the Windows API.

  Then you can write in your node library call as the name of the library ". "*" and the name of the shared library Windows ".dll" while the Linux version is called "name of your library > .so". LabVIEW will replace the * after the comma in the name of library with everything that is the preferred extension shared library for the platform it is running on and therefore load the right shared library.

  Alternatively you can wrap call all the nodes of the library in a structure that contains the node library in the case of Linux RT and all what you want to run on other platforms in the case of default or a case of specific platform, call the conditional compilation.

• Warning message about the shared library file

  I got this warning message when I try to open the sample xml configuration.

  C:\Program NIUninstaller Instruments\LabVIEW reference (Impl) 8.6\vi.lib\xml\Close .vi (NI_XML.lvlib: Close Reference (Impl) .vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW .vi reference (NdList) 8.6\vi.lib\xml\Close (NI_XML.lvlib: Close Reference (NdList) .vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW .vi reference (NNMap) 8.6\vi.lib\xml\Close (NI_XML.lvlib: Close Reference (NNMap) .vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW reference (node) 8.6\vi.lib\xml\Close .vi (NI_XML.lvlib: Close Reference (Node) .vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW 8.6\vi.lib\xml\Get Child.vi first non-text (NI_XML.lvlib:Get first non-text Child.vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW 8.6\vi.lib\xml\Get Sibling.vi non-text next (NI_XML.lvlib:Get next non-text Sibling.vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW 8.6\vi.lib\xml\Get text Content.vi (NI_XML.lvlib:Get text Content.vi node) node
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW 8.6\vi.lib\xml\Load XML File.vi (NI_XML.lvlib:Load XML File.vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."
  C:\Program NIUninstaller Instruments\LabVIEW 8.6\vi.lib\xml\New.vi (NI_XML.lvlib:New.vi)
  -The shared library should happen to "": \addons\internet\dom\DOMUserDefRef.dll "has been charged with"DOMUserDefRef.dll"."

  I've recently updated to 8.6 and I try to compile an executable, but b/c of this warning my executable is not running sends me weird errors. I took the code that calls the XML that is read, and it is fixed. How should I do? Thank you!

  I get this error message when I tried to run the .exe with the xml configuration reader.

  "The application failed to start because xerces - c_2_7.dll was not found. Reinstalling the application may fix this problem. »

• Unable to load the shared library nilvce.*

  When you try to deploy a Labview 2009 real-time application, I get the message:

  Deployment XDNodeRunTimeDep.lvlib:loadnilvce.viXDNodeRunTimeDep.lvlib:loadnilvce.vi loaded with errors on the target and was closed.

  LabVIEW: Unable to load the shared library nilvce. *: niLVCtrlEngineReserveProc:C on the target RT device.
  Completed with errors of deployment

  I reformatted the CRIO-9073 and reinstalled the software, but this did not help.

  Any ideas on how to solve this problem?

  I was able to solve this problem by changing the settings in a timed loop Structure.

  The Source Type has been set to "synchronize in the scan engine.  This change to the problem solved 1 kHz clock source.

  This vi was initially written for the interface of the scan engine and reused on another project that uses the FPGA interface.

• Error during the generation of shared library for OSX

  Hello

  I am trying to build a shared library (.framework) using LabVIEW 2011 as Mac.

  My Version of OSX is 10.7.3.

  When I run the build process, TI allways give up showing the error message:

  There is 1 error in DLL - C compile Source File.vi Possible reason (s): you must have the Apple Developer tools installed to build a shared library. Install the Apple Developer tools and attempts to reconstruct the shared library.

  I don't know what developer tool is missing or if there is another problem with my environment.

  Thank you

  Gschwert

  Hi Gschwert,

  in the meantime, I received a response from our developers in Austin.

  Developer Tools Apple which refers to should be X-Code.

  They work with X-Code Version 3.0 and have no problem. They will try to work with your versions (4.2 and 4.3) too and take a look, if there is something special to look for.

  Have you tried using X-Code 3.0? Then you get the same problems?

  Good day