NI TestStand Idea Exchange

Sometimes in the tests we would like to check are they any common elements for two arrays.

TS2013 have a nice function called Contains() using which devs can easly check if the searched element is in the array or not.

And what about the function which returns an array of common elements of two even more than two arrays?

Instaed of looping one array and issuing Contains() command it would be good to have a kind of logical AND using which we can have a list of common elements?

Would the operator overloading be the right things to do?

Hi,

I propose to that the steps to have new feature called AllowableCallers.

Using this feature developers could restrict the callers (subsequences) from where the particular steps could be called.

Having this feature developers could prevent the mistakes of unintentional step copying during creating new subsequences using the copy-paste method.

The default value for this settings would be AllowAllCallers, but developer would be able to define the condition as they wish (function window f(x))

Hi,

The best would be to draw/paint the feature I'm proposing. However, it would take not so small amount of time, so I decided, regrettably, to write about it.

I wrote the word regrettably because visualised description of the target feature would be very much more attractive than words. Anyway... Back to the point.

The description is as simple as in subject: to allow to change the colour of the background of each step (separately).

Could you imagine how much the readability of the sequence could be improved with this feature? I think that would improve it a lot.

Mainly this feature could be enabled during coding and debugging as during these activities the developers have the problem with readability especially when the sequence is long and the whole project is big and long in time. It could be set to off on when the sequence will be on the shop floor, nevertheless, even in the operator mode this feature could deliver some 'tracing' benefits.

Developers could easily group block of steps and in very natural way - just to color the background of the steps - create a visual 

Reading colors is faster, easier, more intuitive than reading the structures (indent, nested calls). OK it is  - let call it  - one dimensional and it looks flat but it would add another degree of freedom in classifying/grouping the steps improving and speeding up overall readability.

The place (yellow) where this feature (just colour) can be controlled from:

Hi,

It would be good if the documentation tool would have option/report like described below.

After triggering this option user would received the report about every possible flow of the main sequence along with the list of the variables which drive the flow.

Value added by this feature:
1. full view about how many flows the sequence is able to be executed,
2. what variables are involved in the flow of the main sequence,
3. general overview about what and when subsequences and steps are executed,
4. where the flows is splited up and merged back.

This functionality would be great for sanity analysis and overall picture of the possible executions.

Hi,

It would be nice to have another group of the steps.

--send an email,

--send a notification to the syslog server,

--sent a notification to the event log.

It could improve sequence reporting and notifications. The coding these functionalities in the modules no longer wouldn't be needed. 

Hi,

As in the subject.

Now to create a session from the TS two arguments are needed:

--device name (address or alias), and

--session number.

However, comparing to LV, LV needs only one of them, the device name. Why two of them have to be different?

It can happen that session number doesn't exist because the session itself doesn't exist yet. So why this field is made mandatory?

Usually, I put any random number there (0-9) and everything works, but it is not a nice coding style.

I think the Session Number field should be set as not mandatory.

Hi,

I'd like to propose that the FileDiff.exe in the merge mode shall have the possibility of changing the file name labels.

Right now FileDiff.exe tool in merge mode has four fixed file name labels:

1. Base

2. File 1

3. File 2

4. Merged

The names of the labels 1. & 4. are allright. But for someone who uses version controll tool names 2. and 3. could be confusing. I'm not quite sure about the is there one template of  the order in these three-way-diff tools but as I use SVN I'd like to have:

1. Base

2. Mine

3. Theirs

4. Merged

Having this I'd have the same nomenclature which I have in SVN/TortoiseSVN, and it would't create a confusion.

I am trying to edit step variable properties from step to step.

I edit Step.Foo.Bar.Bing.A in the first step.

I click to the next step, it also has Step.Foo.Bar.Bing.A in it, so I edit that value.

I click to the next step, it doesn't have that variable, so I see nothing.

Click to the next step.  @#$%@#$.  Expand Foo.  Expand Bar.  Expand Bing.  Edit variable A

Click to next step.  Still expanded.  Edit variable A

click to next step.  No variable matching that value.

Click to next step.  @#$%@#$%.  Expand Foo.  Expand Bar.  Expand Bing.  Edit variable A

This constant Expand the tree is really annoying.  I'd love to be able to set an attribute of a container to say "always expand this completely whenever It shows up", or a sequence editor wide configuration of "always expand all properties when you browse to them" which would work fine unless you have "show hidden properties" enabled, and then you have the whole Step.TS.* tree visible, so maybe a "expand all custom properties" or "expand all non-hidden properties" or something like that.  Or maybe a way to click on the "+" expanding symbol for that node in the property browser that would completely expand that node