testexec.ini access denied...

[NutaqTestDept]

Hi Doug, 

Currently, I don't get any other runtime errors... Everything seems stable except for this random testexec.ini writing issue. 

Yesturday, I realized that the application crash was caused by the error pop-up itself. If I click "OK" without trying to navigate in the teststand GUI (by clicking on the GUI while the popup is opened), it doesn't crash and the test continues. (well, will have to confirm when it will occur again).

I attached the error pop-up. However, as previously mentioned, my config directory is correctly set in the Stations Options. 

Thank you,

C.

[dug9000]

It's possible this is a similar issue to the one worked around previous. Perhaps the workaround is not sufficient. If you can come up with a simple case to reproduce the problem, that would be ideal. Perhaps see what the sequence is doing when this error occurs and try to do that in a tight loop in multiple threads. Please let us know if you discover how to reproduce the problem.

Thanks,

-Doug

[NutaqTestDept]

Hi all,

I have not been able to investigate the issue in deep yet, but I wanted to let you know that we reproduced the issue with the TestExec.exe (MFC) provided with the Teststand suite. 

From a quick test I did this morning, it seems the issue could be related to the Teststand runtime engine as I was not able to reproduced the failure using the teststand sequence editor. However, the test condition were not the same (i.e. not the same sequence) so I can't confirm anything.

I'm looking to perform more test about this issue in the upcoming days, so I will let you know about my progress. 

Thank you

c.

[NutaqTestDept]

Hi all,

I tested a new implementation and the problem still occur... 

This time, I implemented a launcher sequence to call the test sequence instead of pressing multiple time the button "Test UUTs" (which I think is a more common usage of teststand) ... Basically, this sequence has a while loop with a sequence call (in mode "New execution") and a pop-up to control the loop to call a new execution again. Therefore, I pressed the "Test UUTs" button once, and when I wanted to start testing a new UUT, I press OK on the pop-up..

The test has been performed with the TestStand Runtime Engine 2013, and again, randomly (after many runs), by the end of one of the running execution (started by the launcher sequence), the "TestExec.ini Access Denied" pop-up appeared.

Why does teststand update the config file by the end of each execution? Is there a way to prevent this update? Also, when is it performed duing the teststand post-uut operation (in the sequential process model) ? 

Any new ideas to help resolving this issue?

Thank you

p.s. please also read my previous post...

C.

[dug9000]

Are you calling any APIs in your sequence or process model or process model plugin modifications which modify any station options? When station options are modified then testexec.ini is modified. You should not be getting any access denied errors though. That is not supposed to happen. Can you reproduce this problem in a simple case that you can attach to this forum?

Thanks for any help reproducing this issue.

-Doug

[NutaqTestDept]

Hi Doug, 

The only station options, I think, I modifies using the API are the settings for the TimeLimit in Normal execution (When executing). I'm using the API to enable/disable the timelimit option in normal execution as a Watch dog for steps calling external code module as Batch files, DLL calls, VI for equipments, etc. However, as the access denied issue occurs only when the sequence is terminating, I don't think modifying this option is the root cause. 

I just realized that I also modify the option Parameters.ModelPlugin.Base.NewThread in the sequence callback ModelPluginOptions.  I'm not sure why I'm doing this call, but I think it's because I modify the report path during the execution and it was inspired from this post http://forums.ni.com/t5/NI-TestStand/TestStand-2012-Report-File-Location-variable/m-p/2154774#M38669.

Do you think the issue could be related to this option change or to the report path modification?

Thank you

C.

[dug9000]

I don't think setting Parameters.ModelPlugin.Base.NewThread writes anything to testexec.ini. Changing the TimeLimit station option definitely does write to the file though, so that could be the cause. Though really it should already be synchronized as long as you aren't running multiple copies of teststand (multiple processes, not executions) at the same time. Are you perhaps running multiple copies of TestStand which are doing this at the same time?

-Doug

[NutaqTestDept]

Hi Doug, 

I do not run multiple copies of teststand. Only one operator interface is used to launch and control the three parallel executions. 

Any other ideas since the last time we talked? On my side, I'm not sure what I could do to help pin pointing my issue...  

Thank you very much Doug, 

C.

[dug9000]

To help us narrow down the cause:

1) Can you try doing the timelimit setting in a tight loop in multiple executions on your machine and see if you can reproduce the error readily? Don't forget to disable result collection on the sequence to avoid running out of memory.

2) Can you try skipping your steps that do the timelimit setting and see if the problem goes away?

3) What OS are you on?

To workaround the problem:

1) You can set Engine.PersistConfigFile to false to avoid the error, however changes will not be saved to testexec.ini until you set this back to true. So you need to find a good reliable place to set it back to true in your code once your executions are done and you want to save testexec.ini changes again.

-Doug