Teststand performance when loading code into memory

[mperss]

Hello,

We use TestStand 2014 32-bit in order to develop test sequences that is among other used for production test.

I have created custom step types in order for other testers to easier interface with external hardware. The hardware consists of different modules that are inhouse developed, each module has a certain function and up to 16 can be connected together in one bus. We use a RS485 bus together with FTDI usb adpaters to do the communication from the PC to the test system.

The system is modular and can be connected in various configurations depending on the test requirements for the UUT.

Most of the code that interfaces the inhouse system is built in labview 2014, where I have a .lvlibp (packed library, mainly in order to easily move code between different test computers) which is the library the custom step types calls.

The labview project contains lvoop objects for each "module" in the test system, theese objects are stored as references in teststand (DVR) so that the objects are reused and the runtime information is actually stored in the lvoop object and not in teststand (at least for that object). I have tried various methods to do this, for example to actually store the objects as a objects in teststand, but got problems with performance when reading/writing the object back to teststand after each step executed.

The whole packed library is around 10Mb is size, and contains all of the functionality needed, it takes some time to load into memory first time but then acts ok. My problem is that when loading a large object (when looking

If a use a simple .vi that basically writes data to the virtual com port(i'm using VISA here), and then waits for a response, in a loop and measure the actual time for the message to get onto the bus (with a oscilloscope) i get with some tweaking(no tracing etc) a period time of around 3ms from the recieved message to that the next message is sent. I think this time is quite fast and hard to get any quicker with all the layers involved.

The problem I have is when using my objects to do the same thing the load time is quite a lot worse, around 10-20ms, even tough when using a custom step that is quite low level, that basically does the same thing (with some added functionality, crc checks etc)

Is this what I can expect from such a solution that I have choosen?, is teststand "slow" to load objects into memory, or is it my labview code that is slow to load somehow(size of objects? i dont know).

[GeorgeAF]

Hi mperss,

My name is George and I am an Applications Engineer working for National Instruments in the UK. I’m afraid that your method of running your sequence with the lvoop objects will always take slightly longer to run than the other version that uses functions and steps that TestStand uses by default. However this time increase will differ depending on how much information TestStand has to load each time it runs one of these steps. There shouldn’t be anything wrong with using your packed library but I suggest looking into whether you are loading any unnecessary data when you run these steps as that will waste time. If you have made one object with everything included this will take longer to load than a smaller object that only contains the information you need for a specific step.

Kind regards,

George

[mperss]

Thank you for the reply, I can clarify it a little bit:

I dynamically create objects that interact with the system. The objects themself contains functionality for serial communication, decoding of our protocol, functionality of that specific module etc.The testsystem is modular so it can look different depending on the needs for testing. As the objects are stored as a reference in testand (i.e. only a number) the loading of the particular object i hoped would be fast because they already are in memory. When I do my benchmarking (call time around 3ms) i'm using a small .vi that only does the communication "bare bone", but it loads from the same lvlibp, so i guess that the load time is somewhat proportional to the size of the code being loaded, I was just hoping that the overhead wouldnt be around 5 times larger than when loading the small object.

/Marcus

[GeorgeAF]

Hi Marcus,

It is to be expected that loading a larger object will take a longer time to load and I’m afraid that there is not much you can do about how fast TestStand can load data unless you increase the processing speed of your PC. However you can reduce how much data TestStand needs to load. If you want to decrease the load time the only thing you can do is either permanently load some, if not all, of the code into memory in the initial set up of your sequence so that you do not need to load it temporarily each time or slim down the objects you are loading so they are smaller and more efficient to load.

Kind regards,

George