Calling Asynchronous VI in Teststand not working with lvlibp & LVRTE

[Nerdy Camelopard]

Hi there, I am using Teststand 2020 together with LV 2020 SP1 since a while. My framework contains a HAL with several modules that I use with lvlibp (override module settings) and RTE for production. This works pretty well and we are happy with it so far.

For one of our sequences we need to make asynchronous VI Calls now.

There is an NI Code example and knowledge article about asynchronous calls in general:
https://forums.ni.com/t5/Example-Code/Run-a-LabVIEW-VI-Asynchronously-from-TestStand/ta-p/3834066
and
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000g0sqSAA&l=de-DE

Both solutions explained work perfectly with the LabVIEW Development Environment. When switching to packed libs and RTE on our production Teststations, it won't work anymore. Also if I try to force using lvlibp and rte in Teststand on my development machine it will always open the LV Development and not use RTE.

Did anyone use asynchronous vi calls in Teststand and had the same issues with lvlibp and the RTE?

[ak_nz]

I've had examples working fine in TS 2019 and LV 2020. All LabVIEW dependencies are packed libraries built in the dev environment, then loaded in TS using the adaptor configured as RTE.

Have you tried a very simple example eg. a simple VI that runs till panel closed?

[Nerdy Camelopard]

Hi ak_nz and thanks for our reply. Yes, I used the really simple example of the ni forums article, added it to a lvproj and packed it to a lvlibp. The behaviour remains exactly the same when I call it via the project and the override settings (adaptor configured as RTE).

Interesting behaviour: If i call the vi from the lvlibp directly, it works as expected (-> Called via RTE).

I added the example...one sequence working, the other not...

Example.zip

[Cloedu72]

TestStand and LVLIP are always a bit special. I found out that all visible controls on the called VI from LVLIBP must be in public scope.
Did you compile the code as debug? If so, this rule partially applies to subVI's as well.
Sometimes it is "Disabled structures" with broken code that cause problems.

=> See my checklist:

https://forums.ni.com/t5/DQMH-Consortium-Toolkits/my-DQMH-PPL-and-VILIB-PPL-best-practices/td-p/4155993

Claude

[ak_nz]

20 hours ago, Nerdy Camelopard said:

Hi ak_nz and thanks for our reply. Yes, I used the really simple example of the ni forums article, added it to a lvproj and packed it to a lvlibp. The behaviour remains exactly the same when I call it via the project and the override settings (adaptor configured as RTE).

Interesting behaviour: If i call the vi from the lvlibp directly, it works as expected (-> Called via RTE).

I added the example...one sequence working, the other not...

Example.zip 70.44 kB · 0 downloads

I should have clarified my workflow better. The PPL files, once built in the LabVIEW Dev environment, are then copied into a reference location that the specific TestStand project can access (this is normally within the root folder of the sequences or a sub-folder eg. "Components"). The Async steps are then configured to call the VI in the PPL directly. So component building (eg. PPLs but also other types like .NET assemblies) is independent and decoupled from the TestStand environment.

That works fine for the projects I have done.

[Nerdy Camelopard]

@Cloedu72Thanks for the advice! Everything is in Public scope, debugging is disabled and there is no broken code since I have the same issue with the simple NI code that is quite minimalistic. I also followed the checklist. Thanks for the link though, this one is really helpful.

@ak_nzThanks for clarification. This way it works perfectly and this is also my workaround for now.

Using async calls with "override module" seems not possible. I will report to NI and keep you updated...