06-25-2015 02:53 AM - edited 06-25-2015 02:56 AM
I've recently finished developing the first iteration of a "Utility" library that allows LabVIEW projects to easily interact with a microcontroller-based application that our company has developed. I'm currently trying to create TestStand sequences that will perform tests of the microcontroller-based application via the Utility API. Specifically, I use the LabVIEW adapter to add calls to VIs included in a packed library version of this Utility library.
My problem is that TestStand's performance degrades to the point of being unusable for even the simplest sequences that rely on this library. Below is an example of a very simple sequence for instructing the microcontroller to turn on a relay, checking that it's turned on and then switching it off again. It took 5 minutes just to take a screenshot of the sequence because of the time it took for TestStand to load the sequence.
It seems that TestStand is running slowly because of the calls being made to the Utility library. This library consists of around 800 VIs, which is larger than other projects we've developed but not what I'd expect to be unreasonably large.
This library was developed in LabVIEW 2014 SP1 (32-bit). I'm creating and running these sequences using TestStand 2014 - Sequence Editor (32-bit). The computer I'm running this on has an i7 processor and 8 GB of RAM and does not generally experience performance problems. I have tested using the Utility library directly within a LabVIEW environment and do not notice any performance problems other than the fact that the development environment becomes slightly laggy when including a packed version of the Utility library in a new project.
I have read through Best Practices for Improving NI TestStand System Performance and taken the following steps:
This is my first TestStand project and I'm wondering if there's anything I could do to improve TestStand's performance to a manageable level.
07-06-2015 04:06 AM
Hi,
Sometimes loading of VIs takes time.But once loaded it should have run fast.
Few things which you can check :
1) Is the step configured to load/unload after each step execution?
Click on the step --> (step settings) --> properties --> Run Options ensure that "pre load when execution begins" and "Unload when sequence file is unloaded" option is selected.
There are other options which will make VIs to load/unload for each step and thus reducing speed.
2) Why dont you directly call the vi inside the library ( project selection is an option - try avoiding it).
Hope this helps.
Ravi
07-07-2015 08:37 AM
@SunRS wrote:
Hi,
Sometimes loading of VIs takes time.But once loaded it should have run fast.
Few things which you can check :
1) Is the step configured to load/unload after each step execution?
Click on the step --> (step settings) --> properties --> Run Options ensure that "pre load when execution begins" and "Unload when sequence file is unloaded" option is selected.
There are other options which will make VIs to load/unload for each step and thus reducing speed.
2) Why dont you directly call the vi inside the library ( project selection is an option - try avoiding it).
Hope this helps.
Ravi
Hello Ravi,
A while ago I tried changing the sequence files to pre-load modules when opened and this seemed to help. Since then I've only tried loading the sequence files rather than modifying them so I can't say how painful it will be to make modifications later on.
Unloading modules only when the sequence file is closed - which you mention - is a good idea to improve performance as well but anyone using this approach should bear in mind that this can cause unintended behaviour in their tests - often you'd want a "clean slate" for each sequence execution and therefore choosing to unload modules after each execution should still give you decent performance while also ensuring your tests behave appropriately.
I also put all the LabVIEW libraries my test sequences depend on under a single directory and include the path to that directory as the first search directory under TestStand options.