Jump to content

Fastest way to exchange string between a Labview DLL and Labview program


Recommended Posts

I'm using a Labview Shared Library (DLL) to comunicate between a C# program (made by another company) and a labview Executeable (which means different processes) on the same PC. Currently i'm using network published shared variables, to communicate between the Labview DLL and the LABVIEW program (both made by me) which works well, except for the performance.

 

Each time the DLL is called it needs to connect to the shared variable, which takes between 50 and 300 ms. When it is connected, the data transfer is instant. I have tried to use the PSP "Open Variable Connection In Background", which is a bit faster, because it doesn't wait to verify the connection. But it still adds some overhead.

 

I have also tried to use notifiers from this example: https://lavag.org/topic/10408-communication-between-projects/ . Opening connection and sending the notifier takes 50 - 100 ms.

 

I guess both the notifier and the shared variables are "slow" because they use the network communication, even if it is the same pc both programs are running on (localhost).

 

Does any of you know of a faster method of communicating between a program that is running continuesly (connection open constantly) and one only exectuted when new data is ready (connection "re"-opened on every instance)?

 

Thanks in advance.

 

Best Regards

Mads

 

 

 

 

 

 

Link to comment

This sounds like a good application for UDP. You won't lose data transferring between two applications on the same machine. I've done exactly this - built a DLL in LabVIEW that acted as a plugin for another application and provided minimal UDP communication, then sent and received data from a separate LabVIEW application. Of course, you can also use UDP directly from C#. Another option might be ActiveX.

Link to comment

Thanks for your inputs. I will give UDP a go. Maybe Active-X is the way to go, i've never used Active-x myself, so that can be plan b.  

 

I don't know how the C# program is made, but i suppose that the C# program maybe can keep the DLL in memory, and the shared variables would remain connected (and saving the reference in a functional global)... 

Link to comment

As far as I know ActiveX should be plan "z". It might cause unexpected problems, just like .net. It's hard to imagine how you can exchange data with compiled code without exact knowledge how it's made. I'm not experienced it this kind of things but it sounds hardly to be done. Shared variables are used to communicate e.g. with PLC systems, so it suggesting this should work way faster than mentioned 50-300ms (for sure more stable).
You can also take a closer look on shared memory. I have seen some LV implementations, not only for RT targets on which it is native LV functionality.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Billy_G
      Hello, I wrote a LabVIEW program to communicate with a hardware sensor using vendor-provided LLB and a DLL files. The program runs fine on my workstation both from LabVIEW IDE and from a compiled executable. The problem starts when I copy the entire executable folder to a target host without a LabVIEW IDE (only with a runtime engine). The application opens with a broken Run arrow and a "missing external function" error message appears for every function call I made to the DLL (see attached).
      I have tested my application on 5 completely different Windows 10 computers managed by different people. On three of them with various versions of LabVIEW IDE my executable opened with a whole Run arrow and no error message. Two other machines previously had no LabVIEW, so I installed a Runtime Engine 2017f2 32-bit with default settings to match the version of my IDE. Both gave an identical error message.
      The DLL is always included in the application build. I have tried placing the DLL in every conceivable location on the target host: in the executable folder, in the /data folder, in the c:\Windows and system32 folders... I even created a full folder tree matching the location of the project on the developer workstation. Same error. When I intentionally hide the DLL, my executable prompts me to point to it upon being opened, and when I do, I get all the same error messages.
      Vendor documentation only asks to put the two files in the same folder. From programmer's manual: " The driver was written in LabWindows/CVI, version 4.0.1 and is contained in a dynamic link library which can be linked with a variety of programming languages." There is no vendor-provided support.
      One way I actually got rid of the error message was by editing every Call Library Function Node in every VI in the LLB to use relative path to DLL together with the Application Directory VI. However, I feel that there has got to be a better way to compile than by editing a vendor-provided library, especially since it works as-is on some computers. Can anyone suggest what it is?
      Thank you for your time!
       

    • By govindsankarmr
      Hi, 
      I am looking for a paid or free course online for LabVIEW instrument control that covers topic like  communication protocols, RS232. GPIB etc. Can anyone suggest a good one. Thank You.
      Govind
    • By torekp
      DLL functions or shared variables?  Or something else?
      I have a Labview 2014-64 executable (or I can build a DLL) that runs one piece of equipment, the X-ray.  The other engineer has a large CVI Labwindows 2015 + MS Visual Studio 2012 (C++) executable that runs everything else.  I want the Labview code to be a slave of the CVI code, accepting commands to turn X-ray On or Off, reporting failures, and the like.  Translating the X-ray code into C++ would be possible in principle, but not fun.
      Shared variables look easy, but I'm kinda scared of them.  I would define all the shared variables in my LV code, since I'm more familiar with LV, then use them in both.  There's a thread in here called "Shared Variable Woes" so maybe I should be scared.  In the alternative, I tried building a proof-of-concept DLL in Labview, and calling its functions in CVI/C++, and it works, but it's kinda clunky.  (I'm attaching it below in case you want to play, or advise.)
      Your advice would be appreciated.
      XrayDLL.zip
    • By Porter
      View File Plasmionique Modbus Master
      This package contains the Plasmionique Modbus Master library for LabVIEW.
      It supports RTU, ASCII and TCP modes with the following function codes:
      0x01 - Read Coils
      0x02 - Read Discrete Inputs
      0x03 - Read Holding Registers
      0x04 - Read Input Registers
      0x05 - Write Single Coil
      0x06 - Write Single Register
      0x07 - Read Exception Status
      0x0F - Write Multiple Coils
      0x10 - Write Multiple Registers
      0x16 - Mask Write Register
      0x17 - Read/Write Multiple Registers
      0x2B/0x0E - Read Device Identification
      Other features include:
      - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout).
      - Sharing a Modbus session across multiple communication loops.
      - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order.
      - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. 
      - Detailed help document available through the "Help->Plasmionique" menu.
      Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\":
      MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf
      Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230
      The most recent version of this library will always be released on LAVA first before going through NI's certification process.
      ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master
      Submitter Porter Submitted 04/01/2016 Category LabVIEW Tools Network Certified LabVIEW Version 2012 License Type BSD (Most common)  
    • By Porter
      This package contains the Plasmionique Modbus Master library for LabVIEW.
      It supports RTU, ASCII and TCP modes with the following function codes:
      0x01 - Read Coils
      0x02 - Read Discrete Inputs
      0x03 - Read Holding Registers
      0x04 - Read Input Registers
      0x05 - Write Single Coil
      0x06 - Write Single Register
      0x07 - Read Exception Status
      0x0F - Write Multiple Coils
      0x10 - Write Multiple Registers
      0x16 - Mask Write Register
      0x17 - Read/Write Multiple Registers
      0x2B/0x0E - Read Device Identification
      Other features include:
      - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout).
      - Sharing a Modbus session across multiple communication loops.
      - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order.
      - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. 
      - Detailed help document available through the "Help->Plasmionique" menu.
      Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\":
      MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf
      Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230
      The most recent version of this library will always be released on LAVA first before going through NI's certification process.
      ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master
×
×
  • Create New...

Important Information

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