programmatically disabling database reporting in new 2012 process model?

[david_jenkinson]

Hi,

We have recently upgraded from teststand 2010 to 2012, and with that has come a few days of porting our fairly heavily modified "older" process model into the new one with a plugin architecture.  All is finally running smooth except for one thing which has me stumped all afternoon. 

In our other process model, all we had to do was put a precondition on the process model step "log to database", based on the response in a custom process executed in PostUUT.  It does not appear so straight forward with the new architecture, since there is no explicit top level "log to database" sequence to simply put a precondition. 

So what I have tried, unsuccessfully, is

Move PostUUT sequence ahead of the "Model Plugins - UUT Done", which appears is the one which eventually calls the log to database steps (through many subsequence calls).

Then programmatically setting the following flags in PostUUT if the user chooses not to log to database (this database plugin is enabled by default in configure/result processing:

Parameters.ModelPluginConfiguration.Plugins[1].PluginSpecific.Options.DisableDatabaseLogging = True

Parameters.ModelPluginConfiguration.Plugins[1].Base.Enabled = False

It seems that in a  sequence in modelsupport.seq, Call UUT done/Batch Done, has a for loop that eventually iterates on the database options cluster (element 1 in this case), but ignores that fact that the above flags are set such to disable logging. 

What is the proper/preferred way to disable database logging if chosen at the end of the run by the user?

Thanks

David Jenkinson

[James_Grey]

In 2012, the "log to database" step is now in Models\ModelPlugins\NI_DatabaseLogger.seq.

You can alter that plugin sequence file or a copy you make of it. Look at call to Log All Results for Non-OTF in Model Plugin - UUT Done.

You can also override the LogToDatabase in a client file or put an early exit in the default implementation of it in NI_DatabaseLogger.seq.

This assumes you are not using OTF logging because after the UUT it is too late to decide to not do OTF logging.

[david_jenkinson]

Hi,

I did see that it is now being called in that file, but was hesitant to put the modification there, because new installations of disksets in the future would overwrite that modelsupport.seq, and I'd have to re-code that pre-condition every time we upgrade.  And if I save-as, is there the risk that future updates of modelsupport.seq, or NI-logger, will get lost, when the updates are necessary?  I was hoping to get away with either modifying the process model (which we have under source control), or modifying a property in memory which somehow bypasses database logging programmatically.  There do seem to be properties in existence which imply they would prevent logging, but they don't work when setting them to values other than what they were originally assigned (dicated by the report options before the run).

An no we are not using OTF for this very reason, to choose if a test run is to be logged to the database after the run. 

Is there a callback to enable that overrides this default sequence call? 

[James_Grey]

Changing a plugin is no different than changing a model, which was your previous approach. Both are installed by TestStand, but both can be replaced either in their install locations or by copies under <TestStand Public Directory>\...

Yes, it is too late to disable a plug-in with the Enabled property after the options callbacks are done. Technically, you could remove any database plugins from the arrays under ModelPluginConfiguration.RuntimeVariables.RunOrders at a later point, but that is probably more effort than is needed.

If you are hoping to get away from modifying the model, where do you want to put your modification?  How about overidding the LogToDatabase in <TestStand Public Directory>\Components\Callbacks\Station\StationCallbacks.seq? That would be easiest. Just make sure your override calls the default logger (which a default override will) when you aren't trying to disable logging.

[david_jenkinson]

I actually would prefer it if I could get away with just modifying the process model, since we already have it in source control and therefore I can easily replicate the change to our 14 test stations.  I have the teststand config directory changed in station options/preferences to something under our source control directory, so teststand looks for the process model, typepallettes, stationglobals.ini, etc etc in that directory.  But modelsupport.seq does not reside there, teststand still expects it to be under it's installation directory.  I was saying I'd rather avoid modifying modelsupport.seq, which seems to have a new version with every diskset installed.  But I had forgetten about the <TestStand Public Directory>\..., and the ability to copy files there.  When you say "override", do you mean that when you copy files to this adjacent public directory, it get executed instead of the default one?  Is there another override method?  Thanks for the insight

[James_Grey]

ModelSupport.seq, it is just a sequence file the model sequence files call. The model sequence files call it with only the base file name, so it must be findable in the search paths. Other than that, I don't know of any location requirement that TestStand places on it. However, I wasn't suggesting any modifications to ModelSupport.seq.

If you copy <TestStand Installation Directory>\Components\Models\ModelPlugins\NI_DatabaseLogger.seq to <TestStand Public Directory>\Components\Models\ModelPlugins\NI_DatabaseLogger.seq. Your copy will be used instead of the original.

However, perhaps you should first try my other suggestion of overriding LogToDatabase within <TestStand Public Directory>\Components\Callbacks\Station\StationCallbacks.seq. This copy of StationCallbacks.seq is an empty placeholder file intended for you to modify. Your modifications to it will not be replaced if you patch or repair your installation.

[david_jenkinson]

Yes I'll definitely try that.  It makes me wish I could change the default location of <Testsstand Public Directory>, in the same way I can change the config directory via station options, to something that I can put under our existing source control tree so I can easily replicate the change to other stations.  If not I can create another workspace, just a little more messy that I'd hoped (from a source control perspective).  But yes, that does appear to be the intended way to alter the behavior in the way that I want.  I'll give it a shot.

Thanks

David J.

[RyanWright]

You can change the default location of the TestStand Public Directory by adding a registry value called CustomPublicLocation to the Windows registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\TestStand\<version number>.  The data associated with the CustomPublicLocation registry value should be the path of the new TestStand Public location.