We are trying to develop a module library here at our plant that we can use across the plant site in separate Delta V systems. Years ago, a module template library was developed for our plant site with this same purpose (module classes were not an option at this time). The problem is that over time, the templates were no longer used when creating new modules as modules were copied from another module that was close to what was needing to be developed. As small changes were made to these modules, the further and further away things got away from the original templates. Now I am tasked with coming back to try to implement a standard library again. I do not want to worry about what is already implemented in the system now, I only want to be consistent moving forward and bringing some of the older stuff up to date over time. I don't want the same issue that happened with the first library to happen to us this go around. I am looking for users out there that have opinions on class based modules vs module templates and if anyone out there has tried creating a module library and if it has been a success or not.
I have done a little research and testing with the two and it seems like using module classes may not be a bad idea. If a common type of module was made class based (lets say analog input module for monitoring with alarms) and the necessary parameters to configure the AI block, alarms, and history were exposed for configuration, then a module could be created with everything that was not exposed being what we want to keep standard (error / status masking for example). Another positive to this is that an older module that was not consistent with the linked parameters in the class based module could be converted to the class and all of the exposed parameters would stay the same while the linked parameters would replace the non-standard values that were there. One disadvantage I have noticed is that if text is used in the control modules for notes / modification logs, when a class is created I haven't been able to expose this text for configuration which means the text that is in the class module can not be configured for each instance. The other thing is of course if for some reason there is something unique that has to be done with a class based module instance then the instance has to be unlinked to do this. This will prevent this module from receiving future updates to the module class which is a big advantage of using classes. The good thing is that these abnormal cases are few and far between. Another positive is if a module is copied from a class based module it will be a member of that same class.
Module templates seem to have all of the same traits except that everything is configurable once an instance is created (no unlinking is needed) and because of this, changes made to the template are not made to the instances. This also means that we can potentially go down the same road that we went down before by getting further and further away from the template with no easy way to make a change to all of the instances to bring them back to standard.
In reply to István Orbán:
If you just want an area to enter basic info/notes etc, then I would add a parameter - type string and expose it. That way you can put whatever you want and edit it as you want. This works for a basic heading or notes. But if you want to change the developer notes that are placed around the modules for clarity, the only way I have done it is, to utilize place holders in the class module templates. Then do an export, edit the placeholder & re-import it. Not ideal by any means, but it is a method.
In reply to dsturg:
Andre Dicaire
In reply to Andre Dicaire: