NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Preloading Modules very slow when no source for PPL

Hello,

 

I have made a sequence with LabVIEW libraries. I worked with PPL, so I referenced my LV project file, with the VI in the lvlib :

Config LV Step.png

I set the Override Settings to target the right Build Specification :

Override Steeings.png

 

When I was developping, during my tests, I had the Preloading Modules window. I always used the "Always run VIs in PPL" in the LV adapter options. Everything was fine.

Preloading Modules.png

 

Now, I need to go to production mode. So I deleted sources, and keep only PPL (lvlibp), and lvproj of course.

 

It is working at the end, but the "Preloading Modules" window is very very very slow (few minutes).

 

Do you know what's happening ?

 

 

Message 1 of 14
(2,492 Views)

Hi,  Can you please post the files to reproduce this issue?

0 Kudos
Message 2 of 14
(2,437 Views)

How do you manage dependencies in your project? Do you have your driver in labview\instr.lib directory? Are you sure that TS/LV can easily find your driver? I'm guessing that you have a problem with relative paths.

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 3 of 14
(2,417 Views)

Hello,

 

All my drivers are packaged in a lvlib.

I attached a sample sequence with drivers. I also attached CPX400DP drivers if needed (provided by TTi company).

For this example, I timed the launching, from Click on "Execture >> Test UUT (F5)" until the dilogbox requesting UUT Serial number, here are the results :

- Sources directory keeped : 21s

- Sources directory removed : 4mn 40s (This is huge long time !)

 

Sequence is stored in "D:\Sequences\SomeTestSequence.seq" (D mounted via Windows command)

I have the following settings for this test :

LabVIEW Adapter Configuration :

LV Adapter Config - Advanced.PNG LV Adapter Config - General.PNG

 

Search Directories :

Search directories.PNG

 

Thanks for your help.

 

Download All
0 Kudos
Message 4 of 14
(2,408 Views)

Can you try to use lvlibp (packed)?

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 5 of 14
(2,405 Views)

Il used lvlibp, but via the "Always run VI in Packed Project Library" LV adapter option.

The idea is to develop in LV edition mode, for the debug. When I want to push to production the sequence, I check the PPL option and I remove sources.

 

Of course, I can target directly the VI in the lvlibp, but I'm trying to use the PPL LV adapter option (available since TS 2019).

0 Kudos
Message 6 of 14
(2,399 Views)

Does anyone from NI support could answer to this topic please ?

This new TS option about PPL was very promising but is currently not usable because of this problem.

Thanks


@CH_Fra  a écrit :

Il used lvlibp, but via the "Always run VI in Packed Project Library" LV adapter option.

The idea is to develop in LV edition mode, for the debug. When I want to push to production the sequence, I check the PPL option and I remove sources.

 

Of course, I can target directly the VI in the lvlibp, but I'm trying to use the PPL LV adapter option (available since TS 2019).



@CH_Fra  a écrit :

Il used lvlibp, but via the "Always run VI in Packed Project Library" LV adapter option.

The idea is to develop in LV edition mode, for the debug. When I want to push to production the sequence, I check the PPL option and I remove sources.

 

Of course, I can target directly the VI in the lvlibp, but I'm trying to use the PPL LV adapter option (available since TS 2019).


 

0 Kudos
Message 7 of 14
(2,333 Views)

Hi CHI_RR,

 

Thank you for sharing the files, it helped me reproduce the issue.

 

There are a couple of reasons you're seeing the slowdown:

  • Even when the module is overridden and set to run the PPL, we still access the source project and files to populate the PPL path in the step (if it wasn't already), validate the PPL, check if it's stale and needs rebuilding and also to rebuild the PPL if the Automatically Build PPL at start of execution.. option is enabled.
  • A subtle difference in behavior between the LabVIEW development system and the LabVIEW runtime engine. If a LabVIEW project has missing items, like in your use-case after you've deleted the source VIs and libraries etc, LabVIEW Dev will still load the project but the LabVIEW Runtime engine will return an error and fail.

    So when running in LabVIEW Dev, the project(s) loads and is cached in TestStand, so we take the hit of loading each project only once. With LabVIEW RTE, since loading the project fails, the project never gets cached and we take the load time hit every time we try to access the project, for every step.
    This is what causes the slowdown you're seeing when running in the LabVIEW Runtime.

To prevent the slowdown, you can just avoid deleting the LabVIEW source files so the LabVIEW project loads without errors. If you simply don't want the source files around anymore, the step should be updated to directly use the PPL and not point to the source project and VI. This would mean some loss of information, since the step no longer ties the PPL to the source that built it, but you can choose to do that if that's your requirement.

 

Hope this helps you resolve the issue.

 

Thanks,

Tinu

Message 8 of 14
(2,317 Views)

Hi CHI_RR, 

 

As Tinu called out, it is a bug and the issue is being tracked in Bug #1756316. It will be fixed in a future version of TestStand. 

 

Regards, 

Anand Jain

NI

Message 9 of 14
(2,311 Views)

Hi,

 

Thanks for tracking this issue.

For us (CHI-RR and me), deleting the sources files is a normal requirement on production test benches.

Imaging you have 20+ identical benches : it would not make sense to have the source files on each bench.

But it would be usefull for a developper to keep the ability to paste the sources files afterward to make debug or support without changing the .seq

 

Thanks

0 Kudos
Message 10 of 14
(2,280 Views)