NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Sequence Editor Bug - Dynamically Renaming Steps

Solved!
Go to solution

I discovered a pecular issue with the 4.2.1 Sequence Editor display of steps that are to be dynamically named during Run Time. It could be present in other versions but I have no way to check. I have experienced this with Windows XP and with Windows 7.

 

I have attached an example which is very easy to reproduce the issue. It doesn't seem to matter what Step List Configuration you are in.

 

1) Create a new sequence

2) Create a Statement step type

3) Go to the Expressions view in the Step Settings > Property pane

4) In the Pre-Expression, type RunState.Step.Name = Str(Find(RunState.Step.Name,"t"))

* In theory, when you run this step it will rename it to the position where it first finds a "t", 1.

 

5) (While in the Expressions view in the Step Settings > Property pane), copy the step and paste it a few times.

6) TestStand should lock right up for you. If not, paste it a few more times or (quickly) cycle between view two different steps.

 

It is not just limited to Pre-Expression, and it seems to happen less if you are viewing the Step Settings > Expression pane, but it always seems to lock right up. If you are in any other view (that isn't showing the expression) it does not seem to happen

 

I assume what is happening is when TestStand is trying to check the expression for errors is getting caught in an infinite loop if you cycle too quickly. However, I have no idea how to work around this other than slowly switching between steps if I'm viewing their expressions with this recursive naming concept.

 

I would love to know if this has been documented before, if it has been resolved, and if there is a better workaound.

 

Thanks,

Mike Powers

Download All
0 Kudos
Message 1 of 7
(4,768 Views)

Mike,

 

i am sorry, but i cannot reproduce the issue you describe with TS 2014 (32bit) running on Windows 7 64bit.

 

It seems that there is a CAR which was resolved in TS 2012. You can find it in the TS 2012 readme as resolved CAR with ID .

I don't know if this is really the source of the issue, but i would expect 2012 and later not to run into the lock down.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 7
(4,739 Views)

283247: Viewing expression steps with a large number of comma-separated statements can cause TestStand to crash or stop responding.

 

Thanks for the quick reply. Although it is a different observed problem, I would not be surprised if the fix implemented addressed my problem. Unfortunately I need to stick with the version I am using. I have been working with sequences with this type of pre-expression since May with only minor issues, so I think as long as I'm not in the expression view I will not crash TestStand.

 

I'd be curious to know that others with 4.2 and 2010 could reproduce the problem to rule some sort of setup or other software issue on my end.

 

Thanks again,

Mike Powers

 

PS: Love the skit you reference in your signature.

 

 

0 Kudos
Message 3 of 7
(4,730 Views)

I confirmed it in 2010 SP1 (4.5).  I just opened your sequence file and copied the first step really fast.  Only took 3 times hitting Ctl-v.  It does look like a race condition but as was pointed out it is fixed in newer versions.

 

Regards,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 4 of 7
(4,721 Views)
Solution
Accepted by topic author Mike_Powers

Syntax checking of expressions in expression controls is done asynchronously in another thread when the expression control containing that expression is visible (i.e. the expression settings for the pre-expression, in your use case, are active in the step settings pane). You are hitting a deadlock issue that was fixed in TestStand 2012 (issue 287875).

 

You can workaround this issue either by avoiding having the expression control visible while doing paste, or, in the case of your expression at least. You can rewrite it as follows:

 

RunState.Step.Name = Str(Find(NameOf(RunState.Step),"t"))

 

The deadlock is occurring for your particular use case due to the use of API in expressions for an argument to Find(). NameOf() is another way to get the name of an object without using API in expressions.

 

Hope this helps,

-Doug

Message 5 of 7
(4,709 Views)

Wow, that workaround fixed me right up. I actually had a much more complex expression in my real sequence file, but that one change to NameOf() inside of the Find() function resolved my issue.

 

I did not realize that NameOf(RunState.Step) and RunState.Step.Name were not doing the same thing under the hood. I'll keep that in mind in the future if I have similar issues.

 

Is there a good place to look up a full issue list? I'm having trouble finding Issue 287875 in the TestStand 2012 Readme for bug fixes: http://www.ni.com/white-paper/14361/en/

 

Thanks,

Mike Powers

0 Kudos
Message 6 of 7
(4,692 Views)

Not all bugs are listed. I'm not sure why this one isn't. The main issue that was fixed in TestStand 2012 is related to the use of "API in expressions" in various places in an expression leading to the possibility of deadlock (hangs when mutiple threads are doing certain things in parallel). The main issues related to this were:

 

1) Use of API in expressions along with atomic operations such as +=, -=, *=, /=, ++, --, etc.

2) Use of API in expressions inside of certain expression functions: Find(), Replace(), FindAndReplace(), SearchAndReplace(), and Reverse().

 

There are some other much rarer use cases, but these two are the main ones that you are likely to see the issue with.

 

-Doug

0 Kudos
Message 7 of 7
(4,682 Views)