currently i am trying find a suitable workaround for the wellknown "out of memory" Errormessage during report generation.
I am trying to store the report object as a binary file. So the hole report file size will be small a possible.
In a later process the report generation should be done. The maior aim is that report generation is done without any errors.
It is quite bad if you have some nightly or weekend tests and next morning you will see that test running well but report was crashing,
and you have nothing - thats is really frustrating!
Well it seems that also Engine.SerializeObject is also limited.
I wonder this there a way to determine the size of the object? If this is possible i would split the object.
If you are using TestStand 2012 or higher, you can use the offline results processing "Results Processor". That would be the simplest way to accomplish what you are wanting to do (i.e. It's a built-in feature of TestStand 2012).
In what way is Engine.SerializeObjects() limited? Are you using SerializationOption_UseBinary? What version of TestStand? Do you have large arrays? Engine.SerializeObjects() with the SerializationOption_UseBinary option should be very memory efficient. There was an issue with large arrays at one point, but that was resolved in a later version.
Really though, it sounds like you are wanting the exact feature of offline result processing that was added in TestStand 2012, so if you can use that instead, that might be your best option.
Hope this helps,
Thanks for the answer.
It seems that this might be the best solution. I will try it with my small attached example.
if it is working (or not), i will give you a feedback.
In my example i am using the binary option. There is a loop in MainSequnce. On my maschine with TS2012 there is no "out of memory" if loopcout <= 10.
Just try it.
I have made a some Tests (test_tsr.seq).
Good news: It is working better than my Engine.Serialize stuff, if loop max count is not too large.
Bad news: If loop count is too large Sequence is crashing with exeption during MainSequence-Call. (see sreenshoots).
Previous tests with test.seq and loopmax =50 were running at least to model's report generation.
So the bottom line is that on-the-fly result recording has not the desired behaviour.
How are you running this? I'm not getting any errors on my machine with your example sequence (i'm using 2012sp1). Did you disable all result processors except for the offline one?
Ok, I think I know what the problem is. You need to go to the model options dialog and enabled the setting "Discard Results or Disable Results when not Required by Model'. Once I did this it drastically reduced the amount of memory needed to run this sequence (maximum memory usage went from 1.2 gigs to just 152 megs).
You can also do regular reporting with the report setting set to enable "On-The-Fly Reporting" and "Only Display Latest Results", that should also keep memory usage low without having to do offline result processing.
Hope this helps,
i have tried your suggestion. It works pretty well. Good job!
Now I am able to create my desired reports without any exception.
Just as performance note. MainLoop = 200 will produce a 88MByte binary report file.
Now it is time to deserialise. Of course if the result is too large Text, Xml or Ahtml will except with
out of memory. That is clear. It is my job to splitt dem into smaller files so that my old reportgenators will work.
Now the Problem is getting .tsr file back into TestStand. If you take MainLoop = 50 (22MByte-tsr-file)
I am not able deserialise it with "Process Results File" Sequence in NI_OfflineResultsGenerator.seq
If you do this with ...Processing Utility.exe you will get the same Exception.
just see the screenshoots.
I am using XP,SP3 and TS126.96.36.199
i have designed already some giudelines to disable reportgeneration. So yes we try to keep reports small.
But thats not the major topic here. Here the question is how to handle large reports. At the moment after weekend tests
you have sometimes nothing. Now you can modify sequence's result recording and HOPE that you have a report file next week.
And hope is bad to explain to the management....
EDITED: See my post after this one first. Try what that one says first. Hopefully what's described in this one isn't really necessary after you do what that one says.
If you are close to having enough memory and need just a little bit more memory and are on a 64-bit OS, you can try enabling large address aware support as follows from a visual studio command prompt running as admin (Assuming you have Visual Studio installed):
From this directory (or whereever you have things installed on your machine): C:\Program Files (x86)\National Instruments\TestStand 2012\Components\Tools\Offline Results Processing Utility
editbin /LARGEADDRESSAWARE OfflineResultsProcessingUtility.exe
This will give you about another gigbyte of memory or so to work with.
The only known issues on Windows 7 and TestStand 2012 with using large address aware are related to context menus not showing up sometimes.