NI TestStand Idea Exchange

Post an idea

Every so often it turns into a mess of trying to do math in TestStand. Or manage arrays (finally got some of that cleared up in TS2012).

LabVIEW "solved" some of that by implementing formula nodes, which are kinda just like the expressions we currently have in TestStand. Then they realized that formula nodes didn't have all the functionality that users needed, and why not just expand to a "industry standard" and implement MathScript. Why can't TestStand do the same? Build the MathScript engine into the TestStand distribution, and allow us to write expressions (or at lest a 'mscript statement step') in mscript format. This would help remove pressure from adding more functionalty to the TestStand API (since a lot of it would already be built into mathscript language).

I could imagine writing a statement like Locals.MyArray = Mscript.ones(15)

When setting arrays, even multi-dimensional arrays, it is possible to initialize them in single assignment expression. For example, "Locals.Array = {1, 2, 3}" will re-define Locals.Array as a 1D array with elements "1", "2", and "3". This is essentially the same as C-style initialization syntax, which also supports structs.

It would be helpful if containers could be assigned in a similar manner. For example, the illustrated container:

could be assigned completely using "Locals.Container = {True, 1, "foo"}".

Currently, that syntax generates a run-time error, "Expected Container, found Array of Containers".

The only scenario I could think of where assignment gets a little weird is with Object types, but in that case you'll have to be assigning Nothing, the return of a function call, or an existing object from another property - there's no way to define a literal value to assign there, but that's already the inherent nature of Object types.

My use case is often container initialization. There are several kludges around this - keeping an empty copy of the container and assigning it to the working copy to clear the working copy, individually listing out each parameter, and a few others. Another case is when it's useful to assign a constant to module parameter - it's debatable that may be bad form, but would still dramatically improves the ease of skimming parameters if it were implemented. It would be a slight bonus to Sequence adapter in particular, which cannot expand containers in the parameter list, as other adapter types can (go kudos Allow Sequence Adapter to expand containers in the module tab to fix that!).

Right now I can configure search directories in TestStand, but I am limited. There are 2 types: either an absolute path, or a "programatic" value (think <current sequence file directory>, <TestStand Public Directory>, <Windows Directory>, etc). However, these "programatic" values cannot be modified. I would LOVE to be able to configure a new search directory of "<Current Sequence File Directory>\LabVIEW_files\*", or "<Current Sequence File Directory>\..\Code Modules", but TestStand doesn't support adding modifiers to the ends of those paths.

It would also be nice to be able to specify <Current Process Model Sequence File> as another value.

This would help greatly with being able to move files around, and limiting the total number of search paths, and limiting the cross-linking of finding the wrong code modules for individual sequence files.

When LV throws an error, it's all very easy to catch via callback and/or is auto propigated through the system to Runstate.SequenceError etc.so it can be detected.

When LV throws a warning... the data doesn't seem to go much of anywhere in TS... and unlike LV it doesn't propigate from step to step either.

I'd like to catch and log these warnings in my error handlers (naturally with different logic, but I don't want to lose the data either, it's important sometimes!)

from poking around, it looks like my options are:

(1) creating a custom steptype wrapper around all LabVIEW step calls,

(2) editing each VI called by TS manually

(3) some fun expression(s) in the 'add additional result' or 'post expressions' sectionsof each LV step, to create new variables in TS on the fly... (or using a post-step callback to do the same)

It would be nice if the LV adapter / LV steptypes had some native way of catching this 'almost error' behavior and getting it into the report at least. I don't know if leaning on the error callback is the right answer, since, afterall, these aren't errors... but having a warning callback feels too LV specific...

How about a checkbox in the LV adapter, where you could specify 'treat warnings like errors' and then in the Error callback you could check to see if the bool was false, and punt as desired?

Is there something I'm not seeing that would be a better solution?

--Elaine R.

(This idea was created as response to this discussion board topic: https://forums.ni.com/t5/NI-TestStand/ExpandPathMacros-FindFile/m-p/3767542#M56811)

The commands "Engine.FindFile", "Engine.FindPath" and "Engine.ExpandPathMacros" only support one macro:

$(Platform)

but there are other generic paths that could be helpful e.g. when trying to call a third-party .dll (that's my main usecase) or write a logfile:

-------

$(commonprogramfiles) - The actual folder name varies depending on Windows language settings and bitness. No absolute paths possible but a lot third-party .dlls are here.

$(temp)

$(localappdata)

$(appdata)

$(user)

$(public)

$(MyData) - The actual folder name varies depending on current user and Windows language settings

It hopefully shouldn't be too hard to access the windows functions which get the actual names via macros.

It is really easy to get a user in system by name via the current API methods

User = Engine.GetUser("loginName")

but if you want to (A) delete that user, or (B) update values related to that user (password/fullname/loginname) there feels like an unnecessary number of hoops that must be vaulted through related to digging through UserFile->userList->AsPropertyObject-> Get/SetPropertyObjectByOffset()

in both cases, I'm obliged to loop through the userList to find the element I want, and then fetch/set/delete it.

I would love if there was some shortcut in the API to take on this chore for me in a more efficient manner. Something as simple as:

index = Engine.GetUserIndex("loginName")

would match behavior that already exists with Sequences and Steps so that I can efficiently know what array element I want to interact with based on the current name.

or if we wanted to get fancy we could have an:

success = Engine.UpdateUser("loginName", UpdatedUser obj)

function that would go all the way and actually take a replacement user object and do the array overwrite & save the file for me... but I'd be content to do that myself if there was just an easier way to get the information I wanted in/out of the userlist having to maintain my own search list for users in memory feels tedious. We already have GetStepIndex() and GetSequenceIndex(), so why not one for users too?

--Elaine R.

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:

It would be nice if there was a station option that would set the default load option for all created sequence files. Currently I must either programmatically modify the RunState.SequenceFile.ModuleLoadOption property with a statement in each of my .seq files or navigate to Edit » Sequenfe File Properties and change the feature over and over again.

An example of what I'm talking about is shown here:

Programmatically Update Default Sequence File Load Option
https://decibel.ni.com/content/docs/DOC-20095

Thanks!

View All (5)

There should be an Engine Callback that is executed as the very last step in the order of step execution that will execute regardless of any and all settings or step results: the PostStep "No-Matter-What" Engine Callback. I have a requirement to perform certain actions at the end of every client sequence step regardless of step, station, report settings as well as step results (Status, Error). Right now, the callback that gives the best coverage is ProcessModelPostResultListEntry, but this does not fire when client sequence developers set Result Recording Option for a step to False. My requirements call for my actions to execute whether or not the developer of the client sequence desires the results to land in the TestStand report or not. As with other callbacks, if it is blank, the engine can skip it.

The PostStepNoMatterWhat callback would execute regardless of all these, but as an aid to Framework developers, NI should provide a matrix for each of the default Process Models that shows which of the engine callbacks will execute given the following data&colon;

Step.Result.Status {Done, Skipped, Passed, Failed}
Result Recording Option {Enabled, Disabled}
Step.Result.Error.Occurred {True, False}
Run Mode {Normal, Skipped}
Ignore Run-Time Errors {Enabled, Disabled}
On-The-Fly Reporting {Enabled, Disabled}
Error Dialog Selection {Ignore, Run Clean-up, Abort}

Let consider I have an array of containers. The container is defined as a user type, (array of the same elements) and consist, let say, from three string variables A, B and C. And, let say the array size is for, example 4.

Now, let say, the developer needs to access the array of elements A. Let say he/she has to create an array od strings called StrArr So what he has to do is for example like below:

FileGlobals.StrArr={FileGlobals.MyContainerArray[0].A, FileGlobals.MyContainerArray[1].A,FileGlobals.MyContainerArray[2].A, FileGlobals.MyContainerArray[3].A}

It is a lot of writing isn't it?

Wouldn't be worth considering to implement implicit conversion which allow just to write

FileGlobals.StrArr=FileGlobals.MyContainerArray.A

FileGlobals.StrArr=FileGlobals.MyContainerArray[].A

View All (4)

It looks like there is no "gentle" way to access the results of the executed tests in ongoing execution during this execution.

Sometimes there is a need to access the test results during the execution, before the data will be committed to the database, and execution is still ongoing. The reason for that could be we can reuse the some data of the test in other tests, or we can use for example the status of the test to drive the flow in our sequence.

It looks like there is no other general way to do that as only described by Sasha here: http://forums.ni.com/t5/NI-TestStand/RunState-ProcessModelClient-How-to-access-the-results-from-the/td-p/2796658

So, theoretically, - please read Sasha post - we have recipe to access all results we want. However, problem with accessing the result list is that, that it is done via the index of the ResultList array.

It leads us to two problems:

1. the elements in that list depends on the step position in the sequence file, which makes the editing sequence almost impossible,
2. if our sequence contain loops the problem from the point above is even more impossible.

Therefore, the idea:

Please prepare the easy accessible, not index based as it is now, method (container?) which developers can access the Results containers of the steps on the fly during the execution.

Handler proposal 1:
Step name (binded as unique ID) + execution order number

Handler proposal 2:
Callers path + StepName +execution order number

where execution order number could be the handler which could be number 0 by default unless the step is called few times.

Other post: https://forums.ni.com/t5/NI-TestStand/Accessing-measured-data-from-further-steps/td-p/1144710

View All (4)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

NI TestStand Idea Exchange

Add MathScript capability to TestStand

ProcessModelFileLoad Engine Callback

Add basic file I/O functions to TestStand

Allow containers to be assigned/initialized completely in a single expression

Improve Search Directories for TestStand

A way to trap LabVIEW Warning data the same as LabVIEW Error Data from Steps

Smart rename into/out of container

provide cancel button on loading express VIs dialog

64 Bit Sequence editor

Programatically allow to select LV Adapter Development System version

Ability to get the current ProgressText and ProgressPercent

Additional macros for "Engine.FindFile", "Engine.FindPath" and "Engine.ExpandPathMacros"

Add new API for Engine.GetUserIndex("loginName") or Engine.UpdateUser("loginName", User obj)

Allow model plugins access to Engine callbacks

XML generated for report text of reporting results of For loop contravenes W3 XML spec

Add Station Sequence File Load Option

Modify sequence during excution

Add New PostStepNoMatterWhat Engine Callback

Implicit and fast container array elements access.

Make the access to the test results data during the execution more easy.