Emerson Exchange 365

Control Module Class External Reference to Unit Module Alias

I'm trying to create a new internal read parameter configured as an External Reference.  This control module class is instantiated inside a unit module class.   The intent is to connect the external reference inside the control module class to an alias inside the unit module.   In the example below the "RUN_ID" parameter is referenced to unit alias path "Unit/Unit_Parameter.field"  e.g. "UnitName/Batch_ID.CV".  Another example of where this is used on our site is, "Unit/Unit_Parameter.field"  e.g. "UnitName"   This alias is used to determine the unit's name for unit relative logic.  i.e. logic that only executes for specific units.

This practice has been used successfully in the past on a DeltaV version 13.3.2 system.  However, now that we are on version 14.3.1 LTS, we are getting the following error when trying to create new parameters similar to above or even editing the existing parameters as shown above.

 If we set the external path to an alias/parameter the error goes away.     e.g.  #B_ID#/Parameter 

This unfortunately breaks for us when we attempt resolve the unit name only.  Is this case we need an alias to be referenced to the Unit module only, not a unit module/parameter. Is there are better way to reference a control module's or unit module's name?

Wes Urbat

• 11 Oct 2022 6:22 PM
• Cancel

8 Replies

• István Orbán

  

  • 12 Oct 2022 6:55 AM

  Try #B_ID#/B_ID

  • Cancel
• Wes Urbat

  

  • 12 Oct 2022 2:36 PM

  In reply to István Orbán:

  Thanks Istvan, It worked!

  

  My foundational understanding of how alias' works has been shaken.  Can you help me understand why this works?  This alias is literally referenced to the root path of my unit module   i.e.  path =  O-SIM.  I would expect the "UNIT_NAME" internal read parameter in my control module to resolve a unit parameter "O-SIM/UNIT_NAME".   However, there is no unit parameter defined in the O-SIM unit called "UNIT_NAME" only and alias called "UNIT_NAME".

  I appreciate you help.

  • Cancel
• István Orbán

  

  • 13 Oct 2022 11:12 AM

  In reply to Wes Urbat:

  As far as I know, it's not a documented feature, but I've seen it used widely in the past 10 years, various DeltaV versions.

  • Cancel
• Matt Forbis

  

  • 13 Oct 2022 1:55 PM

  In reply to Wes Urbat:

  The reason is works is because every alias also behaves like a parameter under the unit as well. So, Aliases with the # around them do a string substitution in the reference, then you still have to reference a parameter underneath that. Aliases in a unit have two fields. The first is CV which is the string of the alias, the second is IGN which you can use to determine whether an alias is ignored.
  
  Two examples of common usage. First, customized messaging where you phase can reference #THISUNIT#/CW_VLV.CV to get the module name of a valve. The second is in a confirm statement you might wait for the valve to be open or it's ignored, ('//#CW_VLV#/PV_D.CV' = '_VLVNC_PV:OPEN') OR ('//#THISUNIT#/CW_VLV.IGN' = TRUE).

  • Cancel
• gamella

  

  • 13 Oct 2022 2:40 PM

  In reply to István Orbán:

  Implicitly it is documented, but not clear in my opinion.
  Inside Books online => Batch => Batch Reference => Understanding equipment configuration => Unit Classes => Unit Modules => Resolving aliases with unit modules section you may find next sentence :
  "With the implementation of dynamic alias resolution for class-based modules (similar to unit phases), you can modify the alias path without downloading all class-based modules referencing the modified alias. You need only download the unit module that contains modified alias. "
  So, implicitly it is saying that non phase class based modules can use Alias.
  
  Note that there are some restrictions/limitations, in example "Alias Resolution Table can only be resolved if that control module or equipment module resides on the same controller to which the unit module is assigned".

  • Cancel
• Wes Urbat

  

  • 14 Oct 2022 1:50 PM

  In reply to Matt Forbis:

  Matt,
  
  Thank you for the detailed explanation, this makes a lot of sense. If not for your explanation I was going to blindly rationalize alias' like parameters at the root level of my unit. I'm glad my thought process wasn't too far off. I seriously appreciate you taking the time to respond.

  • Cancel
• Wes Urbat

  

  • 14 Oct 2022 2:02 PM

  In reply to gamella:

  Gamella,
  
  Thank you for providing the reference within Books Online. Also appreciate you highlighting the limitations of non phase class based module alias limitations. I recently modified an alias path within one of my units and wasn't sure what the extent of the download impacts would be.
  
  Based on what you're saying the alias resolution table (memory register pointer table?) appears to be a loaded to a controller and accessed real-time as a logic is execute? I was originally thinking it may have been a table that was used to resolve references only when logic was first complied and downloaded to a controller. Based on my original assumption I was expecting to have to download other impacted modules. Please correct me if I've misinterpreted your explanation.

  • Cancel
• gamella

  

  • 17 Oct 2022 7:51 AM

  In reply to Wes Urbat:

  As written into books online, " you can modify the alias path without downloading all class-based modules referencing the modified alias. You need only download the unit module that contains modified alias. ".
  However, I would recomend to perform "Download Setup Data" on controllers containing involved UNIT(s), EQM(s) or Control Modules(s) after an structural change.
  Also will recomend checking Bach Executive on batch enabled application station for "blue Triangle". If blue triangle it is present on Batch Executive but any assigned recipe has the blue triangle and Batch Executive=>Download Delete Unused Recipe configuration option says "There are no recipes configured for this Batch Executive that are not used" then Batch Executive=>Download Equipment should be performed.

  • Cancel