Communicate between different LabVIEW executables

[A.FromTheHays]

Hello all,

I would like to program a set of labview executables.

1 executable will be the main interface.

The other executable will be a driver for a sensor which we want to use.

In order for this to work, I would like for the executables to communicate with each other.

It is possible that we will need a configuration where we will connect more then 1 sensor to the interface.

My preference would be to use the same set of commands for this sensor.

I can the call a second instance of the same sensor driver executable.

The structure of this software would be like the structure shown in the diagram below:

I have tried to do this using "shared variables". This works incredibly for 1 sensor.

As far as my knowledge about shared variables stretches, it is quite hard to use the same set of commands for 2 different drivers.

It is not possible for shared variables to have something alike an address to make a distinction between one driver or the other.

I would like to ask this forum for your opinion on methods to program this.

This method does not specifically have to be based on shared variables, I am open to all advise.

I am using LabVIEW 2019.

Thanks in advance!

[ZYOng]

Try Asynchronous Message Communication (AMC) Library (NI Asynchronous Message Communication (AMC) Library Toolkit for LabVIEW) ?

[UnholyPenguin · Accepted solution]

The AMC (Asynchronous Message Communication) Library is a strong option, particularly given its ability to handle asynchronous, modular communication between different parts of a LabVIEW application, including separate executables. However, whether it's the "best" option depends on several factors specific to your project, such as complexity, real-time requirements, and ease of implementation. Here's how AMC compares to other methods:

AMC vs. Network Streams:

• AMC:

  • Pros:
    • Handles asynchronous communication effectively.
    • Simplifies the process of sending and receiving messages between executables.
    • Scalable for managing multiple sensor instances.
  • Cons:
    • Might be overkill if your communication needs are relatively simple.
    • Requires setting up and managing AMC contexts and channels.

• Network Streams:

  • Pros:
    • Provides reliable, lossless communication with built-in buffering.
    • Ideal for high-throughput, real-time data transfer.
    • Direct and straightforward for one-to-one communication channels.
  • Cons:
    • Typically used for continuous data streams rather than command-based messaging.
    • Each stream is unidirectional, so bidirectional communication requires two streams.

AMC vs. TCP/IP:

• AMC:

  • Pros:
    • Higher-level abstraction than raw TCP/IP, making it easier to use in LabVIEW.
    • Automatically handles message passing, reducing the complexity of protocol implementation.
  • Cons:
    • Slightly more overhead than direct TCP/IP communication.

• TCP/IP:

  • Pros:
    • Very flexible and widely supported.
    • You have complete control over the communication protocol.
    • Suitable for both command-based and streaming data.
  • Cons:
    • Requires more effort to implement and manage.
    • Handling multiple connections (e.g., multiple sensors) adds complexity.

AMC vs. Shared Variables:

• AMC:

  • Pros:
    • Better suited for complex, modular systems where each executable or VI needs to operate independently.
    • Avoids some of the scalability issues of shared variables when dealing with multiple instances.
  • Cons:
    • More setup required compared to shared variables.

• Shared Variables:

  • Pros:
    • Simple to implement for basic communication needs.
    • Integrated into LabVIEW's development environment, making them easy to use for straightforward tasks.
  • Cons:
    • Can become unwieldy or difficult to manage in more complex systems, especially with multiple instances of similar executables.

Best Option Determination:

• AMC is likely the best option if:

  • You need to manage multiple instances of the same executable, each potentially handling different sensors.
  • You require asynchronous, non-blocking communication.
  • Your application involves modular components that need to communicate without direct dependencies on each other.

• Network Streams might be better if your primary need is continuous data streaming rather than discrete command-based communication.

• TCP/IP could be optimal if you need maximum flexibility and are comfortable implementing and managing a more complex communication protocol.

• Shared Variables might still be a viable option if you decide to simplify your system or if you're handling just one or two sensor instances where the complexity of AMC or TCP/IP isn't justified.

Conclusion:

AMC is one of the best options available for your described scenario, especially considering the need for modularity, scalability, and handling multiple sensor instances with the same command set. However, it's important to weigh its benefits against the specific needs of your project to determine if it's the most appropriate choice. If the complexity AMC introduces is justified by your application's needs, then it stands out as a strong, scalable solution.

[A.FromTheHays]

Thank you for this informative answer!

I will review the options you presented to find a suitable solution for our use case.