NI TestStand
Report not displayed in TestStand due to stylesheet path issue
I'm not sure whether this is a bug or it is expected operation. Where I use the UUTStatus macro to include the UUT test status in the report file name, the report is not successfully displayed post-execution in the TestStand Sequence Editor if I do not include the absolute path in the report.
What I believe may be happening is that the temporary report file is being generated in AppData\Local\Temp\TestStand and then being renamed and transferred across to the correct, final location. It seems that when it generates the temporary report, it is trying to use the relative path to the stylesheet relative to the temporary folder, rather than relative to the correct, final location.
Conditions and steps to recreate:
TestStand 2017 32-bit, Windows 7 32-bit VM
1. Brand new installation (i.e. result processing configuration default)
2. Create new empty sequence file and save to disk
3. Change report options File/Directory to Specify Report File Path by Expression
4. Add the UUTStatus macro to the path (<UUTStatus>)
5. Uncheck "Store Absolute Path" on the Contents tab.
6. Run the sequence via the Test UUTs entry point
7. Enter serial number
8. Click stop after the first execution
9. Report viewer in TestStand says unable to load the style sheet tr5_horizontal.xsl. It is looking in AppData\Local\Temp\TestStand.
10. The actual report generated in the client sequence folder can be opened successfully if the stylesheet is in the same folder, i.e. the relative path in Report Options is correct.
Note that without <UUTStatus> this works correctly. i.e. it is the need to use the UUT status post execution to determine the report file name.
It appears this is the same on 2014/2016.
Would anyone have any thoughts on this?
wrote:
I was able to reproduce this behavior and I already reported this to R&D. For me it looks like a bug and should not behave like this.
A possible workaround would be to use a second report just for display. In this case on 32bit you should be beware of possible memory issues due to the fact of the second result processing.
Many thanks for your help with this Christian. I was running TestStand 2017 on a VM to test this which just happened to be a 32-bit OS image but that isn't a limitation for the actual system.
Would you know whether this has been recorded as a bug with a CAR I could look out for in future TestStand version release notes?
