06-02-2024 09:50 PM
The function I want to achieve: a window is always displayed during the program running, and the data in this window will be refreshed in real time during the running process.
The method I thought of: insert a vi in a certain step in teststand, call vi when running here, keep vi running in the background, and teststand continues to execute the subsequent steps.
My question: 1. Can teststand realize that vi and teststand program of a certain step can be run at the same time, instead of having to finish vi in this step before continuing to execute the subsequent steps
2. What kind of program structure is needed to achieve this function
06-03-2024 02:30 AM
There are several ways to achieve something like this.
Is "the VI" to be used as an Operator Interface?
Starting a VI to be run in the background is one thing, how do you plan to stop it?
I'd like to understand your UseCase a bit better, before throwing options at you 😉
06-03-2024 02:45 AM
Hello Oli Wachno,
Thanks for your reply. Regarding your questions:
06-03-2024 03:30 AM
I'd suggest to set up the VI as an DQMH module.
It enables you to start and stop the module with a simple VI call (Action Step) from anywhere within the sequence. And you can create a nice API to enable easy communication between TestStand and the module.
Also check out Cyrils Video
https://youtu.be/gSErNHAn_HY?feature=shared
06-03-2024 07:03 AM
As Oli mentioned, there are several ways to achieve this. I suggest two native methods for TestStand: the "Run VI Asynchronously" step and the "Sequence Call" step with the Execution Option "Use New Thread". Additionally, custom solutions can be considered, such as using synchronization mechanisms native to LabVIEW (e.g., as recommended by Oli) or those native to TestStand. There is a ready-made wrapper for SyncManager available here.
Run VI Asynchronously Step: This method seems best suited for your case. It will launch a VI asynchronously (creating a new subsequence call under the hood and running it in a new thread) and, depending on the configuration, can use the caller context or create a new one. See more details here. When using the caller context, you can share variables between threads. However, this approach requires additional synchronization mechanisms (under the hood), which might impact performance. It is recommended to use a new context and store a reference to the new thread in a variable. This way, you can control the new thread using the API (e.g., you can terminate it if needed). See examples here and here.
Sequence Call Step (Use New Thread): This method is similar to the previous one but involves calling a subsequence in a new thread instead of a VI (although in the previous method, this also happens under the hood). In this method, it is best to store a reference to the new thread in a variable, allowing you to control it using the API. More details can be found here and here.
06-03-2024 07:04 AM
Try: