How to Monitor TestStand Execution Context from an External CVI Application?

[Med114]

Hello everyone,

I’m working on a project where I’ve developed a standalone CVI application (a separate EXE) that needs to monitor the current execution status of a TestStand sequence running in the TestStand IDE or another UI application.

My goal is to:

• Receive real-time updates (step name, execution status, context changes) from TestStand,
• Without embedding the TestStand engine in the CVI application,
• And without modifying the TestStand UI.

In LabVIEW, I can run a VI that loops and automatically stays synchronized with TestStand’s context. But in CVI, unless I create and host the engine myself, I can’t seem to track the active execution context — especially if the execution was started from the TestStand IDE.

I’ve explored the COM/ActiveX API and I can create a new engine instance in CVI, but it doesn’t reflect the actual execution running in the IDE. Also, I didn’t find any direct event subscription like OnStepChanged or OnExecutionComplete that works from an external listener.

Questions:

1. Is there a way to monitor or “subscribe” to TestStand execution events (e.g., step changes, status updates) from a separate CVI application, without controlling the execution?
2. Can TestStand broadcast its context or current step info to external listeners (via COM callbacks, sockets, etc.)?
3. Has anyone implemented a reliable communication method between TestStand and a CVI-based external UI for live status updates?

Any guidance, examples, or best practices would be greatly appreciated.

Thanks in advance!

[ebalci]

I think your scenario is best suited to the use case of TestStand callbacks.

You can setup TestStand callbacks so that you are informed (within TestStand) about virtually anything (after/before each step, after failing steps, after run-time errors, etc...)

Since the callbacks are actually TestStand sequences themselves, you can call some CVI code modules (functions exported from a DLL (you may need to create a second project in your workspace to create such a DLL)) and pass the full sequence context or just the data you need to your EXE.

How does that sound? Tell me if you need more details.

(Note: You may also find this especially useful.)

[Med114]

Thanks for sharing your idea.

Right now, I’m updating my UI controls using a classic shared memory mechanism between TestStand and my CVI application.

The official TestStand example (from NI) doesn’t really allow for live UI updates from an external process.

It also doesn’t update native CVI controls properly — especially when the execution context changes or when the UI is separated from TestStand’s execution flow.

[ebalci]

Shared memory mechanism? That sounds like lots of work you do not need.

Callbacks are a built-in mechanism of the TestStand engine.

So your original code remains virtually unchanged.

Yet, of course, your code-your decision 🙂