Recent Control & Safety Systems Discussions
Similar Posts
Referencing and EM Class Module Block Binding
User Defined Import - Bind Class Based Module Blocks at Instance
VB Accessing Module Name
Import warning for module with DCC block with custom named sets
Accessing Module Tags in Referenced Modules
Share
  • Not Answered

Accessing module block binding module name

Hi,

Query  -

             

               1. A module block is bounded to some physical module

               2. We want to access name of this module bounded to DEV1 in logic.  

Explored:- 1. Looked for a parameter in DEV1 for this purpose, but didn't found any.

               2. Looked for FMT, it used MODULE_BLOCK_BINDING.MNAME. Tried using this field in ACT block but parse errors.

                 

Is there anyway to do this ??

Thankyou 

Devpriy sahu

15 Replies

  • gamella
    This cannot be done, MODULE_BLOCK_BINDING.MNAME is only present into deltav configuration space and it is not available on run-time (controller).

    If bound module name is required into any logic, I see two options:
    1- Use Unit Class Aliases. This is what deltav nativelly offers to identify bound modules but it's provided into batch unit layer and not into EQM layer. Batch licenses required to use this (license for all implemented batch unit instances).
    2- Add a parameter, i.e. MODULENAME, into any control module to set module name in configuration time. DEV1/MODULENAME will contain this parameter value in run-time. Watch-out for controller metrics, as doing this will increase controller memory consumption.

    NOTE: This points out that MODULE BLOCKS inside EQM should be used only into internal logic of EQM. Using EQM 'instance A' bound module name into EQM 'instance B' logic seems not to be something directly supported by deltav.
  • Devpriy sahu

    In reply to gamella:

    Hi Thanks for your response ;-

    1. Yes through Alias we can do that but actually that is not possible to be created at EM level.

    2. This would be additional configuration step. So if i have 10 devices then if i create 10 parameters, configure them with device tag, still i won't be able to use those parameter through ACT block to bound module blocks (....I THINK SO). I need to do additional task of binding module block manually.

    3. I am going to use module name into in logic of same EM. Basically i am looking to select 1 device out of those 16 through some logic and then want to store tag of selected device into a string parameter which would be accessed by some other module to command that particular device.
  • gamella

    In reply to Devpriy sahu:

    For option 3 maybe you can use 'meaningful' names on module blocks rather than DEV1, DEV2, etc..
    In this way it will be easier to manage code. I've seen similar approach using DEVxx making very hard to read code, specially online.
  • Devpriy sahu

    In reply to gamella:

    Ya agreed, generic name are really confusing....btw thanks for your replies  

  • Matt Stoner

    In reply to Devpriy sahu:

    Gamella was indicating to put the item under a Batch Unit and then the logic within this item could use the Aliases of the Batch Unit it was under.

    Another option not given is you could add String parameters for the associated Module Blocks that you configure the associated Tags for that device and this could be used by the logic locally instead of having to read the parameter(s) from a control module that might even be in another controller (Examples being DEV1_TAG or BTM_VLV_TAG parameter and have FV24101 configured at the instance _BT_IN_M1_A_TK1).

    I don't understand what you are trying to do for item #3. You are selecting equipment in this configuration (how is the selection made?) but then allowing other logic to write to it? Seems you either should have the selection and control be done in this configured item or do the selection where ever the control is being done from. I would think that would be hard to troubleshoot if I'm understanding what you are wanting to do.
  • Devpriy sahu

    In reply to Matt Stoner:

    I share exact logic and then we will discuss on it :-

    1. We need to take a material into an vessel from one of the 16 possible source tanks.

    2. An EM is developed (With 16 module blocks for 16 tank discharge valves). It will receive source tank name from Phase and based on which it will and store tag name of selected valve into an parameter
    (This is what i want...To store this tag name...at present we need to do configuration in 2 steps...bind all 16 valve manually to valve module block and other 16 string parameters to store valve tags......if say DEV1 is selected then a code will move that tag from string parameter corresponding to DEV1 to selected valve tag parameter)

    3. Once Valve name is stored, phase will map path to SP PV MODE of that particular valve using dynamic referencing and operate valve as per requirement.

    I under stand this could be done through Alias also but then also you need to bind Alias with selected valve tag. To read selected valve tag we require to read binding module name of module block And this is the issue.....!! How to do it without having a extra configuration step of putting string parameter ... how can we directly move binding name of a module block to some parameter.

    And to your points -

    --- Batch Unit and then the logic within this item could use the Aliases of the Batch Unit it was under.

    Item is already inside a unit module, i can make an alias but suppose if DEV1 module block got selected then how will i move tag name bounded to DEV1 into alia

    --- Another option not given is you could add String parameters for the associated Module Blocks that you configure the associated Tags for that device and this could be used by the logic locally instead of having to read the parameter(s) from a control module that might even be in another controller (Examples being DEV1_TAG or BTM_VLV_TAG parameter and have FV24101 configured at the instance _BT_IN_M1_A_TK1).

    Doing same at present but it consume a extra configuration step and a bit of extra code to be developed 

    --- I don't understand what you are trying to do for item #3. You are selecting equipment in this configuration (how is the selection made?) but then allowing other logic to write to it? Seems you either should have the selection and control be done in this configured item or do the selection where ever the control is being done from. I would think that would be hard to troubleshoot if I'm understanding what you are wanting to do.

    I explained about exact application 

    Thanks :-)

  • Matt Stoner

    In reply to Devpriy sahu:

    I still don't know the purpose of the EM if it is only setting a string on which valve to use...EMs are typically used to make manual operations easier and I'm unsure of how it does in your instance.

    Not knowing your system but this would appear to also only allow a single source tank to be used at a time which would be limiting if you ever need to add multiple sources at the same time. I would suggest making the Source Tanks have EMs or individual EMs per Source and then have the Phase drive the appropriate EM and the EM would open the valves to the destination allowing multiple additions at the same time if this requirement is ever needed. If you continue this way I think it will be a big re-design to change how the system works to do more than one at a time.

    Finding where logic is opening one of these valves that is being driven with dynamic references from the phase would be pretty hard to troubleshoot for someone that didn't design/implement this. You would get references that the EM uses a valve but that would be it. The EM if driven by an alias wouldn't be shown as a reference in the phase logic. If you have a direct reference to the EM then will show up but typically people are using aliases for reuse of the phase.

    Just some things to consider...
  • Devpriy sahu

    In reply to Matt Stoner:

    Problem is already resolved........ but i am trying to know if there is any other more efficient way possible. This efficient way require to read and store tag name of module, bounded to module block.

    ----I still don't know the purpose of the EM if it is only setting a string on which valve to use...EMs are typically used to make manual operations easier and I'm unsure of how it does in your instance.

    1. Here we got 48 source tank to get 3 types of material into the vessel. Now each route (Source to destination) contain 2 valves and a pump.
    2. There are total 9 such EMs (3 for valve 1, 3 for valve 2 and 3 for pump as each EM supports max 16 devices).
    3. A master EM receives route ID from Phase.
    4. Based on some selection logic master EM triggers 3 salve EMs (1 for valve 1, 1 for valve 2, 1 for pump) and provide them route ID
    5. Slave EM will then put corresponding device into CAS and start/open them.
    6. Slave EM will also store dynamic path to SP PV and failure parameter of corresponding device.
    7. Master EM will map its parameter dynamically to these parameters as discussed in point 6
    8. To these parameters of master EM, phase map its parameter.
    9.Now SP PV ALARM in phase are accessed as per requirement.

    But notice
    Suppose i want to supply selected valve1 valve2 and pump tag to the phase. how will i do that ? i can't read DEV1 tag in salve EM
    To do this i had written a bit of extra logic. I want to avoid this extra logic ....!!!

    ---- Not knowing your system but this would appear to also only allow a single source tank to be used at a time which would be limiting if you ever need to add multiple sources at the same time. I would suggest making the Source Tanks have EMs or individual EMs per Source and then have the Phase drive the appropriate EM and the EM would open the valves to the destination allowing multiple additions at the same time if this requirement is ever needed. If you continue this way I think it will be a big re-design to change how the system works to do more than one at a time

    Sounds good but redesign is really not an option as of now.


    ----- Finding where logic is opening one of these valves that is being driven with dynamic references from the phase would be pretty hard to troubleshoot for someone that didn't design/implement this. You would get references that the EM uses a valve but that would be it. The EM if driven by an alias wouldn't be shown as a reference in the phase logic. If you have a direct reference to the EM then will show up but typically people are using aliases for reuse of the phase.

    1. tracing out dynamic references is really a challenge. I do it by making creating fhx of all possible modules and then making a consolidated word file and then use find by trying all permutation and combination based on parameter name. Do you have any other strategy for this ????

    2.Since this logic is reused hence created in such a complex way using dynamic referencing.

    3. Using Aliases as you said won't help much, although to access master EM phase is using alias concept.
  • Andre Dicaire

    In reply to Matt Stoner:

    DeltaV Provides several methods to reference information from other modules, but none appear to provide what Devpriy is asking for.

    Initially, DeltaV supported the concept of a Module Block, which allowed for one module to be represented as a Function Block in another module, which allowed the Function Block diagram to graphically depict the signal flow to and from that module. This Module Block only exposes Module level parameters to the host module and does not expose the name of the referenced module.

    When Batch support was originally added to DeltaV, the concept of Aliasing was introduced, which allows Batch PHASE logic to be written with generic (alias) module names that are bound to a set of modules that define a specific Unit. By using a class based structure, we could define multiple instances of identical Units and know that a single Phase would work identically on all of them.

    External and Internal type reference parameters also existed, but could not be changed dynamically. So Dynamic References were added. By defining the $Ref attribute, to a module/parameter path, the parameter would bind to that parameter and adopt the available attributes. A user can redefine these $REF paths, and once the connection status goes to 0, now the parameter was communicating, even to remote modules in othe r controllers.

    Equipment Modules were added, which used the Embedded Module block mechanism, rather than Aliasing. Because of this, the Hosting EM is not aware at run time of the module names bound to these modules. Like a typical cascade loop with an Inner and Outer loop, the Outer loop has the Inner loop represented as a private Module Block and has access to its exposed parameters. These Modules must be defined to expose the required control data to the host EM, such as having SP or Command parameters the EM can write to. The entire EM logic can be created using only the Module Block names. As a Class object, it can be instantiated multiple times and one only has to rebind the Blocks to their new modules.

    What is missing in my opinion, is the ability for the EM to "know" what modules it is bound to. It would be nice if every module could expose its module name as a parameter. This would allow an EM to read "^/DEV1/MODULE_NAME" . Now the EM logic would be able to set a series of Dynamic References using this module name in the path. It would be able to display which modules it is currently acting on. There are many possibilities.

    the solution is to add a new String parameter to every module and set this equal to the Module's name. We also add a "FRIENDLY_NAME" parameter and point Dynamos and GEMS to the module Friendly Name rather than define it for every instance of a module in the displays. If the Friendly Name is "FROM_MODULE", the module parameter is used. Otherwise, the user can enter a custom string for Friendly name.

    Adding these parameters will require a download of all the modules, or at least all the modules that need this. It would then be fairly easy to create Bulk edit format and data files that will programmatically update all these new parameter names to their respective module. For a module called MTR-1001, create the data file in excel suing the Module name to define the MODULE_NAME Parameter, and if you like, include the FRIENDLY_NAME parameter:
    MODULE, MODULE_NAME, FRIENDLY_NAME
    MTR-1010, MTR-10001, Main Drive
    etc

    The "MODULE_NAME" parameter will now be available from the EM module block via '^/DEV1/MODULE_NAME.CV'. You could confirm that the parameter is properly set by comparing the "^/DEV1/MODULE_NAME" string to a dynamic reference configured using the string value
    $REF:= "//MT-1001/MTR-1001". If the Dynamic reference does not bind successfully, the string is either misspelled or is incorrect.

    Now, if you rebind this EM module block to a different module, the EM will use that module's name in the relative dynamic references. If you are using DEV1, you can specify any number of Dynamic Reference parameters in addition to the Module Name. Other modules can read these dynamic reference parameters.

    By having a MODULE_NAME parameter, a host module is able to display the module name of its embedded modules with an internal or dynamic reference that is setup to read the Module Block/MODULE_NAME parameter. That eliminates data entry errors and also allows for a programmatic validation that all MODULE_NAME Parameters are correctly set. Now you're not chasing errors and know the names are correct.

    What do you think, should DeltaV add a new Parameter to every module that automatically populates with the Module's Name? Would that solve this and other problems?

    Andre Dicaire

  • gamella

    In reply to Andre Dicaire:

    I've used approach explained by Andre in a complex, from routing perspective project; added MODNAME parameter into each control module class. I think it will be useful to provide EQM the names of bound modules but cost in controller memory needs to be considered. On that application resultant free memory was lower than free cpu what is quite unusual.

    However I still think that this kind of application, massive routing required, should be implemented using deltav BATCH layer.
    On that project we found that using UNITS for raw materials (SOURCES) makes application simpler and more reliable. Using BATCH enables use of equipment trains and selection policies to select SOURCE, launch a UnitProc that validates the SOURCE and generates report parameters with name of modules required to dynamically setup route. Then another Unit Proc into DESTINATION UNIT gets those module names (refer/defer) and configures EQMs dynamical references before executing the raw material transfer.
  • Andre Dicaire

    In reply to gamella:

    Good points about resources, though that is much less of a concern in v14. Adding a couple of limited character static strings will not impact Memory loading significantly. Where strings impact memory is usually when strings are manipulated, resulting in fragmentation and over time impacting downloads. This was most common on MD and earlier controllers. MDPlus increased memory from 16MB to 48MB and MX has 96Mb. new PK controllers have increased this by more than 50 times.

    I also agree that Batch Aliasing is a better solution over a homegrown set of Dynamic references. But not every solution requires a Batch deployment. Having a MODNAME or MODULE_NAME parameter makes it possible to programmatically identify referenced Modules and to access additional parameters without explicitly exposing them as wired parameters. In a cascade pair, the slave loop name is manually entered into a module parameter so that the Master Loop's Faceplate can display and link to the slave Loop module. The MODNAME makes this automatic rather than a two step configuration process that can be in error.

    Andre Dicaire

  • Michael Krispin

    In reply to Andre Dicaire:

    Andre,
    "What do you think, should DeltaV add a new Parameter to every module that automatically populates with the Module's Name? Would that solve this and other problems?"
    My answer to your question definitely is a big YES!
    In nearly every project of my longer DeltaV experience we had to add a string parameter with this content, to use it further into the very powerful "Dynamic References". Needless to say that this is a potential copy/paste trap.
    BTW, it would help also to introduce such an system parameter for each Step in a SFC.
    Thank You,
    Michael
  • Michael Krispin

    In reply to Andre Dicaire:

    Hi Andre,
    "I also agree that Batch Aliasing is a better solution over a homegrown set of Dynamic references. "
    In principal Aliases do similar things as Dynamic References.
    There are some pros and cons of Dynamic References and Alias.
    + While Aliases can be resolved during download on a phase/CM by knowing itself of its unit,
    - dynamic references use a weaker process to establish the link, due to the mess that some server must look online for the reference how ever.

    - Both don't show a reference to other modules like an external reference in the DeltaV Explorer
    Here I see a potential of some program code in the DeltaV Explorer to solve that thing (Don't want to call it a Gap), that at least
    + Aliases could be also offline resolved. I do this in my own Access tool, when I try to find references out of expressions etc.

    -- changes on the Alias table can be downloaded only with an Unit Download. :-(
    Yes, there might be some conflict with running phases, but could it not be ignored the same way as DeltaV do with a DL on a phase while it is running ?
    ++Dynamic Reference link, used in a Phase, can be changed with a simple phase download

    Where the first points are more related to the offline DB, is the last point more what make me a pain in my biggest muscle at the back side
    Best Regards,
    Michael
  • Devpriy sahu
    1.No doubt having that MODULE_NAME parameter would be very helpful in some cases like this.

    2. Doing it with Alias

    - Suppose i created 3 Aliases (sel_vlv1,sel_vlv2,pump) for Unit - Destination_vessel.
    - To which module these Aliases to be bound could only be decided at Run time, when my phase is running on UNIT, it will exchange data with a S/W and then receive route ID and based on which selection logic as i described earlier will figure out valve & Pump modules to be selected.

    Now
    - Is it possible to bind a Alias at run time ?? (I think NO)
    - Even if i can bind, i need module name of vlv1, vlv2,pump from EM, that is exactly the issue, we cann't simply get that.


    3.One advantage of using Alias that i noticed is
    When Unit module downloaded, it will check all assigned phases by substituting values of Aliases in expression, and give unresolved path error if any.

    4. Dynamic references
    Yes very hard to trace, any strategy for this ?
  • Andre Dicaire

    In reply to Devpriy sahu:

    The Alias mechanism is intended to provide generic naming within the Unit Phase Logic and thus allow one Phase to run on many units that have the same/similar structure. If this was a header that had 16 valves and you want logic at one level to Open and Close one of the valves, but which valve is decided separately. An Equipment module could 'own' all 16 valves and is configured to take a command to Open/Close. In the EM logic, there is a second selector that is set to which valve is opened, and all others are held closed. The EM allows you to abstract the the sequence from the valve selection. There would be no Aliases or dynamic references. Since the header is a common asset, the EM can prevent multiple valves from being commanded and the content of the header is controlled.

    As for tracking dynamic References, each such parameter is explicitly manipulated by your Code. You are always in control of what you tell the reference to bind to. One thing I can think of is to follow a $REF write with a LOG Event to record that the dynamic reference has been defined, changed or cleared. You can then have a record of this in the Event Chronicle, and Sort on the attribute containing $REF. or a keyword in your message.

    This will also catch user changes to a $ref parameter if all Operator actions from all workstations are tracked. This will not catch someone that fails to include the log event when they add an $ref.

    A search of the FHX file will contain all dynamic reference parameters and there must also be at least one Assign statement in a CALC or ACTION that writes to the $REF of each of these. That will tell you where a dynamic reference is being manipulated. I'd try to keep that to one location. And there is logic that there to validate and also set the LogEvent.

    I'll add that one should try to color within the lines and avoid overuse of a feature like Dynamic Referencing. When we use it, it should be to accomplish something that cannot be done with conventional references. After we are gone, some one is left to support the system and a convoluted, unstructured, undocumented implementation of dynamic references would not be appreciated, and worse could result in down time. Keep it simple. Sometimes the dynamic reference does just that. However we choose to make use of it, be sure to document it for future understanding.

    Andre Dicaire

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.