First usage of the TS API tales up to 30 sec.

[Marcos_V._Bischoff]

Hi there,

at themoment I'm implementing a small executable, which should execute a TS sequence. It works (almost) fine, but i encountered a irregulrly behaviour, which left me with  a question mark. The first call to any method of the TS API takes up to 30 seconds on my devolpment pc and on the deployment pxi sys. only secs. After the first call the following method calls work faster. The actual test take about 1 to 3 secs and as we want to execute the tests sets "over night" execution of a sum of tests multiplies these 30 secs.

The differences between the HW configuration of the two sys. isn't that much as it would explain the gap.

Is there some way to maybe configure the TS engine?

Or has anyone experienced similar behaviour?

[dug9000]

This is not expected. Have you tried to narrowing down where the 30 seconds is being spent? What particular API are you calling where you think the time delay is occurring? Try removing (or commenting out) any customizations or UI modifications and see if that effects things. Have you tried one of the default UIs to see if you are seeing the same problem? Are you using the TestStand Application Manager UI control or are you using the lower-level engine API?

This is not an expected behavior, so more details about what exactly you are doing or instructions for reproducing this in a simple case would be helpful.

-Doug


Message Edited by dug9000 on 05-27-2008 11:11 AM

[Marcos_V._Bischoff]

Hi Doug,

well we are using a C# console executable to adress the TS API and the delay ocurres at the moment when I call

myEngine = new Engine();

or in a sperate (not usable) user-interface

axApplicationMgr.Start()

. We have investigated with the given user - interfaces and encountered a similar delay. Depending on which programming language is used between 20 and 30 sec. But these aren't fix number the delay is variable, however it is about 20 sec. I even implemented small executables in C#, VB.NET and LabVIEW, which only instanciate the TS Engine and mesured the tick around it. All with the same delay. I think, that the TS engine ist setup, but I thought that the TS engine were something static and eith the above expression I only get a reference on it. Am I wrong with that?

[dug9000]

There are many factors in startup time. The first time you create the engine there should be a short delay as lots of things are going on, dlls are loaded, global variables and configuration files are loaded and internal data structures are created. When Start() is called, additionally the loginlogout callback might be launched. 20-30 seconds does seem a bit long though for any modern machine (I'd expect more on the order of 2-5 seconds on a reasonably fast computer for creating the engine) so something else might be going on in your system. Do you perhaps have a lot of global variables, are a lot of VIs being loaded by the loginlogout callback perhaps and perhaps being mass compiled by labview? Is your login callback perhaps hanging on an instrument driver call until a timeout occurs? There are many many possibilities. Have you tried launching a UI or seqedit.exe on a clean install of teststand on that machine? If so how long does that take? If it's much faster than 20 - 30s, then the extra time must be due to customizations you have made. If so, try systematically removing or commenting out customizations to narrow down where the problem is. If on a clean install of teststand it still always takes 20-30seconds to create the engine, then there might be something unusual about your machine that will need to be narrowed down (assuming it isn't just an usually old or slow computer). Have you seen this significant a slowdown on all of your machines or only on certain ones?

Also keep in mind that the OS does lots of caching of things, so the first time dlls are loaded is often much slower that subsequent times.

Also keep in mind that .NET applications startup slower than non-.NET application (especially the first time one is launched after rebooting) as there is a significant amount of overhead involved. This is something Microsoft has been working on improving for future versions of the .NET framework.

Hope this helps,
-Doug

[dug9000]

Another possibility I just thought of is type palette files. These are loaded when Start() is called too. Do you perhaps have a lot of custom types or type palette files? Are they out of date with the current version of teststand (do they need to be resaved, do they have a modified indicator when they are first loaded)?

Also, many of the files in the engine's cfg directory are loaded when the engine is created so maybe you've ended up with a lot stored in one of those files (this includes globals).

Really there are many possibilities. I'd compare the times you are seeing with a clean install of teststand on a similar machine and if you see a huge difference in speed then I'd start looking at what's different on the machines to find out what the cause of the slowdown is.

Also you might consider a different architecture for your system that doesn't involve recreating the engine each time and instead reuses the same engine for each run.

-Doug


Message Edited by dug9000 on 05-28-2008 01:16 PM

[Joe_H]

We have a lot of trouble with this also. We were told NI application engineers that it was normal. However I can tell you that it varies from PC to PC and that if you set the modules (esp for LabVIEW) to run in the run time environment instead of the developement environment then everything runs much faster. Also keep an eye on how you load dlls.

[j_dodek]

Hi Joe,

I have made the same experience!

Thank you for the LabView hint.

Juergen

[Marcos_V._Bischoff]

Hi Doug,

thanks for the detailed reply. Well we have a quite new Teaststnd installation, as we bought it 2 months ago and we are not using custom types ore steps. I also narrowed down that we ain't use unspecified search directories. And the execution time does variate a lot from pc to pc. As the execution on a NI PXI system is quite fast I think that your right with the assumption, that the hardware devices or drivers could be involved. I'll check this on two identical test hosts we have. But I doubt that the soltuion is taht simple 😉
You mentioned something, that I found quite interessting.

dug9000 wrote:

...
Also you might consider a different architecture for your system that doesn't involve recreating the engine each time and instead reuses the same engine for each run.
...

Message Edited by dug9000 on 05-28-2008 01:16 PM

How could I do that? We want to use TS as a test executer on a single hardware device, wich we develop and want to test the HW device as well as the SW components. As a test specifier we use a web client, which basically start the TS engine either remote or local over a browser script. But it shall be executed on the PXI rack. Therefor it is logical to leave the TS engine in a "endurance run". But how can we keep a statical instance of the engine, when we need to run an exe for every test we want to carry out?

[Joe_H]

If I understand you correctly you have your system set up to run like this: insert the board and run the executable. Then the EXE closes and you insert another board and run the EXE again. Is this correct? if it is then this is the wrong way to set up your test station.

You should have your station set up like this: Start your EXE, Your EXE upon startup should open TS and start the engine and load the correct sequence file. Then you load the board and hit the run button. it should then test the boards and then stop and then go back to a state and wait for another board to be placed for testing. this is how it should be set up that way the 20-30 sec startup hit only affects you once and then it will not be that big of a deal.

You should also time the startup of the sequence editor. you will find that it takes the same amount of time to start the editor as it does to start your application. There is nothing that you can really do about it. 

just my 2 cents 

[dug9000]

Marcos,

I'm not exactly sure what you are doing, are you saying that your only way to interact with TestStand is by running an .exe because you are using a web client script? If so you might consider using a stub exe program that really just interacts with an already running version of TestStand. There are many ways you could do the interprocess communication between the stub .exe and an already running teststand program. You could even use the existing UIs or sequence editor that comes with TestStand along with the /useexisting commandline parameter. Both the example UIs and the sequence editor supporting opening and running sequences using commandline parameters and the /useexsiting commandline parameter just forwards the commands to an already running version of the UI or sequence editor if one exists. You'd probably have to have some other way of knowing when the execution completes though. There are many ways you could do that as well, such as polling for something that the execution does when it completes (perhaps creating a file, or some other form of interprocess communication). You could have a stub program that runs a UI with /usexisting and then waits for something that indicates when the execution completes. This is just off the top of my head though, there might be a better way.

-Doug