* Why not include Configuration files, such as TestExec.ini by default in Deployment Utility?
* Also using default settings, nothing appears in the Start Menu/All Programs menu on the target machine. Why not have the main sequence file to be installed so that it appears in the Start Menu/All Programs menu on the target machine?
If there's a way to do this already feel free to ignore this suggestion 🙂
I have a process that spawns N parallel measurements for a given DUT at one point during code, and then has a series of wait steps later, to collect all the results / errors / etc.
I have a reaonable timeout, with error generation enabled on the Wait steps as a safety mechanism in event a process hangs (rare, but not impossible). During normal execution these timeouts never trip, and all runs beautifully.
If I set a breakpoint/single-step my execution to troubleshoot one of the measurements during design/debug, often times it takes a while before I 'resume', and when I do, the timeout on the parallel wait immediately trips with error.
would there be some way to make the Wait step's timeout logic 'pause' while execution paused and 'resume' when sequence is executing normally? that way the error I'm trying to trap during debug won't get confused with an irrelevant error for 'you took too long'...
i know I can put conditional logic on the timeouts to discard the error if running inside the debugger, but it'd be cool if the step was just smarter in general
When editing in CVI, I often find it useful to copy the contents of 'Find Results' into an edit window so I can edit/parse/filter/sort the information. I would like to be able to do the same thing in the TestStand Sequence Editor. Saving the Find Results to a plain text file would be an acceptable alternative.
Because a customer asked me about it... And in looking around on the forums I'm surprised there's no opensource 3rd party solution yet to fill this gap
TS has the ability via that little .ocx component to 'ploty' via the graphcontrol tool in an HTML or XML report. But after many years, there is no 'plotxy'. As this seems to be a common need for customers, maybe this could be rolled in with other changes? (if it isn't already?)
The Database Options dialog in TestStand 2013 and 2016SP1 (the versions I have tried) have the key focus set to the 'OK' button. Pressing the 'Enter' key at any point while navigating that dialog will close it and not save the changes.
This becomes very frustrating when editing the 'Command Text' of a database statement as you might want to insert line breaks to make editing/reading the statement easier.
I have had this happen at least 10 times already today and is very frustrating and is only a very minor change to the Database Options dialog.
Finding syntactical errors -- missing arguments, arguments of the wrong type, ... -- involves either manual inspection or running a sequence to see where it croaks. TestStand could use the equivalent of a broken run arrow from the LabVIEW environment. As in the LabVIEW environment, clicking on that broken run arrow would present a list of the syntactical errors, and double-clicking on one of the entries in that list would take you to the entry itself.
I would like a built-in tool in the Sequence Editor that would check my sequence file to verify that all expressions used in every step are valid and that all variables called exist. It would be nice to find errors during development/edit time rather than at run-time. I think this could significantly improve the usefulness of TestStand.
If you double click a LabVIEW step in TestStand, currently it will sometimes enable you to edit the name of the step. I think it would be better to have a double click open the LabVIEW VI that is called by the step as that feels more natural then right clicking the step and selecting edit code.
The Start Modal Dialog VI currently needs to be placed on the block diagram of the VI that needs to be modal. This means that you can't put it in a subVI with logic around it. If a VI reference input were added to the VI (with the default being the calling VI) then you could keep the same functionality but have the option of calling this from a subVI.
For those that are running into this, there used to be a workaround here:
The behavior of the TestStand - End Modal Dialog.vi should be changed. The current behavior is for it to not execute if an error occurred before it runs. Instead, it should always execute, even if an error occurred before it runs. With the current behavior, if an error gets passed to the VI, it can cause TestStand to hang. In general, close or end functions and VIs should always execute even if an error occurred before they run because unintended consequences such as errors, crashes, or hangs can happen if they don't execute. Yes, you can use the Clear Errors.vi before the TestStand - End Modal Dialog.vi and Merge Errors function to work around this behavior, but it would eliminate the need to do this if the behavior of the VI were changed.
We source control testexec.ini, becuase I want to replicate the custom path information, which is stored in testexec.ini, among our other stations. But, whenever I start teststand, it tries to write to testexec.ini for some reason, and I get the "can't write to testexec.ini" message because this file is set to read only when checked in (which in our case is most of the time). I have become so accustomed to clicking this message that I dont' even think about it.
But, I do have a request to the developers. Please store path information (paths configured under configure/search directories) to a file all by itself, or to a file that does not share so much other information that testexec.ini stores (which is a lot). I notice there is a file called teststandperistedoptions.opt, that appeared around TS2010, that perhaps a lot of the testexec.ini stored stuff can be migrated to? That way I won't get this message every time I start teststand.
At least one other person has had a similar issue.
With the release of TS4.5 there is new way of .net invocation.
The new look of the .net panel was first strange to me.
I was always searching constructor stuff for defining a handle But after understanding. It is very easy use.
Add especially the feature with the dots is pretty good. It seems you are doing your stuff in programming language like VS. But this leads to a “missing” feature. Which is not possible in VS.
In TS 4.5 you may store every return value ina variable.
If your invocation consisting of many “.” calls. You only see the return of the bold function. So this feature makes some return values “invisible”. Maybe a tree or using some other colours should make them visible again
For our test we use 48 TestSockets in a Batch process model.
Every TestSocket will gather data for every millisecond while the test of maximal 3 minutes is preformed. A few times per second we like to call a LabVIEW VI and preform some tests on the last few seconds of this data. To give the CPU some time to do other things a 100msec wait time is in between all the tests. While LabVIEW only needs the last few seconds of the array to preform the test, TestStand will take a subset of the array and give this to LabVIEW. But this subset it already taken more than 1.5 seconds in TestStand.
Attached is a small Benchmark test that shows (and hopefully explain) this behaviour.
We just make an local array of 180000 data points. (3 minutes with 1msec sample rate)
A for loop of 100 times is done to average the results.
In the loop two VI's are called.
One with 100msec wait.
The second to receive the array. In LabVIEW the array isn't touched.
If we just start with an array from 10000 data points. (the first 10 seconds)
This will take 107.5 msec and about 12.5% of my CPU resources.
Seems good, but the data grows to about 3 minutes, lets test 180000 data points.
This will take 138.5 msec and about 40% of my CPU resources.
We already use 40% of my CPU without doing anything more than give LabVIEW the data.
As we don't need the complete data array, it seems not smart to copy everything to LabVIEW. TestStand is capable to take a subset from the numeric array and send this part to LabVIEW.
So if we want to analyse the last 5 seconds, we give the data to LabVIEW like this:
Locals.Array[175000 .. ]
This is only half of the data as the first test, so expected it will be about same in execution speed.
The average execution is now 1.6 seconds, so 1.5 seconds is used for the array subset.
Also the CPU is fully taken by this process. This way our application can't work.
As a workaround I send in the complete array into LabVIEW and take a subset in there. This is at the moment faster than take a subset in TestStand, but I would expect that this process can be faster done inside TestStand.
I would like to post the idea of an optimized array subset function.
This will optimize the performance of TestStand greatly while working with larger array's.
Especially if you have more TestSockets than CPU cores, like me.
Currently you must set the path to the folder that teststand will load its inital configuration through the options. This means that it is not possible to change this via the cmd line wehn launching sequences. Tehre are several work around for this (none of which are very good).
The 'best' solution to this issue would be to add "/configPath "c:/projects/tests1/" " as an option on the cmd line and allow teststand to use this instead of the path hardcoded int he registry.
The TestStand Deployment Utility lets you select the following locations for the installation destinations of individual files:
However, you can select the following for the default installation base directory:
It would be really nice if both lists of available installation locations were the same, both in terms of locations and naming conventions. The most glaring omission in the file installation destination list is the Windows Volume location.