Two pump templates with different sets of tags or one pump template and a way to hide tags not used?

[Tanquen]

Just wondering the best way to work with almost identical templates for devices but some have a subset of tags. So maybe half of your hundred pumps have a leak alarm and the other half doesn't. Do you make two pump templates so that you're not creating extra database points against your license for that leak tag that you don't need or is there a way to make one pump template and disable or hide that tag?

[AdamWoodland]

This comes down to how you structure your templates. The simple way is a flat structure and so in your case it might be best to create a second template. You can look into using abstract points in your template and converting in the instance, but this might be time consuming with too many points and too many instances.

The better way might be to have a more structured template, i.e. define templates for your blobs and create instances of those within a template. You'll still need multiple templates but by bringing in a common template for say RTUs and mimics, and then also for Pump type 1, type 2, etc it provides a very modular setup. The first time you see it it looks confusing, but as you have a common template across multiple "parent templates" maintenance becomes much easier.

For example, create templates for:

* RTU

* Displays

* Site Reports

* Pump Type A

* Pump Type B

* Pump Type C

* Valve Type A

* Valve Type B

* Valve Type C

Then create a parent template which is just a grouping of instances, and would consist of the first three always, then pick and choose from the others as necessary to build that example site. Then create a second parent template and again pick the first three, and another mix.

If you have no consistency across anything this is probably really inefficient, but if you have standards on site construction it can be really powerful especially when you're dealing with many hundreds of sites.

[BevanWeiss]

Normally we'd have a set of templates for each device type.

So you might end up with:

- Basic Pump

- Remote Control Pump

- VSD Pump

- Remote Control VSD Pump

- Wet Well - Low + High Floats

- Wet Well - Low + High Floats + Level Transmitter

- Wet Well - Level Transmitter

- RTU

Then you'd have a site (2 pump SPS) that would have two pumps a wet well and an RTU.

When you instantiate that site, you can swap the template instances between different types... so you could swap the default Basic Pump template instance out for a VSD Pump, or a Remote Control VSD Pump.

Maybe this site has a level transmitter, so you swap out the Wet Well - Low + High Floats with a Wet Well - Low + High Floats + Level Transmitter.

If you have 100 different kinds of pump versions in your field code / wiring... well that's a lower level standardisation problem, and Geo SCADA Expert isn't a magician... it won't solve all your problems, you need to solve some yourself.

For minor variations, then having an Abstract Point is the cleanest approach.  But it does add a point licence, even when not used (which I personally hate... but I don't see that licence aspect changing).

If licencing is a problem, and the abstract points would break the camel's back, then you can dummy in the animations, and use an IIF(EXISTS(..), ..., ...) kind of thing in every animation expression.  But it's a bit horrible.

You do have to be a little mindful of the nesting depth with templates however.  Each level of template nesting does cost a bit in regards to template propagation lock times... So try not to go too deep with template nesting (this is something I struggle with).

[MarkPitout]

Sounds like a feature request for future Geo SCADA releases: Templates with optional components that can be enabled/disabled per instance. And preferably, points in disabled portions of an instance, should not be counted in the point count for the license.

In Ecostruxure Process Expert (formerly Hybrid DCS), the templates are constructed this way - you have one template with potentially all the features you may need, but the features can be enabled/disabled on instances as required. Features that are disabled, simply don't get generated in the final PLC and SCADA code and tags. So for example, the "Motor" template caters for several types of motor starters - simple DOL, 2-speed, forward/reverse, with or without field start/stop stations. etc. etc. It would have been a nightmare to have distinct templates for each kind of motor starter.   

Coming back to Geo SCADA - I don't have anything to add to what Adam and Bevan advised. In the end it becomes a balancing act of managing the complexity of the templates, vs reducing the number of different templates you have.

[BevanWeiss]

I'm not sure the concept of 'disabling' points in a template instance makes much sense for Geo SCADA Expert.

For example, if I have an animation that is:

("Point 1" + "Point 2" + "Point 2") / ("Point 1" + "Point 2")

And I disabled "Point 2", what does this animation mean?  does it become entirely invalid, does "Point 2" get replaced with 0?

How does this kind of situation work in Ecostruxure Process Expert?

The one thing I would like to see in Geo SCADA is the ability to 'extend' templates.

So Template 1 has:

* Point 1

* Point 2

Then I could have Template 2 which 'extends' Template 1, and adds a Point 3.  This means Template 2 has

* Point 1

* Point 2

* Point 3

Animations etc already in Template 1 would still apply to Template 2 (unless Property Overridden and changed)

[MarkPitout]

You make a good point. 

In Process Expert, it is very possible to create a template where, if a specific tag is not generated, then the resulting graphics animations would produce an error. Template design and testing can be a very complex affair in Process Expert. Sometimes script in the background is required, to first determine the existence of a tag, before considering it in the calculation of animations (similar to IIF(EXIST,...). Added to that the developers of Process Expert have a very tough task producing template libraries that are suitable for all scenarios and for all customers. (one of the reasons why there are specialized libraries for Mining, Water, Food and Bev. etc.)

Something that Geo SCADA has got going for it, is the simplicity of making templates. For Process Expert there exists a full three day course just focused on creating and modifying templates, because it is not a straight forward process.

I think your suggestion of extending templates is perhaps a better route, as it would give some more flexibility, without making the process of creating and modifying templates overly complex. I wonder if the concept of template extension is achievable, without creating the same performance implications that come with deeply nested templates.  eg. Template10 extends Template9, which extends Template8, which extends... etc. etc.