Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel

Custom Inherited Fields

EcoStruxure Geo SCADA Expert Forum

Find out how SCADA systems and networks, like EcoStruxure Geo SCADA Expert, help industrial organizations maintaining efficiency, processing data for smarter decision making with IoT, RTU and PLC devices.

Lt. Commander
Lt. Commander

Custom Inherited Fields

I was playing around with Geo SCADA today and trying to figure out a good way to create inherited fields such as default view link/alarm view link, but there doesn't appear to be a good way to do it.  Has anybody implemented something like this in the past?


My use case here is to create something like an area of interest, but at a group level instead of a point level and where it would also inherit from parent if not explicitly configured on a point.  Regions could potentially be used here, but the issue is that things in these "groups" might not always fall into the explicit geographic region.  I kicked around the idea of just setting a fake location that falls into a region, but if there ever was a case for configuring lat/long down the road then this would no longer be valid or apply. 


What would be ideal is if AOI could be configured at a group level, but it doesn't appear to be possible.  I'm debating creating a link/reference field and creating some logic to populate this nightly, but wasn't sure if there was another way or something that I'm missing. 


Side-note and unrelated -- there should be a label for Metadata when submitting a forum post. 

Tags (2)
3 Replies 3

Re: Custom Inherited Fields

My understanding is that AOI only really applies to an Alarm Instance (normally based upon the configured Alarm AOI, but redirections can change this too I think).

There's not many ways I can think of doing this really.

1) via SQL.  If you have a Metadata field configured with a 'null' value defined (easy for Object References, tricky for things like integers), then you could sort by the LEN of the FullName, and have the query like:
   SELECT TOP(1) FullName, MyField
   FROM CDBObject
   WHERE MyMetaField <> {NULL} AND {MyObjectFullName} LIKE FullName || '.%'


2 Via calculation point, but you'd be limited to only having a group level reference (which would contain the Calculation point)..

   IIF(".MetadataField" <> {NULL}, ".MetadataField", "..MetadataFieldCalc")

   and this would need to be in EVERY group... so it seems horrible



It might be worth raising a feature request for what you're after.  Although it does seem quite niche.

I try to avoid using AOI.  It always seems to be a real maintenance nightmare compared to the relatively small benefits that it provides.  Better in recent versions where imports don't SPAM the AOI list with hundreds of foreign language entries... but such erroneous entries still seem to find their way into the databases.


(apparently trying to add a tag automatically posts the message... this forum software is painful)


Lead Control Systems Engineer for Alliance Automation (VIC).
All opinions are my own and do not represent the opinions or policies of my employer, or of my cat..
Tags (2)
Janeway Janeway

Re: Custom Inherited Fields

Thanks guys. Thinking aloud, what about a Metadata field which has an expression to set its value. So you have one metadata field which has an optional value, such as "SetProperty", and another based on an expression "SetPropertyInherit" which reads its value or the parent value if blank if(".SetProperty"='',"..SetProperty",".SetProperty")


You could implement as a string variable/constant now, and use a single Logic program on a daily/scheduled basis to modify it as config changes (take care only to write new values if changed).

Tags (1)
Lt. Commander
Lt. Commander

Re: Custom Inherited Fields

It sounds like what I'm asking for is not something OOB, which I kind of assumed.  I don't think this feature would be a niche feature at all though.  For the purpose of this thread, it's a topic regarding creating a "group" type field that is pushed down to all children who inherit from parent, similar to default view.  However, I think the use cases for this could be rather large if it were a configurable metadata type that could be added.


I think the route I'll end up going here is to create a search key metadata field instead.  This seems simple enough to implement with a logic program that runs periodically. 


For the purpose of this thread topic specifically, I think expressions as they work today would be more work than it's worth  I would probably go this route if it was easier to set the properties on groups throughout the system.  Right now I don't believe there's a method to do this via script (please let me know if I'm just missing it!).  I haven't looked into the API yet to see if it's possible there (I'm sure it is). 


Stop reading here if you only care about the thread and not my feature requests! lol


I think template expressions in general leave a bit to be desired.  I've raised my desires about this with support before.  Early on my assumption was that I could configure the expressions to reference properties or objects relative to the template that you set them in, but that's just not the case. I believe right now the only properties you can assume from the template level are name, fullname, and parent.  Being able to create an expression at the template level for these would allow for a lot of automatic configuration of objects and properties. 


An example would be to set the alarm source for points to relatively reference certain attributes within the template level.

"..Name" + ' << ' + "Name" + ' >> ' "..objCommDeviceName"


Example 2:  Imagine a scenario where you have a station grouped up as such:

  Run 1


  Run 2



  Valve XYZ


By setting RTU level specific properties at the device level, there would be no need to try and figure out how many parent folders you need to jump to in order to access properties from the Device folder.  These would be auto-magically pushed down and accessible using something like ".PropertyName".  Whether by inheritance or expressions, you could make this much simpler and take the guess work out.  Expressions could be set at the template and no further configuration would be required.  If you had inherited properties rather than expressions, it would have the same affect and depending on the class could be an accessible attribute on the objects themselves.  The result would be if I query a point, I can get the device level properties in the same query without the need to jump through parentgroupid->parentgroupid->______. 


I guess I'm envisioning something like dynamic bindings rather than something that has to be explicitly defined per object. 

Tags (1)