NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

TestStand 3.1 XML Reports in TS4.1

 

I am trying to implement TestStand 4.1 in our facility as seamlessly as possible. This means I still need to run TS3.1 sequences with no modifications on both systems with TS3.1 and with TS4.1.

 

My problem is with the creation of xml documents when run in TS4.1. When we first implemented xml it was on TS2.0 which didn't support xml at the time. So some patch was downloaded from NI I believe and it worked fine. We continued to use the patch when we switch to TS3.1. But when I now run the TS3.1 sequences in TS4.1 the reports are generated, but slightly differently, I cannot view the xml document in I.E. The error is:

 

"Required white space was missing. Error processing resource"

 

and the offending line(s) in the report are: 

  

<ATMLStylesheetMRU type=" dimensions="[0..2]" decimateBy="0">
  <Element type="" index="[0]" name="ATMLStylesheetMRU" >trml.xsl</Element>
  <Element type="" index="[1]" name="ATMLStylesheetMRU" ></Element>
  <Element type="" index="[2]" name="ATMLStylesheetMRU" ></Element>

  </ATMLStylesheetMRU> 

 

These lines do not appear in the report if the sequence is run with TS3.1. 


I modified the TS3.1 Process model and ReportGen_XMLseq to use the original "modelsupport.dll" from TestStand 3.1 since the TS4.1 version didn't support some of the commands called. I also changed the report.xsl and horizonal.xsl called from the process model to the TestStand 4.1 versions, but the problem is still there.

 

I admit to not knowing exactly how the reports are generated, but I suspect the above lines are there because the API calls are to the TS4.1 engine as it is the active TestStand version. Looking for any sort of help on this one, not that well versed in xml. Am I trying to do the impossible? I don't want to switch the reports to the TS4.1 format at this time, as we have custom software that imports the data and it currently doesn't work with the TS4.1 report format.

 

Thanks 

0 Kudos
Message 1 of 6
(3,628 Views)

Cabman,

 

In TS 3.5 we added a new type of report called ATML. The offending lines in the report that you are refering to, is to store stylesheet information for this new report format.

But adding these new properties to ReportOptions should not cause the issues you are describing. 

 

I did notice that the text you pasted is not exactly what we generate in TS 4.1.Here is why we generate in TS 4.1 for xml reports

 

    <Prop Name='ATMLStylesheetMRU' Type='Array' LBound='[0]' HBound='[2]' ElementType='String' Flags='0x0'>
        <Value ID='[0]'>trml.xsl</Value>
        <Value ID='[1]'></Value>
        <Value ID='[2]'></Value>
    </Prop>

In the text you pasted, I noticed that type attribute is empty in all 4 lines and also the generated XML snippet looks different.

 

I am not sure how your XML report was generated,  but that might be the issue. 

In TS 3.0, we introduced a new API called PropertyObject.GetXML which can be used to generate an XML report. 

 

To help diagnose the problem I have a couple of questions. 

1. Do you still use your TS 2.0 process models or are you using TS 4.1's process models?

2. Can you give me more details of how does the XML report get generated in your system? Are you using the 2.0 XML report generation mechaism or did you move to using TS 4.1's XML report generator?

 

Regards

Anand Jain

National Instruments
0 Kudos
Message 2 of 6
(3,619 Views)
Thanks for responding.

The report was generated using TS4.1, running a TS3.1 sequence with a TS3.1 sequential process model. I can't use the TS4.1 xml reports at this time since they are incompatible with our software that imports our xml files.

The TS3.1 Process Model was created back in TS2.0 with the xml features as an addon. I not sure of the details as the programmer who did it is no longer with us.

If the report is XML why is it including some ATML properties? Can you also explain the role of the style sheets? I know the role of report.xsl is to allow the xml data to be displayed in Internet Explorer, but what is the role of horizontal.xsl?

 

 

Dave

 

 

0 Kudos
Message 3 of 6
(3,600 Views)

In response to your final paragraph:

a) In the creation of the XML document, TestStand places all the report options into the XML report, including ATML properties even if it's not an ATML report.  This does not harm the XML document.  

b) The horizontal.xsl and report.xsl are both stylesheets, they merely display the data differently. 


Mark E.
National Instruments

0 Kudos
Message 4 of 6
(3,585 Views)

I found the problem and the solution, but I fear it still may cause me problems when I migrate to TestStand 4.1 reporting.

 

The problem was a type conflict with Custom Data Type "ReportOptions". My TS3.1 sequences and process model use version 3.1.0.4. When I ran TS4.0 it would load the default SequentialModel.seq which uses version 4.0.0.0 of the data type. There are a number of differences, but the two that caused me grief were that array of strings 'StylesheetMRU' is renamed 'ATMLStylesheetMRU' and the added string 'ReportStyle' has contents with double quotes that caused problems.

 

The solution was simply not to load the SequentialModel.seq when running TS4.1. This works for now, but when I start to use TS4.1 sequences I can see there will be conficts again when I switch between TS3.1 and 4.1 sequences.

 

Maybe the best is to still use the version 3.1.0.4 with the TS4.1 process model? Will there be problems with this? I don't believe we will be using ATML so not having these properties shouldn't be a problem.

 

Dave

 

0 Kudos
Message 5 of 6
(3,553 Views)
If you upgrade the process model but don't upgrade all of the sequences, there will be a mismatch between the old version and the new version of the supporting files.  The XML reporting you are using that came from TestStand 2.0 did not ship with TestStand; it was an add on as you mentioned.  XML reporting was officially added as of TestStand 3.0. We recommend that you move to the current XML reporting feature.

There are two possibilities for you:

1) Migrate everything from 3.1 to the current version of TestStand.  You won't get any of the new features we introduce in new process models, but it will migrate your old system.  To do this, you will need to copy the entire model folder (<TestStand 3.1>/Components/models/TestStandModels) from TestStand 3.x to your new version of TestStand. 

2) Upgrade everything to the XML reporting that is built into TestStand.  Now might be a great time to put in the extra time to modify all your tools to use the new XML reporting. We recognize this will take extra time, and it's up to you whether it's worth the time to do it now. 
Message Edited by EadieU on 05-14-2009 11:28 AM

Mark E.
National Instruments

0 Kudos
Message 6 of 6
(3,494 Views)