Leaderboard

There is and it is called Interapplication Communication. Which one to use depends on the platform and your familiarity with a specific method. - File IO (multiplatform, trivial to setup, difficult to manage as you have to deal with concurrency of two applications trying to access the same file) - DDE (Windows only, ultra ancient and much older than legacy, don't ever use it if you can help it) - Shared memory (super high throughput, complicated to use, pretty different APIs and methods on each platform) - (D)COM (Windows only, complicated to use from anything else than C(++). - Pipes (Standard method on Unix, LabVIEW supports it on Unix platforms only, Windows has pipes too but it is a fairly obscure and seldom used feature) - TCP/IP (multiplatform, native support in LabVIEW, almost as high throughput as Shared Memory when both sides are on the same machine since the network socket uses internally shared memory to transfer the data between the two endpoints, can also work over the network where client and server are on different machines) - If both sides are LabVIEW based, you can also use the VI Server interface. That goes over TCP/IP too under the hood, but gives you a fairly easy method to directly access VIs in the other process. The TCP/IP method is by far the standard method nowadays. It is ubiquitous on pretty much every platform, from the tiny embedded controller up to super duper ultra high performance computers. It has a few minor challenges such as proper network setup, the very distinctive server/client model and if you do not want to have to configure the client and server in some ways for their IP address and port number, you need additional complicated services that let you discover the according resources on the network. Most of them do however cause more trouble than they solve, so for your home grown kitchen sink automation, the easiest is to simply leave these things configurable in an ini file or something.

@The Q started such a thing on the LabVIEW Wiki: https://labviewwiki.org/wiki/Text-Based_terminology

Hi! I found this discussion while doing research on test automation framework. There is an open source project for test automation that I also found while researching called OpenTAP. It is an open-source test sequencer that is well document and has a pretty decent community. Its extendable and has a .NET core. There is another one called OpenHTF that was created by some Google engineers that is a Python test framework, but it has limited documentation. I don't know if this helps because I have limited software and testing knowledge, but this is what I've found.

Reentrant: Roughly also "Reentrant", although... LabVIEW VIs are non-reentrant by default, C/C++ functions are reentrant by default. Unlike LabVIEW, there is no setting to force C/C++ functions to become non-reentrant -- you simply code them in a way that makes them reentrant. In LabVIEW, non-reentrant VIs are impossible to run multiple instances simultaneously. In C/C++, non-reentrant functions are unsafe to run multiple instances simultaneously (it's possible; you'll just break things). Single element queue: Depends on how you use it. I often use it as a nicer form of Data Value Reference (see below). Data value reference: "Pointer" (as per the Wiki) or "Reference" Functional global: Doesn't really exist in textual languages. They were invented to fill the role of Global Variables, back in LabVIEW 2 when Global Variables didn't exist. However, an Action Engine (see https://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801) roughly maps to a "Singleton". Sounds good to me. However, note that a LabVIEW "variable" is quite different from a textual "variable". A textual variable is more like a LabVIEW wire.