The problem: Developing Code on Production Test Stations
There are pros and cons to developing TestStand code on the same machine you are running production tests on. Regardless of whether it is an optimal solution or not, it is a fact of life. TestStand developers have done it in the past and they will continue doing it. Unfortunately, one major con of doing development on a production test station can be unanticipated changes in how your production tests work due to actions you took while developing new code.
I experienced an example of an unanticipated side-effect of code development on a production machine recently. I was testing out some code in a small demo sequence and did not want the results cluttering up the EFT database my client was using to store UUT data. So I disabled the EFT database result processing plugin temporarily. I finished up my testing, integrated my new code, and went home for the day. Later we went looking for the UUT data for production tests that had been occurring over that past few days—there were none. I had forgotten to re-enable EFT database logging. Woops.
After rampant apologies I developed a little bit of code that could be included in a TestStand sequence that would ensure that results from that sequence always got logged to the EFT database. This would insure that a forgetful developer (me) couldn’t prevent the logging of results from a really important sequence.
The Solution: Forcing EFT Database Logging
The implementation of this turns out to be fairly straight-forward (at least compared to the cost of losing data):
- In the sequence that must get logged to database, create a sequence file callback for “ModelPluginConfiguration”
- You will notice that one of the parameters of this callback is “ModelPluginConfiguration. Plugins” This is an array of containers that corresponds to every available results processing plugin shown in the results processing screen, whether they are currently enabled or not.
- Each plugin container has a property that dictates if it is enabled or disabled: “<Plugin Container>
.Base.Enabled” All we have to do is find the EFT database plugin and set this property. There are many ways we could identify which plugin is the EFT database plugin, but I have decided to look at the sequence name property, which is “<Plugin Container> .Base.SequenceFileName” The EFT database reporting plugin runs the sequence “EFT_SQL_Report.seq” Once you have found the correct plugin, use an expression to set its “Enabled” property to True Include this callback in any sequences that must get logged to the database
Note that this code will only enable database logging for the sequence that is being run. It will not “check” the check box in the Configure->Results Processing dialog to enable database logging for all sequences on a test station.
I have included my implementation of this solution below. Happy logging!