Emerson Exchange 365

• Not Answered

Reference search doesn't return every result

When modifying a control module I have carried out a reference search and it returned the results of several other control modules where that particular control module is referenced as expected.

However I happened to know that particular control module was referenced within an expression in an ACT block which is directly in same equipment module as the control module I was carrying out the reference search for.

This particular reference was not listed when I searched the control module for references.

Is there some constraint on the reference search that means it won't return references from expressions in function blocks residing directly in the same equipment module as the control module you are doing the reference search for? 

Many thanks

Adrian

AdrianTaylorUK

• 1 Aug 2018 2:06 PM
• Cancel

5 Replies

• Michael Krispin

  

  • 1 Aug 2018 3:27 PM

  Hi Adrian, I think if you embed that control module into the EM, then the link count as internal reference. I'm not a friend of embedded control modules, because that produce more load than a shadow block composite and references only to the real used parameters from inside the composite down to the control module.
  The old school way of searching internal references is to search in the export file for the module block name, or more brutal - change the embedded module to an empty one and make a verify of the EM. In both cases you can find the internal references. Not easy, but quick and dirty.
  Best Regards, Michael

  • Cancel
• Andre Dicaire

  

  • 1 Aug 2018 6:59 PM

  In reply to Michael Krispin:

  The terms "embedded Control Module" or "embedded module" do not exist in DeltaV Books On Line. The module block is a data base structure that allows you to show interaction of two modules in the graphical layout of Control Studio. Instead of building explicit external reference parameters into a module, you can "expose" the parameters of another module and then wiring to these connection points. The module referenced can be private or shared. Private is preferred if the referenced module is in closed loop control, such as in a Cascade Loop. Shared modules typically are used to provide input referencesto the host module.
  
  At Runtime, DeltaV converts the wired connections to references so the logic either reads or Writes data as needed. In the case of a Private module, the wired connection from the PID1/OUT to the FIC-101/CAS_IN connection is actually downloaded as an external reference in the CAS_IN parameter, changing it from a Floating point with status you see in Control Studio to //PIC-100/ PID1/OUT. And the BKCAL IN read from FIC-101/BKCAL_OUT. This ensures exception reporting of parameters is used instead of explicit writes, in case the modules are in different controllers.
  
  Saying that "embedded Control Modules...produce more load that shadow block composites" does not make sense to me. The composite block approach requires explicit movement of data within the host module to the composite block parameters and then to the destination module parameter, and that requires CPU and memory. Not a lot. And it also creates Redundancy data update loading.
  
  The Module Block has no load. The module it references does. Using a Module Block creates a download that minimizes the interim steps (parameters) used to move data, so it gives better CPU and uses less memory, since the module exists no matter how you reference it.

  Andre Dicaire

  • Cancel
• Michael Krispin

  

  • 2 Aug 2018 12:54 PM

  In reply to Andre Dicaire:

  Hi Andre, you are right, the correct name is a module block, sorry for the confusion. But I think it was clear what I meant.
  However, the load comes from the huge amount of useless parameter as input or output parameter in a typical PCSD control module which all need to execute to transfer the data in the main module, because they are visible in the main module and can be called i.e. also from a graphic or other CM, so they must all update. I talk for example about an approach for a bigger EM with roughly 60 actor/sensor modules. BTW even Emerson had done improvements by using shadow block composite for Sub-EM (~20 State-driven) used in an Command driven EM as Main in my actual project here.
  If you check this how it looks, you can see a lot of parameters, which are mostly not used in a normal approach by the main module.
  The Module Block do not use CPU load, but the composite nut shell too, do not have CPU load. Only the references must be executed in both in the same way. If your CM by design would be a dynamic reference maybe for OWNER and BATCH_ID, you even would not need to connect your EM/BATCH_ID to each of the valve module blocks, which also take load for the inner module data transfer, but the sub CM read direct from the EM/BATCH_ID source parameter.
  I can tell you that I have done improvement on CPU load by using standardized composites as shadow block with only a few parameter references, i.e. REQ_SP, REQ_MODE, PV_D, FAILURE etc. for a valve. It reduce massive the amount of data to be transferred. Such parameter are external reference to and from the real CM i.e. a Valve-module. To make the engineering easier I used also dynamic references. The module block need load in the same way as the composite to transfer the data up/down to the main module. Sure - not for the function blocks from the control module itself.
  The CM of course execute by it self in his own task as the main module or even in another controller.
  That at download do change sub CM input parameter with fixed variable structure to an external reference as read from the EM/Modul Block interface is good to reduce writes over the CM. Especially if the sub CM is in another controller. But that is also the reason why you must do always downloads on both modules.
  Especially the example to put two PID module block as master/slave, maybe even an extra AI and AO and connect them on top level in the main module is on another reason better not to use module block. First a control- loop should be for my opinion in one CM including AI and AO. The PID is a fully AI, and the AO don't need an own control module because it usually is in CAS and can be fully controlled from the PID/OUT in what ever mode.
  If you use only for a normal loop with 3 individual CM for AI/PID/AO, it can end in a longer signal response, because we can't determine the execution of the CM.
  The order look for us as AI->PID->AO , but it could be also AI->AO->PID within 1 sec. This would need 2 cycles and might change with the next download on one of the CM. How you want tune such approach? If all IO are in one CM then you will always have the fixed execution by the function blocks from AI through PID to AO.
  With this in mind, put now the Master controller in our game and let the slave connect direct his CAS_IN to the OUT of the master. If this Master also have the (FF) AI and PID FB in the same CM, You will have two CM in the same task instead of 5 single CM. So after the CM is before the CM it doesn't matter, but both execute in 1 sec. From the Master-AI to the Slave-AO, you have a fixed signal response of max 1 second.
  Finally now put this all as module block in an EM and connect them all on top level of the EM. Do you get it slowly? How often must the data go up and down through the EM which itself execute also only one time per second, same as the other CM. So in best case you get your PV into the Master-PID. The OUT will transferred up to the EM go through this to the Slave-PID/CAS_IN, execute here and send its OUT up to the EM again to link finally to the AO Module CAS_IN. But here to keep the response within 1 sec you would need to execute the EM with 500ms which would be totally nonsense.
  How more CM and EM links you have in that queue, how more worse could become the struggle of the signal transfer through all from Master-AI to Slave AO and control-loop tuning. We can't determine the execution order of control modules. We know only that they will execute within 1 sec but not in which order. I see that sadly very often, the engineers may not consider the signal response and even the higher load of individual CM for AI/PID/AO . Alarms are double or three times generated , Mode-Look and Acquire mechanism etc pp. from typical PCSD library modules.
  
  It is similar with a Totalizer which might be used in an EM-Command SFC, wait after start of dosing on the complete signal and jump to the next step which close the valve.
  If the dosing valve will be connected with his CAS_IN direct to the Totalizer COARSE or FINE parameter then you have the same fast response between these two CM within 1 sec. To be flexible here, the Valve CAS_IN could be a dynamic reference again and the string might change from the EM before the dosing start. So one totalizer could control several solenoid valves etc. The EM should be used just as a conductor for the control modules, send Set points etc, but the control loop/dosing control itself should run direct on the lower CM level. For fast process you can set the control loop in 500ms or 200ms and let the EM on 1 sec. That is why I don't need all sensor/actor functionality brought by the interface parameter up to the EM, but only specific parameters for SP, PV, Mode, Failure and some other for general purpose.
  
  But this all is now off topic and might be better placed in an own blog for good engineering practice, pro and contra. I think it will be interesting for more people.
  Best Regards, Michael

  • Cancel
• Andre Dicaire

  

  • 3 Aug 2018 1:24 AM

  In reply to Michael Krispin:

  You are right that we have taken this discussion off topic, but now that we are here, you've brought up some very good points, but also some misconceptions. When you place a module block in a module diagram, the module block exposes all the Input/output parameters defined in the referenced module diagram. In the case of PCSD modules, this might look like a lot of excessive references, but there is no module processing happening here. In Control Studio Online, these parameters are retrieved directly from the referenced module, not through host module parameters. So it certainly looks busy with extra data displayed that you may not care about. But the host module is not moving this data at run time, as you are saying. 
  
  There are three ways to add a parameter to a module: Input Parameter, Internal Parameter ( each can be a constant, Internal Reference or an External Reference, or a Dynamic Reference), and as a property to the module (i.e not in the diagram itself). The Input or Output parameters are the ones that will always show up as a connection point when the module is referenced with a module block. So if a module has been configured with these "regular" parameters rather than the Internal parameter, Control Studio online will retrieve and show this values whether you reference them or not. Using the Internal type (has two corners trimmec at the connector) these do not show up in the Module Block, but they are identical in functionality. Also, in the host module, you can selective expose the Internal parameters.  

  This nomenclature can get confusing, but an Input Parameter can be an External Reference.  And an Internal Parameter can also be an External Reference.  The difference is in how they look in the diagram and how they appear in a module block. But they behave identically at run time.
  
  

  As for all your examples, I'm not going to try and debate your configuration choices.  My point is that the module block is a construct in DeltaV configuration designed for efficiently linking two modules.  You've provided some good reasons to not use this.  But module loading efficiency is not a shortcoming of module blocks.  Feel free to PM me to discuss further.

  Andre Dicaire

  • Cancel
• Jason.Brumfield

  

  • 8 Aug 2018 7:13 PM

  I discovered the same issue previously. KBA NK-1100-1201 discusses the finding & as of now it is an identified issue, but does not have a solution. It was originally thought to be a pre 12.3.1 issue, but was later identified as still being an issue (We run 13.3.1 same problem). I found it with embedded/linked composites that are used in our class based modules.

  • Cancel