06-02-2019 09:43 AM - edited 06-02-2019 09:43 AM
What is the recommended best practice for adding a static tag mapping to a dynamic module? For example, say you're developing a dynamic module for alarming that checks any configurable list of parameters against a limit and then sets a single boolean output tag based on those states. The dynamic example shows how to set up mapping for the tags to check and the limits. How should the static boolean tag be added to the configuration? I've made a few dynamic modules that do this type of thing and I've tried it a few ways - like adding a string input on a config UI tab - but I haven't found an implementation that I like for doing it.
I'll see if I can make up a generic example, and I'll add it to the post to clarify what I'm talking about.
06-03-2019 03:50 AM
I've also played around with a few different ways of doing this, and also struggled to find a neat approach.
Attached is an example of what I think the best approach is on the simplest module I could find. It takes dynamic boolean channels that are named, and reduces them down to a string "command".This was written just for testing purposes, for a project where I had command strings passed from the HMI to the DCAF controller, and various modules processed that, but for testing I used the attached module with buttons on a local UI. There's other examples I've got possibly, but this one was the smallest and simplest.
From a config point of view, it just involved defining a "Static Tags" vi, and appending that to the channel list. I found that defining these static tags in the serialized config was unnecessary as the mapping is stored with the engine config not the module - except in the case that the user should be allowed to set a default value (If that's required I'll find a module I've written that does that).
In the runtime, it's as you would expect with performing lookups on the static tags and storing indices.
In the editor, I used the existing tag selection menu and got it to appear on button press. This required a bit more code than you might expect, and it's not all in the same place. There was a message handling VI I had to define and run in parallel, as well as the callback for the static VIs. I only really got this sussed after spending a lot of time developing dynamic modules and spending a lot of time working on the dynamic table they use and defining custom columns (that's where most of that code comes from).