|
|||||||||||||
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>
Why not make it possible for Teststand to generate reports in PDF format?
It would make it a lot easier to send a testreport of a specific board to people not connected to the actual tester.
Today we use XML but this requires the stylesheet to be present on the readers pc.
Graphs are also not showing correct unless you do a manual setup of the settings in Internet Explore.
PDF would make my life a lot simpler
/Michael
Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use.
This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.
Regards,
Kyle Mozdzyn
Applications Engineering
National Instruments
1) TestStand functions Time() and Date() only output local format; they should support both local and UTC format. (Like LabVIEW's Format Date/Time String)
2) TestStand configuration options should have a setting(s) for:
report time format local / UTC
datalogging time format local / UTC
It would be helpful to be able to provide a regular expression (like Labview Match Pattern) as a string value test limit. We often look for a pattern of data within a string rather than a constant.
Maybe also a regular expression function within the built in functions within TestStand expressions would be a help also. This could provide more flexibility if a user needs it. For example adding option to gain match position, and match length as well as give the option to search in reverse and ignore case.
Almost all of our analog measurements are specified in %: example
a Power Supply DMM measurement limit is 24.00Vdc +/- 5%
We typically have 100+ measurements like this in a project
Why not include it in the default step types as an optional selection?
I sure would use it, so would my team.
I agree that it should not alter existing programs using the default step, but I believe that this feature should have been in Teststand when it was first released.
I have run across this in both analog measurements, and the results from an ADC
Think a limit of 0x234 +3%, -7%
A nice feature of reporting is the ability to form the report file pathname using an expression. However, since the path is resolved before the client Sequence file is executed, you cannot use properties populated in the client sequence file as part of the report pathname. Currently the only way to accomplish this without modifying the model or reportOptions callback is by including the <UUTStatus> macro in the path expression, which enables a portion of the process model which copies the report to a new path based on the result of the UUT:
I propose that we add an option to force the report path to be re-evaluated after the client sequence to allow users to include properties evaluated in the client sequence file in the report file path without needing to include the <UUTStatus> macro. (basically exposing the ReportOptions.NewFileNameForEachUUTStatus property in the dialog)
In the report options, when you have selected to include measurements and insert graphs, it would be nice if TestStand could provide an option to display multiple numeric limit test measurements in graphical form. To expand on that, when the value goes outside of a limit, it would be nice to have a red point on the graph to show where this occurred at.
TS does not allow the ability to rename steps that are of the Flow Control type (i.e. If, Else, For, While, etc.). In a report, these generic names are then used, making it very difficult to know what condition the step was evaluating to determine whether to enter or continue within the flow control block. A step name would normally give the reader of a report some indication as to what is being tested or reported on. This is not the case for these step types.
For example, an "If" step that is determining whether a condition is met (and whether to enter into the subsequent steps within the flow control block) simply shows up in the report as:
| Step | Status | Measurement | Units | Limits | ||
| Low Limit | High Limit | Comparison Type | ||||
| If {True} | Done | |||||
There is no indication of what it evaluated to determine it was True, meaning someone reading the report has no idea what the purpose of the step is. As designer of the test, I can look through the sequence to determine exactly what it was doing, but a report is a useful tool to be able to show to someone not familiar with the test and allow them to be able to see what happened. A report gives the reader the history of the test. Without knowing what a step is for, a lot of the "story" being told by the report is either lost or becomes much harder to follow.
I would assume there is a reason as to why these step types are not able to be renamed, but I'm not familiar with what that would be. It would be nice to be able to modify, or at least add to, the step name so that the report gives some indication of what it was that it evaluated. If that is not possible, there should be a simple way to include the parameter/expression being evaluated with the step name in the report. This can be somewhat accomplished using other methods, such as the Additional Results of the Properties tab, but this is not intuitive or clean and I would think this behavior should actually be default, not something the user has to manually create and enable.
Regards,
The default process models internally enable/disable the PostResultListEntry callbacks in ways that aren't intuitive to users seeking to quickly edit a callback to customize/override behavior.
It would be nice to see that instead of simply turning off the callback (leaving users to wonder why their override doesn't work like all the others, except if they read the help/ or think to turn on 'on the fly reporting') as part of the process model based on the options....
(1) leave the callbacks on and move the 'on the fly' logic into an IF defined section within the sequence
(2) make a second PostResultListEntrys style callback that's explicitly for 'on the fly' that is in addition to other PostResultListEntry behaviors that a user may want to enable/add.
I've had several customers now who have designed custom event loggers / reports around the ProcessModelPostStep callback (with some rather convoluted logic where they dig for results) simply due to the fact that they couldn't understand why their PostResultListEntry callbacks didn't work.... or that they didn't feel comfortable editing the process model in order to remove the logic that force the callback to be disabled when not 'on the fly' and also keep the 'on the fly' reporting unharmed if they want it later.
Cheers,
Elaine R.
something Kekin proposed with the digital signature made me think, that it'd be nice if there was a means to suppliment/append to header/footer of reports in general without having to do it with raw statement steps... (and if this already exists I apologize for not checking first).
I think it'd be neat if there was an approach similar to the 'Additional Results' logic per step that's available. In the 'ModifyReportHeader' callback, or in the report options somewhere, a user would be able to supply the data within a certain list of available options/allowable types, and the report generator/DLL would handle the formatting/whitespace such that it works for txt/html/xml headers without the user having to do the formatting themselves. From my experience, most items added to headers consist of (1) supplimental string data, (2) supplimental numeric data (3) small images/logos(in the case of txt, maybe the alt text can be used, or just the path put into the file...?)
even if the new info was just tucked into the list/table before the failure chain block, it would be a nice time-saver for users who want a generic report but just have one more UUT detail that needs to show up in the header.
When a 2d array is added to the report as table, you get the following table:
[0][0] 00
[0][1] 01
[1][0] 10
[1][1] 01
It would be better to have a table like this:
[0] [1]
[0] 00 10
[1] 10 11
Currently this needs to be implememented in the stylesheet. But for a lot of users, this is a complex workaround.
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?)
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... ;-)
When I create reports they usually look like:
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
The Additional Results Step property is a great way to add customized results to the TestStand report for a particular step without much effort required. However, there should be an equally simple way to add additional results too all of the steps in a sequence. The current options are all lacking:
I think there should be an additional results option available in either the report options or in the sequence file properties window or the report options window. Configuring the results here would be identical to adding the additional result to every step in the sequence.
Potential implementation of button on report options window:
Additional results button launches a dialog:
Since reports are to certify the test results, it would be nice to have DIGITAL SIGNATURE option to give it FORMAL touch.
It will also help in organizations to authenticate the result.
It will be also nice to add some PPT or PHOTOS to report to describe the test setup & UUT.
Have an option in Report Options to modify report format.
1. A new tab "Report Format" which can provide the option to generate report in default mode (I call it vertical) or customize to generate in horizontal format.
The Report Format tab can have defined set of options for user to enable in the report. The horizontal format would look like something similar to as shown in the attachment "Report_Horizontal.jpg".
2. Have a checkbox to generate report in Horizontal Format on the "Contents" tab. When selected the report will be generated with the similar table columns shown in the attachment "Report_Horizontal.jpg".
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