Setting the Preferred Execution System of LabVIEW VIs to Prevent Deadlock
- Updated2025-07-23
- 1 minute(s) read
When a VI calls methods of the TestStand API, you must correctly set the Preferred Execution System on the Execution page of the VI Properties dialog box for the VIs.
When you call synchronous methods that do not return until the LabVIEW server executes a VI on behalf of TestStand, the VI that calls these methods and the VI that TestStand attempts to run using the LabVIEW VI Server cannot run in the same LabVIEW execution system. When the VIs attempt to run in the same execution system, the execution of the synchronous TestStand method consumes the execution system in which the VI needs to run, causing deadlock. Since most TestStand API methods are synchronous, you should consider this when calling any TestStand API method from a LabVIEW user interface.
Because LabVIEW handles ActiveX communication through the user interface execution system, you cannot set either of the VIs in this scenario to run in the user interface execution system. For example, you can have a LabVIEW code module that calls the Engine.NewExecution method followed by the Execution.WaitForEndEx method and a new execution that calls LabVIEW code modules. Deadlock can occur when either VI in this scenario uses same as caller or user interface as the preferred execution system.
To avoid deadlock, use the Execution page of the VI Properties dialog box to select a different preferred execution system, such as other 1 or other 2, for each VI.