Programmatically (de)activate a ModelPlugin

[CyGa]

Hi,

Is there an API call that I can use to (de)activate a model plugin ?

The idea is to do the same thing as (un)checking the 'Enabled' box in the Result Processing window.

[Mr._Jim]

Hi CyGa,

I don't know of a "nice" way of doing it, but here is how I've done it in the past:

Locals.configuration = Nothing
,Locals.configurationFilePath = "C:\\ProgramData\\National Instruments\\TestStand 2021 (64-bit)\\Cfg\\ModelPlugins\\ResultProcessing.cfg"
,Locals.configuration = RunState.Engine.ReadPropertyObjectFile( Locals.configurationFilePath, False,ConflictHandler_Error,0)
,Locals.configuration->Data.ModelPluginConfigurationSet.Configurations["<Default for Inline Processing>"].Plugins[0].Base.Enabled = True
,Locals.configuration.AsPropertyObjectFile.WriteFile( WriteFileFormat_Current )

Then call the ReadModelPluginConfiguration method of modelsupport2.dll

I've attached a sequence file (2021) that should do what you want.

I don't remember anymore how I figured out which method to call. I'm pretty sure I looked at the source code:

"C:\Program Files\National Instruments\TestStand 2021\Components\Models\TestStandModels\modelsupport2\ResultProcessing.c"

As long as you do this up front while nothing is loaded, it does work. I don't run the attached code verbatim, but something pretty similar.

If NI has a better way to accomplish this, I would love to know.

Good luck!

Mr. Jim

[CyGa]

Hi Mr Jim !

Thanks ! I noticed that the setting was stored in the cfg file indeed.

I should have said before that I don't want this to be done from TS but from LV (TS UI).

I can still call the modelsuport dll from LV of course, but I'd prefer a standard API call.

[Mr._Jim]

Hmm... I wish I knew of a way to do it cleanly from the API.

If someone else knows, we'll both learn something new. I spent a long time trying to figure it out and finally just called the DLL.

[CyGa · Accepted solution]

To follow up, I had a reply from NI's support :

We don't think there is a TestSTand API Method that can enable or disable Model plugins. That is done by the Process Model's Results Processing Configuration Entry Point, which throws a configuration dialog box and persists the settings in the ResultsProcessing.cfg file.
With that said, I think you could implement a Model Plugin Configuration Switcher routine. Here are the steps to follow:

1. Create different Result Processing Configurations and switch between them programmatically using the ModelOptions Model Callback in the StationCallbacks.seq file.

1.  

1. You can add a statement step to change the Parameters.ModelPluginConfigurationToLoad string parameter.
2. You can add preconditions for this statement so it runs only if X condition is met.

Here is an example:

Another option would be creating a Model Pluing Add-On and having some script to add or remove the Model Plugin sequence file from the Add-Ons folder. Honestly, the first option seems better to me, but I'm also commenting about this one just in case. 

[Mr._Jim]

That's fascinating. It's a pretty creative solution, and though I've used the ModelOptions callback plenty of times in client sequences, I can't believe I've never noticed that parameter. Most people don't think to call model callbacks from the station callbacks file as it's a bit counterintuitive. Now I know of at least one use for that feature.

While I enjoy TestStand hacking, it would be nice if we didn't have to get so creative in solutions, though.

Digressing into addons... So that's what that directory is for. I've been running my own plugins for years and I always wondered what the Addons directory was used for. I guess I should have searched. 🙄 There aren't that many mentions of it in the help reference.

I'm going to move my model customizations into addons now!

This is pretty useful information - thanks for sharing it!

[CyGa]

You're welcome !
Addons are basically model plugins that always execute.

You can't uncheck them nor even see them into the Result Processing... wizard window.

I'd completmy avoid station callback in my case since it forces the whole station to behave only in one way.

Things should be kept at project level, not station level IMO.

According to me, it is a shame that something that is configurable is not exposed in the API.

Having to call modelsupport dll or hack things to make it work is not really acceptable.

TestStand is an engine ! The Sequence Editor is a UI ! Here the settings are coupled with the UI... 😞

[Mr._Jim]

---

I'd completely avoid station callback in my case since it forces the whole station to behave only in one way.

Things should be kept at project level, not station level IMO.

I couldn't agree more. Things with über-global universal scope tend to cause more headaches in the long run.

According to me, it is a shame that something that is configurable is not exposed in the API.

Having to call modelsupport dll or hack things to make it work is not really acceptable.

TestStand is an engine ! The Sequence Editor is a UI ! Here the settings are coupled with the UI... 😞

---

Preach on. 😎

Every time I run into something like this I think, "Come on, this really can't be this complicated..."

I'd put it in the Idea Exchange if there weren't so many cobwebs gathering over there.