Application instance

An Application Instance refers to a specific running instance of a LabVIEW application or project. Each instance operates independently and can execute its own VIs (Virtual Instruments), dataflows, and user interfaces. When you run a VI in LabVIEW, it executes within an application instance, which is part of the LabVIEW runtime environment.

LabVIEW allows multiple application instances to run simultaneously, each isolated from the others. This capability is useful in situations where you might need to run multiple versions of an application or multiple applications that must not share data directly, ensuring that the execution of one instance does not interfere with another.

Application instances are especially relevant in the context of LabVIEW projects that are deployed as standalone applications. Each deployed application runs in its own application instance, separate from the LabVIEW development environment and any other running applications. This separation is critical for ensuring the reliability and stability of deployed applications, as it prevents conflicts between different running instances of LabVIEW code.

Additionally, LabVIEW’s ability to manage multiple application instances is useful for modular programming, testing, and deployment scenarios, allowing developers to build complex, scalable, and maintainable systems.

Application Instance vs Contexts

The term Application Instance is used in all public documentation, but in the C++ code LabVIEW is written in, those same things are called "contexts". Because R&D folks occasionally post to customers without tech writers reading over our shoulders, we slip up and use the other term. So you should generally regard those terms as interchangeable, but know that "application instance" is preferred for a long list of (very good) reasons.

Isolation of Application Instances

An Application Instance is very nearly an isolated LabVIEW.exe. The VIs in one application instance cannot interact with the VIs in another context unless they do the same things that would be required to talk to a VI that was loaded on a separate machine entirely. So whatever you would do to talk to a network VI is the step you generally have to do to talk to a VI in another application instance.

All LabVIEW files -- VIs, libraries, projects -- load into an application instance. The same file may be loaded into multiple app instances simultaneously. Editing one of the "reflections" (a term that R&D uses which is distinct from "clones" of a VI, which has to do with reentrancy) does not change the other reflections of that file until you synchronize the application instances (either by pressing the green arrow button that appears on the VI next to the Run arrow OR by saving the file).

LabVIEW Classes and LabVIEW Project Libraries can be loaded in multiple instances at the same time but will become uneditable. This will become apparent in Project Explorer due to the class or library becoming locked.

Projects are loaded into an application instance, but they also manage a set of application instances. The "My Computer" instance is the one that the project is loaded into. If you add any targets to a project, (an FPGA target, RT target, etc.), those are other application instances. *All* of the app instances that a project creates, including the "My Computer" instance, are lifetime managed by the project, meaning that when you close the project, you close the application instance, which closes out all the VIs and Libraries loaded into those application instances.

Any application instance may be owned by zero or one projects, but not more.

Application References

Application Refnums are the references to an application instance. Before LabVIEW 8, you would open an application reference to an entire LabVIEW execution system. Now you open an application reference to one application instance within the execution system.

Private Application Instances

LabVIEW has multiple private application instances, including the "NI.LV.Dialog" application instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user application instances, so there is never a chance of one of those VIs cross-linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LabVIEW will create temporary application instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files. Some other known application instance and their purpose include:

• Main Application Instance
• NI.LV.Dialog - instance where VIs from the Tools menu run
• NI.LV.MxLvProvider - instance where VIs in the Project Provider Framework run
• NI.LV.NoVIs
• NI.LV.Editor
• NI.LV.AutoLaunch
• NI.LV.XNode
• NI.LV.XNodeCodeGen
• NI.LV.XCtlMassComp
• NI.LV.XSFPCodeGen
• NI.LV.Express
• NI.LV.Wizard
• NI.LV.Hierarchy
• NI.LV.ClassBrowser
• NI.LV.ExpressVIClone
• NI.LV.PlugIN
• NI.LV.RegenerateChannelInstances
• NI.LV.PopupPlugInEditPanelDiag
• NI.LV.PopupPlugInRunDiag
• NI.LV.IconEditor
• NI.LV.ClipVI
• NI.LV.NewCtl
• NI.LV.CCallVI
• NI.LV.ReadLinkInfo
• NI.LV.Probe
• NI.LV.PrivateUserPriority
• NI.LV.Merge
• NI.LV.MergeVIFromPalette
• NI.LV.OnlyLoadTypedefRefee
• NI.LV.SimDiagScripting
• NI.LV.Palette.LocalHost
• JKI.LV.Extensions.SDP

User Temporary Application Instances

Users can also create temporary application instances. Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well.