NI TestStand Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Hello,

 

If you get memory problems, you had to tune your reports options, result collecting, load / unload modules  .... Smiley Embarassed

 

These tasks are very long, you have to point all memory consumers first ... It pollutes your test sequence only for memory purposes ! Smiley Frustrated

 

When you try to modify the result reccording, you will also have problems for your report generation ... 

 

It should be nice to add a new feature allowing an automatic result list removing, after onTheFly reporting, ontheFly database writing have treted them ...

 

A kind of "OnTheFly and remove unused results"

 

When ontheFly reporting, and The OnTheFly database writing are over, the treated resultList should be put in a garbage structure !

Older test results could be removed if memory is needed ... Smiley Wink

 

I know this could be not simple ... but this could help very much, for big sequences creation. Smiley Happy

 

Thanks a lot.

 

Manu.net (TestStand memory dustman !)

 

Recently I had a problem with a testprogram slowing down after 3 hours of execution.

It was traced to opening a .wav file and not closing it. The .wav file was opened and played 3 time but only closed once.

The problem was discovered by using Windows 7 task manager and looking in the process information display. The number of .wav file instances increased with every run.

Vi analyzer did not find this.

 

It would be nice to have a tool that monitors the teststand execution and highlights suspicious behavior, like growing resources.

 

Instrument handles are also an area that can cause memory leaks. If an Ni-Daq is used and not closed, resource usage grows with each run.

When a step cannot be preloaded due to the prototype being out of date (if, for example, a VI was updated after it had been placed in a sequence), an error message pops up telling the user what is wrong. This can then be used to track down where the step is that is causing the issue. Some of the error descriptions get quite lengthy.

 

While this does provide the user with information as to where the error is occuring, the only option is to click "OK", which then closes the message. In long sequences with many subsequence calls and steps (many of which may be similarily named), it is cumbersome to find the specific step that was listed in the error message that is now no longer viewable. At times I find myself having to get to the general area where I thought the error was listed as occuring, and then click RUN again just to get the error message to pop up again, and then continue narrowing it down (repeating this process several times). This is very cumbersome.

 

There is a simple solution to this issue. The easiest method would be to simply include a second button in the error message that brings you directly to the step that is causing the issue (with it selected in the step window). This would solve the main issue of trying to find the step that was listed in the error message as being the problem.

 

To go a step further, there could be a button that simply activates the "reload step prototype" that you have to do once you are at the step that is out of date.

 

To go even a step further, and solve another issue I would like to see remedied, there could be the option of reloading all steps that call that module (since they are now likely all out of date and need the prototype refreshed). Currently, if a VI is called repeated throughout the sequence, then each one must be found and have its prototype reloaded manually. This is very tedious.

 

There may be other preloading errors besides the "prototype out of date" issue (ex: VI not found, etc.) that could use the same functionality of a button that brings you to the offending step, but this is what I am running into at the moment.

 

Regards,

It'd be neat, in the scenario when a parallel thread is called, if there was some smooth way of gathering the results back into the main thread of the execution for the sake of the report. 

 

I've handled this historically by passing a parameter into the subsequence/thread with the ResultList-index of the parent-step, and then doing some notification based handshaking during cleanup of both threads to quickly copy the Result container out of the sub and back to the parent via API calls. But I bet the R&D types could do this far slicker and reduce the whole thing to a checkbox... 😉

 

21413i267B71BB01EB46E5

 

When I create reports they usually look like:

21417iA1EFA6BABE8471F4

 

I just think it'd be a simple feature to add for users who might be uncomfortable with the API  & ResultList? (Naturally if the sequence doesn't wait at the end it may never be safe to 'pass back' results. But if you're already killing time on the back stretch, why not copy the block up?

 

Cheers,

 

Elaine

Hello,

 

It would be nice to VIEW errors which occurs in the process Model or callbacks using a special dedicated window.

 

Recently, i have send updates to one of my customers, using FTP transfert.

The updates consists of processModel updates, dotNet assemblies ...

During the FTP upload by my final customer, the dotNet assemblies were marked, by windows 7, as "Bloqued" Smiley Frustrated. (For security reasons ...)

These assemblies were called in my process model.

When the final user tryed to launch his application (Operator interface), nothing occurs Smiley Mad! The dotNet assemblies calls fell in error, but without any message. I had to investigate using debugging tools to find out the problem.

 

It should be nice, in case of "anormal errors" in process model calls, or in callbacks (like frontend callbacks) to launch an error window to view this kind of errors.Smiley Wink

 

You may say, you should have test the errors and handle them correctlty ... and you're certainly right !

But i get a look to the default processModels provided with TestStand ... and they are coded as i do !!!!

So even with the 'default process model', if an internal dotNet error occurs (missing sub assemblies, no more ressources ... ) the same kind of anormal behaviour could occured !

 

So having the way to view process Model, or hidden callbacks errors will perhaps be interesting ! Smiley Happy

 

Thanks a lot.

 

Manu.

In synchronization  Notification with Wait as an Operation, then there should be Time Out status (Optional Output, Available as a property now) based on which the user can take decision.

Hi,

 

Default log option for " Numeric Array - Graph" , String Array - Array but not formatted properly. Will be good if theres a option to display as table.

 

TS - Array.PNG

Hi,

 

Now the Evaluate() command cannot resolve names when the name to evaluate is within the square brackets []. In other words if the name to resolve is a part of the index.

 

It would be demanded the Evaluate() doesn't have this limitation.  

Hi,

 

Exactly as in subject.

 

When code modules containing termination monitors receive the terminate signal, the arrow still pointing at them eventhough the current action is one of the action from the clean group.

 

It'd be good if the developers and operators could see the current operation as it is in real, not the last active from before termination.

 

Example:

 

Capture5.PNG

To restore a Teststand perspective to its original layout.