Shutdown LabVIEW Operator Interface never complete

[J.C._Andersen]

Hi.

I have made my first real custom made operator interface (not based on the NI exampels) in LabVIEW. It runs fine from the LabVIEW IDE but when I build it to a .exe I experience two problems.

The first problem is that from the time I call the "Shutdown" method on the Application Manager i takes about 20 seconds before I receive the "ExitAppication" callback event. When running from the LabVIEW IDE I receive it in less than 1 second. Why is this the case?

The second problem is that once I have received the "ExitAppication" callback event and have done all the cleanup of event registrations etc. I call the "FP.Close" method on my to level VI. Again this works just fine when running from the LabVIEW IDE but when I run the built application the task never finish. The front panel window closes but the application i left hanging in the Windows task bar, and the only way to close it is by using the Windows task manager.

Before any one suggests that I should just use the "Exit LabvIEW" primitive as that last thing in my code, I will jut say up front that I will never consider that to a solution. I know that NI do that a lot in there examples but it does not make it right. I is just a bad quick fix for a problem that needs real solving.

So I hope some one has a real solution to this, thanks.

[AJost]

Hi Jens,

Just from your description it sounds very similar to what the standard TS UIs are doing, so it should be fine.

However, those UIs do not suffer from the problems you are describing, so there must be a subtle difference we are missing.

Also the FP.close method always worked fine for me on both IDE and executable. Exit LabVIEW too ;-).

Would you be able to share some code so we can help debugging? To be honest, at the moment I have no idea where the delay could come from and only careful debugging can tell.

Andreas

[J.C._Andersen]

Hi Andreas.

Sorry for the late reply. The good news is that I have been able to make it work. I made my launcher VI so that it launches the OI VI as fire and forget. I then use a Notifier which is created in the launcher VI and passed as an input to the OI VI. The launcher VI then waits for the notification from the OI VI before it shuts it self down.

This works, and the application closes completely. I my opinion this is much more clean way of doing it, and this is also much like how the splash screen in the Actor Framework examples is implemented.

But I have discovered that If you take the Full-Featured example from NI, open the launcher VI and put a Diagram Disable Structure around the Exit LabVIEW primitive, this example hangs in exactly the same way on shut down as mine. So, I guess the person who made the example code ran in to this problem, and instead of having some one from the R&D look in to it, it just got fixed in this truly gruesome way. This primitive should never be used in any real-world application, and you can look this up in the LabVIEW forums if you need to know the reasons.

The first problem I wrote about is still not solved. That is the approximately 20 seconds delay before I receive the “ExitApplication” callback event after having called the “Shutdown” method on the Application Manager. This is also something you will be able to test using the Full-Featured example and it also just requires that you disable the Exit LabVIEW primitive in the launcher VI. However, it only happens after you run an execution containing LabVIEW steps. I have tried the following scenarios:

1. Execute an empty sequence file using the Test UUT entry point and then close the OI. Result: No shutdown delay.
2. Execute a sequence file containing only non-LabVIEW steps, using the Test UUT entry point and then close the OI. Result: No shutdown delay.
3. Execute a sequence file containing only one step which is an action step calling an empty VI. Result: Shutdown delay.

To me this indicates a problem between TestStand and the LabVIEW runtime engine, which NI needs to address since this leads to a bad user experience.

[RoxtheFox · Accepted solution]

Hi Jens, 

Thank you for bringing the second issue to our attention. I was able to reproduce it, and we already have documented it as a bug on our end. It has also been published in the Known Issues List with Issue ID 632567. 

However, there is a workaround for this issue. In the Adapters.cfg file located in C:\ProgramData\National Instruments\TestStand <version>\Cfg, set the _FlexGAdp_WaitForLVRTECleanupAtShutdown key to False.The delay was significantly reduced after this key was changed. 

Hope this helps! 

[RoxtheFox]

Hi Jens, 

We have also filed a separate bug report to remove the Exit LabVIEW primitive from the full-featured user interface. Thank you for bringing this to our attention. 

Let me know if you're still running into any trouble. 

[J.C._Andersen]

Hi Roxana.

Thank you for looking in to my request. I am happy that you could reproduce the issues on your side, and I will look forward to the next release of TestStand to see if the Exit LabVIEW primitive has been removes from the full-featured user interface.

Have a nice summer 🙂

[KiwiWires]

Hi

I just tried this with LabVIEW / TestStand 2019

Adapters.cfg file located in C:\ProgramData\National Instruments\TestStand <version>\Cfg, set the _FlexGAdp_WaitForLVRTECleanupAtShutdown key to False.

Still takes 18 seconds between end of sequence and TestStand to fire the quit event. 

I see its still listed as an issue in 2019. https://www.ni.com/product-documentation/55166/en/#632567_by_Category

P.S. Mainstream support of LV2015 expired in August 2019... is it time to bump this bug up the priority list?

Regards

Nick

[Rajesh_Nair]

Hello Nick,

Did you get any workaround for this? Thanks!

[NickNZ]

Hi Rajesh

Sorry I can't remember.

[Rajesh_Nair]

Thanks Nick for the reply.

Am facing the same issue. This is critical for me since, my application is a scheduler, it will take request and will execute. So i will opening and closing the teststand interface frequently.

If anybody got  a workaround, please let me know. Thanks!