NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Additional Results step type doesn't log additional data in ProcessModelPostStep

Solved!
Go to solution

I would like to log additional sting data that comes from a StationGlobals.string variable to every step in my xml report without having to modify the thousands of steps already written.  I tried to do this by adding a ProcessModelPostStep callback to my custom sequential model and placing an "Additional Results" step in the sequence.  I set the Name to "StringData" and value to log to "StationGlobals.string" but when I run the sequence this data never makes it to the report.  The sequence properties has the "Disable Result Recording for All Steps" unchecked and the "Additional Results" step has the result recording option enabled.  Is there something about process model callbacks that doesn't allow this to work?

0 Kudos
Message 1 of 5
(4,386 Views)

You can't just place a step anywhere and suddenly expect it will show on the report.  You need to get it into the MainSequence Locals.ResultList.  This is ultimately what gets put in the report.  Callbacks are not set to propagate their ResultList back to the caller (mostly because they really aren't called as code modules).  

 

Fundamentally you need to understand that each sequence contains a Locals.ResultList.  This is what collects the data that goes on the report.  If that result list isn't passed back to MainSequence somehow then it won't show on the report.   If you were to pause in ProcessModelPostStep callback and look at Locals.ResultList you would see your result in there.  Sadly though it doesn't make it's way back.  

 

Overall I would think that you want the additional report to be part of the step. I've created a simple example that shows additional result injection.  It gets a little tricky because you are populating expressions and also you need to check and see if the result already exists before just throwing it in there.

 

I do it in a SequenceFilePostStep but the same principle would apply to ProcessModel or Station Post Step.

 

Let me know if you have any questions.

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 2 of 5
(4,354 Views)
Solution
Accepted by jason1

Honestly, your request makes little sense. Why would i ever want the same string all over in a report for every step? That sounds like blowing the memory consumption through the ceiling without any use.

The only case this makes sense is if each step modifies that string. However, i doubt that this is the case.

 

Anyways, here is the content of a PostResultListEntry callback which logs a FileGlobal string to report:

AddGlobal.PNG

Both steps are important!

Note that in my example, the FileGlobals.FileGlobal is the variable i copy and add to the report. You have to modify this as such to target your StationGlobal variable.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 3 of 5
(4,344 Views)

Thanks jigg for the explanation and posting of a sample seq.  I mistakenly assumed the results list of ProcessModelPostStep would be passed back.  However, your solution doesn't work for my situation, which after reading Norbert's response, made me realize I need to give more explanation of what I'm trying to do.  Maybe you have a better method.  I was trying to keep it simple.  I actually do modify this string after every few steps including looping steps.  I created a StationGlobal.Procedure_Number as way to keep track of where I am at in relation to a procedure document that we use in production.  Sometimes a single TestStand step matches with a single procedure number and sometimes it takes multiple TestStand steps for a single procedure number.  This allows anybody to look at the test report, view the failing step number and then go to the procedure to see what the test set was doing.  This also gives me single variable to view for progress as my test sequence is tracing through several sequences with many reused subsequences.  It seems like this information should be in its own property for each step.  Norbert’s method works for me but it brings up another problem. 

The report is ugly an unnecessarily long.  It takes two extra rows for each step to display the data.  My report is already hundreds of pages without this.  I would rather see it in an extra column like shown below.  I’m sure there are people out there that can understand the complexity of NI’s stylesheet and can edit it but that’s not me.  With some struggle, I figured out how to add columns and get the proper data to it.  Any ideas how to remove these rows for this specific instance, not all additional data?

 1.png

I found it interesting if I add the Procedure_Number in the additional data for a single step without the “include in report” box checked it still adds it to the xml report but the stylesheet won’t display anything because the flags are set to 0x0000, which is what I would expect.  The report is exactly what I would want to see, as shown below, but I don’t want to have to do this for every step.  Although maybe I should reconsider.

 2.png3.png

 
If I use Norbert’s method with the flags set to 0x0000 it never makes it to the xml report.
 4.png5.png
 

Here is what I added to the stylesheet

 6.png

Thanks to anybody that managed to read this entire post.

0 Kudos
Message 4 of 5
(4,310 Views)

I am not sure if a textual report is suitable for your needs. It sounds like you would be better off with databases and use interfaces (e.g. webbased) to generate text reports of snippets of the data in the database.

Yes, i am aware that you would swap "stylesheet programming" to "SQL query programming". However, databases provide more flexibility for possible future requirements towards the report.

 

"Additional Results" which you configure per step work differently for report generation in XML than 'normal' data in the Result container. Additional Results are always put into the XML report, but the style sheet filters them out if IncludeInReport is false. For normal data, the report generation process disregards that data completely skipping it. You are indeed observing expected behavior here.

 

Removing the 'redundant' rows from the XML report requires additional modifications in the stylesheet. I haven't done that myself so i cannot tell you exactly how this is done. I would start to look how filtering is done in the stylesheet, e.g. how !IncludeInReport flagged data is excluded while IncludeInReport data is included.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 5 of 5
(4,303 Views)