TS UI Doesn't Respond when Loading VI Call using Project Path

[EricEvola]

Using the shipping example for a TestStand User Interface with Native controls, I'm calling my own .seq file. The seq only has one vi. Everything works well when I specify the VI Path in TestStand directly. However, if I specify the VI location using a Project Path (lvproj), the UI will never load the vi and goes unresponsive. Why might this be? Here's a screenshot showing the issue.

[MarinaBen]

Hello,

What version of TestStand are you currently using? Does this happen with all LabVIEW VIs or just this one?

[pulidotech]

Can you also check if it works with other shipping TestStand UI's?

I just tried running that UI code with one of my sequences that has a project and I am seeing similar behavior.  However, I have never had an issue with the regular simple UI:

National Instruments\TestStand 2017 (64-bit)\UserInterfaces\Simple\LabVIEW\Source Code

[WireWeaver]

I try to encourage pretty much everyone who uses TestStand and LabVIEW together to read this page:

http://www.ni.com/product-documentation/14335/en/

Changing the project path (in addition to a few other things) will change what application instance the VI runs in. It's hard to say for sure if that's what is causing your problem, but it's a good place to start.

-Trent

[Norbert_B]

It seems to be a dead lock on the UI thread. Loading LV code is executed in the UI thread, execution of code segments like most property nodes or DLL calls configured for UI Thread (thread safe) as well. That means that if your UI executes something in parallel while the project is being loaded, a dead lock could be a potential result (even though it should be unlikely).

Is that behavior always occurring?

If not: What are parameters it depends on (e.g. loading immediatly vs. waiting a couple of seconds for the UI to settle)?

[EricEvola]

Thank you for the thoughts and suggestions!

• It only occurs with the shipping example "User Interface with Native Controls". Other TestStand UIs appear to work fine.
• It's very easy to reproduce - just create a sequence with a LV VI that's stored inside a project and referenced via the project path. Call that sequence from that particular TS shipping example UI and you'll be forced to quit LabVIEW completely.
• So far, it happens every time and is independent of timing as far as I can tell.
• LV 2019, TS 2019
• Appears to be independent of LV Adapter setting (Dev vs. Run-Time)
• Context: This is mainly a curiosity for me although I'd like to pin it down since it could indicate something to avoid doing in the future.

[RoxtheFox · Accepted solution]

Hey Eric,

This is a known issue with TestStand. See http://www.ni.com/product-documentation/55168/en/#665065_by_Date. The workaround is to use the built exe rather than launching from the LabVIEW dev environment. 

Thanks!

Roxy

[EricEvola]

Nice call. Thanks for the info.

[Anand_Jain]

Hi, 

As a workaround, you can change the execution system of the following VIs  to "Standard" to avoid the hang -

1. TestExec.llb\Process User Menus.vi

2. <vi.lib>\addons\TestStand\_TSUISupport.llb\TestStand - Execute Menu Command.vi

Note: <vi.lib>\addons\TestStand\_TSUISupport.llb  will be replaced when you switch to a different versions of TestStand. So you will have to make your fix again if you switch TestStand versions. 

Regards

Anand Jain

National Instruments