NI TestStand Idea Exchange

Hi,

As in subject,

It would be good to have the Fail execution option. When the step will fail the execution pointer shal be moved to clean-up part of the sequence (and parent sequences) and the whole execution will be marked as failed

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:

It would be nice to see a Help Button on the .NET Adapter that allows developers to see the help for methods they're choosing similar to the help for the ActiveX Adatper.

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. 

Currently the message popup step is quite primitive.

It would be good to enhance the functionality of this step.

Proposal: pressing the any button definied should be able to trigger the set of TS commands (as in Statement step) definied for any button.

In this case it would be helpful in that way that developers won't be needed to program separate modules to process the flow control flags and user interface popup.

Hello

Execution of a single step is a process executing a lot of steps depending on looping and synchronization. Needing the option to call a PreExecuting and PostExecuting step before taking Looping, PreConditions and Synchronization options in consideration and after all other steps are executed. This is intended to custom step types for use with external customers.

Thanks Vagn

Hello,

For the moment, the precondition builder editor only allow to check steps status or to create custom conditions.

It would be nice to add a way to test the current sequence Status.

To handle this, i create my own custom condition by using the runtime variables Runstate.SequenceFailed and  Runstate.SequenceError.

The problem is that these variables doesn't exist at edit time.

I think that adding this feature to the precondition builder editor could simplify our work.

Thanks.

Manu.

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.

Hello all TestStand users,

How often i had to debug my sequences ... to find out after many minutes that some of my steps are Skipped ! 

It would be nice to highlight the skipped steps by default ... (Without having to customize something in TestStand) 

• By using a stroked font to view the step détail (STEP SKIPPED) 
• By using a red, flashy color (STEP SKIPPED):smileyhappy:
• Or better, both ... (STEP SKIPPED):smileyvery-happy:

Thanks for your help ...

Manu.net

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.

As in subject:

Now if I put the label inside Selrct-Case-End block the sequence won't run:

Sometimes, you have a lot of cases and the labels would be very useful do describe the cases.

I think they shall be excluded from the the rule that "Only Case blocks can be nested in Select blocks".

Using the stock reportgen_xml.seq file, the text value of the XML node shouldn't contain the characters < or >:

http://www.w3.org/TR/xml/#syntax

When using LabVIEW VI's to parse this, you (rightly) get errors, so it's incredibly difficult to just search and replace the offending characters with their XML escapes. 

Example node contents from the XML report:

<Prop Name='ReportText' Type='String' Flags='0x400000'>
                            <Value><![CDATA[{0} Locals.i = 0; Locals.i < 2; Locals.i += 1]]></Value>
                        </Prop>