Custom Model Plugin for non Result Processing Functionality

[BarJea]

I have some functionality I wish to add to TestStand as a Process Model Plugin.  However, the functionality is related to how serial numbers are configured and parsed to extract UUT metadata and nothing to do with result processing.

Is it acceptable/recommended to create plugins that are not result processing specific?

I started by creating this plugin following the instructions here, which tell you how to make a plugin operate as part of the result processing - which means configuration info etc is held in 'ResultProcessing.cfg' and the config dialog I created for it is only accessible via the 'Result Processing' dialog.  I had this working successfully, but it just feels wrong that I am having to go into the result processing dialog to access functionality that is unrelated.

I have therefore been trying to create a separate model plugin to perform the Serial number formatting task.  Unfortunately there seems to be very little information about exactly how to do this.  I am finding snippets of information here and there but no definitive direction.

So far I have created a configuration entry point in my PM (which adds an item to the config menu) and can call my config dialog with a sequence call to my plugin sequence 'Model Plugin - Configure Standard Options'.  I realise that if a cfg file exists in the correct location, that modelsuport.seq will process it and the model plugin specific options become available in parameters - for use by the process model (more specifically the 'Model Plugin - pre UUT' sequence).  The bit I am really stuck on is how to create the cfg file in the first place (from the plugin options that my config dialog modifies) and I am certain there are other things that I am missing / need to consider - one of which is the purpose of 'category' (this plugin shouldn't have the 'result processing' category I am sure).

I am using TestStand 2017 and LabVIEW 2017.

Any information / links, words of wisdom would be most appreciated.

- Barry

[~jiggawax~]

Here's my 2 cents:

I use model plugins all the time for non-result things.  It's nice because the framework is already set up for you.  I don't get hung up on the result processing name.  It is annoying but who cares.

The configuration entry point is not a bad way to go about it.  What are you doing with the data they configure?  Do you need it at any point during your execution?  One thing to look at is the property object read and write methods.  As long as you store all of your data in a variable you can use those methods to store them off to an INI file in the config directory for TestStand.  Then when you need them use the read method to bring them into memory.  I've used this in the past and it works well.  One caveat is if the datatype changes you have to do a little tweaking.

Hope this helps,

[BarJea]

Hi,

Thank you for taking the time to reply.

After some discussion with NI and other TestStand users (as well as reviewing your reply) I reverted to implementing my plugins inside the result processing plugin framework.  It seems a shame that NI have not simplified, or at least communicated, how to make plugins work outside of this process as it is clearly possible.  I did actually use the language files to change the name in the config menu (and the result processing dialog title) to something more generic, which made me feel a little better 

Sharing data created by the plugins was one of the big implementation problems I was having and I did have some success creating custom config files using the property object read and write functions, but like I said I ultimately reverted to using the result processing dialog...

Cheers,

B

[SreeRanjaniSG]

 Hi Barry,

I am having a similar requirement. It will be helpful if you can let me know how you changed the configuration menu option and result processing dialog box name.

Thanks,

Sree

[kent.wedeking]

I'm late to the party but came here to say this is exactly what I wanted to here.  We have lots of functionality that would be best served as plugins.  Thanks for the good words.