Emerson Exchange 365

• Not Answered

DeltaV Live: (Graphics Studio) Is it possible to propagate a "Mode Indication" change within a GEM Class to all current instances?

Hello All,

It was determined that the Mode needs to always be shown on the graphic for all Controllers, Valves, & Motors. (Not just during an abnormal condition)

Using OUR MODIFIABLE "AnalogInfo" GEM as an example, under Graphics Configuration  / Extended Configuration / Mode Indication / **Change selection from (ABNORMAL TEXT to ALWAYS)**.

The change was made and saved using the GEM CLASS TOOL/ GEM CONFIGURATION DESIGNER/ MODE INDICATION / DEFAULT where it was changed to ALWAYS.

This only changed the setting for the New Instances of the GEM from the Palette and not the Existing Instances on the current graphics.  

Is there an easy way this change can be propagated out to the EXISTING INSTANCES?

Steven Cox

• 13 Jul 2022 2:16 PM
• Cancel

2 Replies

• Matt Stoner

  

  • 13 Jul 2022 3:52 PM

  You would have to manually change each GEM instance or export the displays, modify the file (which is an XML format so use something like Notepad++), change the appropriate values, save and re-import and overwrite with the modified XML file.

  In the below snaps you will see a section of the XML for a display where you can see the correlation to the GEM configuration options. I'm not sure how your GEM you are using is built but this will show you most likely how to figure out what you need to change your export values to.

  

  Just be very careful and you can mess up the XML and it may not import or may import and mess things up. Suggest keeping the original export and creating an updated one to import so you have a backup if you choose this method!

  • Cancel
• Andre Dicaire

  

  • 13 Jul 2022 6:03 PM

  In reply to Matt Stoner:

  Hmm. The Class based linked GEMs should allow for a modification of a GEM to propagate to the instances. However, there may be overrides present that prevent the underlying default settings to be used. It depends on how the GEM's are designed how things propagate from the classes.
  
  If you've exposed the SubGem property and set it in the host GEM based on an instance specific property, I'm thinking the instances have an override that maintains the explicit setting of each instance.
  
  Managing system wide behavior would typically be done based on a Standard or a Function. This allows for a system wide change in behavior. I'm thinking a "DefaultModeIndication" standard could be used to configure the AnalogInfo property tot he Standard, or to an explicit choice. All instances explicitly defined would not follow this Standard. Later, when you change the value of the Standard, you effect all instances that follow the Standard.
  
  A Function is like a dynamic Standard. You could have some conditions that dynamically set the property. The function could use the Standard as the default, but use some thing else to alter behavior. Maybe not for this, but that's how I think of Functions. Linking functions to standards allows you to still manage the runtime behavior through the Standards, and therefore have the Functions responsive to Themes or Language, depending on the data types.
  
  The benefit of a Standard or Function is that you can modify them and publish them to effect the runtime system. They don't flag the Displays as you are not modifying any GEM, just their behavior. When you modify the GEM, you flag every instance on every display and they all have to be published. Saving the modified GEM can take more time, while modifying a Standard or Function is a one off change.
  
  It's a trade off, but if you make things instance dependent, the system wants to maintain instance behavior. If you want to manage things globally, don't expose the setting as a property in the Sub Gem. Then if you change it in the GEM, there would be no overrides in the instances. If you set them to a Standard, you can easily manage system wide, and any instances that don't use the Standard will remain as defined.

  Andre Dicaire

  • Cancel