Jump to content

Search the Community

Showing results for tags 'shared library'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 3 results

  1. Hi everybody, I am wondering whether or not it is possible to call the functions of a dynamic library over a LAN connection, without needing to control a VI on the server using the LV remote server (my server is Win7 embedded on an SSD, so not much resources to waste running the RTE). Does the "Shared library file is not on the local machine" checkbox allow that when using the Import Shared Library wizard? Is there any easier solution than implementing a protocol over a TCP connection to access my DLL's functions? Thanks in advance, Sylvain F.
  2. I'm trying to automate dll import using Jenkins. So the question is: is it possible to import dll in Labview using some sort of command line? Right now i have to do it manually by going to Tools>>Import>>Shared library (.dll). Then i have to select dll itself and .h file, wait a little and get my library. Every time dll and .h file changes (which happens with every new revision) process has to be repeated. It would be nice to automate it though. Any thoughs? Thank you in advance!
  3. I need to provide a customer with a dll library with function prototypes that exactly match a provided .c header file. I would like to use LabVIEW if at all possible, as fast turnaround on source code modificaiton may be required. LabVIEW cannot export a function with a char* return type (verified by LabVIEW R&D), thus the customer application directly calls a thin wrapper dll (written in CVI) which then calls into the LabVIEW based dll. I have a subvi that is called by one of the exported VIs. This subvi acquires and analyzes waveform data from an instrument. Memory for a significant waveform (on the order of a MB) is thus dynamically allocated within the subvi. The waveform is not passed up to the caller, and the exported VI returns only a scalar double. If I remove the subvi from the exported VI's block diagram, other Exported functions behave as expected, However if the offending subVI is added to the block diagram of the exported VI, other exports in the DLL always return a value of "0" (default value for most numeric data types?). This is regardless of whether the Export that includes the SubVI is even called within the client application. It seems that the mere inclusion of the offending SubVI breaks the entire dll. Both the LabVIEW DLL and the wrapper DLL(which is in CVI) use only the cdecl calling convention. I get the same behavior for LabVIEW 2011 and 2011 SP1, and for CVI 2009 and 2010. I'm testing using MS Visual Studio C++, since that is the environment for the client application. Behavior is the same in VS 2005 and VS 2010. I definitely appreciate any insights or ideas regarding how to seek a resolution.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.