|
|||||||||||||
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>
Currently, the only way to pass parameters from a subsequence to a caller is by reference. It would be nice if you could also pass parameters to callers by value to prevent the callers from modifying them.
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
Right now, custom substeps (edit substep in particular) only supports one step at a time. (I can only invoke the edit substep if exactly one step is selected). However, I have a case where I have a dozen or more steps in a row that are all the same custom step type, and I want to perform the custom edit event on all of them. This means going through each one individually, which takes a while. I'd love to be able to select all of them, and then invoke the edit substep call for all of them at once. The "cheap" way to do this would be to just invoke the edit substep of the first one, and then once that is done to go to the next, and the next, and finally you are done (but this is still annoying to the user). What would be nice is to be able to pass an array of sequence context values in (one for each step that is selected), and then your edit code could manage all of the steps however it sees fit. If multiple different step types are selected, it could just default to not allowing a multi-step custom edit, but ideally if all of the steps selected shared a common edit substep entry (name and module) it would allow it.
After a recent attempt to create a virgin system by deinstalling all NI software and installing it again I hit an issue that took quite a while to resolve (FYI: Reference#1295936).
Basically, neither the file system nor the registry was properly cleansed during the uninstallation procedure.
Sometimes this behavior is desired - e.g.. if you want to keep user settings - but sometimes not.
Currently the user is neither given the option to decide whether he wants a "clean" uninstall or one which keeps data saved nor he is given information about the extend of the uninstallation.
An selectable option to create a virgin system (at least regarding NI software) either during deinstallation or later during installation (if residual data is detected) could be helpful.
This applies to all software handled by the NI installation routine, I just put it into the TS-section because there I missed it first.
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.
http://forums.ni.com/t5/NI-TestStand/TestExec-ini-
Thanks
David Jenkinson
TestStand now works incredibly well with LabVIEW Classes, but there is a slight annoyance with the fact that you cannot call a Dynamic Dispatch VI with an empty Object Reference. The implication of this is that when you want to use a .lvclass, for every class instance you have to call a VI that does nothing more than return a wrapped class constant which then populates an Object Reference. Technically this is not a problem, but it means that your Sequence becomes very quickly littered with these VI's and it would be nice if there was a way within the LabVIEW module adapter settings for a class member call if when you first call a Dynamic Dispatch VI that, as within LabVIEW you can just pass in a class constant rather than a previously populated Object Reference.
The Problem - All the LabVIEW calls prefixed with 'NEW' are simply returning a class constant.
A Potentially more integrated way of doing this
The Dynamic Dispatch input has the option of either passing in an Object Reference, or a class constant.
All compatiable classes are listed in the value box now - either as .ctls, or alternatively as .lvclasses. This could also possibly be more akin to what happens in labVIEW when you call a Class which has available overrides that it gives you a tree view of the class hierachy to choose from.
Another way you could do this is to have a checkbox adjacent to the 'Class Path:' or 'Member Name:' named 'First Call' or 'New' or 'Construct' that then changes the 'Derived Class
Often times a sequence file ends up containing dozens (or even hundreds) of sequences. Currently they all show up in the sequence editor Sequence Window as a flat list. It sure would be nice to view them organized in folders so that, for instance, all my sequences dealing with Rs485 communications or whatever could be group together in a "folder" called "RS485". Also it would be great if there was a displayable property for each sequence showing the date/time last modified. Then you could sort the list on that and see which sequences have changed. (really helpful if you have multiple guys who might be making changes.)
When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help. While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help. I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.
This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users). Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.
When creating custom step types, it is highly recommended to use Post-Step for calling execution module instead of Default Module.
Thus, when instanciating a custom step type, parameters passing is not saved within the sequence but only in the step type definition.
This allows to change parameters passing without having to update all the step types instances.
In some big test benches, it is intersesting to have low-level step types and high step types based on low level step types.
High level step types execution modules are sequences using low level step types.
Since sequence adapter is not available for Post-Step, we are obliged to call the sequence through Default Module.
Thus it can generate problems when adding parameters in sequence call.
I suggess to allow Sequence Call in SubStep creation :
Jean-Louis Schricke, MESULOG
TestStand Architect
The Sequence File Documentation Tool allows you to create documentation in the file formats HTML and text.
It would be nice if it could also create XML based documentation similar to report generation. Selecting a style sheet will ensure that the XML file is presented in a certain way using a browser.
Norbert
The menu to create a new variable (right click on variable in an expression edit control and select Create "VariableName") contains all the data types you can use for the variable, however, in the LabVIEW Panel (and other similar panels or dialogs) there is enough context information about the variable to suggest a data type, for example, if the variable is in a control of type Double we know we should create a Numeric variable. TestStand should add the contextual suggestions to the top of the context menu and bold them so that I can more quickly select the data type I want most of the times, then have a separator and put the normal menu so if I don't want that data type for some reason I can still choose the other data types (see attached image).
I am a new user of TestStand for about 6 months or so. Please pardon me if this post is duplicate ... I did a basic search to make sure it wasn't.
Test Stand is able to load a cluster from LabVIEW and show its elements, very cool.
It might be awesome if a Container in TestStand can be loaded into LabVIEW that'd do the same.
I currently use property loader to load calibration data from a file during test. I populate this file using export. The problem is that now I want to write a calibration sequence as well and there is no property exporter step to do this programatically in TestStand. I will end up writing my own code to create this to emulate the way that Import/Export does it but it would be nice if this was supported as a TestStand step.
Hi!
I was working on a project which required LabVIEW 2011 and TestStand 2010. The software had lots of LV modules already created. I reused some of them. However, I needed to trim whitespaces in TestStand which were coming from the string outputs of these LV modules. Nevertheless, I was surprised to discover that there is no TRIM string function in TestStand at all. I had to create a simple VI which just trimmed the whitespaces. I couldn't modify the previously created modules because they were used elsewhere and could affect the outcome of the other test systems. Why does TestStand lack this simple functionality?
Regards,
L_A_B
Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. | E-Mail this Page
|
||

E-Mail this Page