NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Process Model Plugin - communication method between plugins

Solved!
Go to solution

Hello everyone,

 

I am working on a framework for production where I will have multiple Process Model Plugins.

I am using Batch Process Model.

 

What is the advised method to share data between plugins? (One plugin will be response for MES and the other one for communicating with PLC that controls the production line).

 

Currently I plan to use StationGlobals variables but it is not the best method as it makes the data visible also in Client Sequence and is prone to be changed by Test Engineers.

 

Any advise on what would be a better method?

I have seen something that under Parameters.ModelPlugin.PluginSpecific.RunTimeVariables.PerSocket[]

I can add variables but are not visible on other plugins.

 

Thank you,

Just a TSUser

0 Kudos
Message 1 of 4
(109 Views)
Highlighted
Solution
Accepted by topic author TSUser

What kind of data do you need to share?  Is the data generated during run time or is it more static data (i.e. could come from a shared file)?

 

There are many options out there depending on what you want to do.

 

You can use TestStand Queues.  There are steps or the API.  Take your pick.

 

You can also use temporary global variables.  https://forums.ni.com/t5/Example-Code/Using-TestStand-Temporary-Globals-Engine-TemporaryGlobals/ta-p...

 

If the data is more static then you can use the options for the plugin.

 

Ultimately, you should make your plugins work independently of each other if needed.  If you don't then there is no reason not to put them in the same plugin.

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 2 of 4
(61 Views)
Highlighted

Hello Jigg,

 

Thank you for your suggestions!

I really like the idea of temporary variables !!!

 

Thank you!

Just a TSUser

0 Kudos
Message 3 of 4
(40 Views)
Highlighted

Jigg's point about keeping plugins independent is a good one, but for the sake of completeness I should mention that each plug-in entry point is passed a ModelPlugin parameter, which is the instance data for your plug-in. You can add fields or attributes either by editing the data types for your plug-in, or dynamically using the PropertyObject api.

 

Each plug-in entry point is also passed a ModelPluginConfiguration parameter, which can also have field or attributes added dynamically. In addition the Plugins sub-property in the ModelPluginConfiguration parameter contains an array with the ModelPlugin instance data for every plug-in instance. 

 

The ModelPlugIn.RuntimeVariables sub-property, or the ModelPlugIn.RuntimeVariables.PerSocket[socketIndex] property is the 'intended' location to store data that is run-time only and is not edited as part of the configuration

0 Kudos
Message 4 of 4
(37 Views)