I ran into a case last week where there was a module, that contained a module block ref, that contained another module block. Besides being a major "no-no pet-peeve" of mine, I feel that it goofs up the scan rate and/or execution order of the modules a bit. Does anyone know for sure what happens in this case? Can anyone elaborate on the "shared" and "private" options when using this feature?
Hi,
What do you mean by "it goofs up the scan rate of the modules a bit"?
Being 'Shared' or 'Private' module blocks should not affect the scan rates for the module execution. For both cases, if the scan rates of higher level modules are faster than the lower level ones, then the data update rate on higher level modules may be delayed.
This can be also depending on the execution order of the modules, if the scan rates are same for both level modules. You can define this order by "block execution sequence" inside the module (only possible for multiple blocks at the same level. i.e.: not possible to define sequence for SUB_MOD1 & SUB_SUB_MOD1).
Please read the topic "Controller Performance" in the BOL for more details.
Also read topic "Function Blocks - General Information", last section on the page for "Block Scan Rate".
Hope this will clarify your doubts.
Regards,
Amod.
In reply to amodbobade:
Thanks for the topic suggestions, hopefully they will help clarify my question.
The "controller performace" topic you listed says the following about execution order:
"Only the execution order of blocks within modules is set. So, the user does not control the order of execution of modules with the same scan rate. Modules that interact with other modules having the same scan rate could effectively be delayed 1 scan in terms of acting on information from another module. This might lead the configuration engineer to scan all interacting modules at twice the required scan rate"
And from the "Function Blocks - General Information" topic:
" The block scan rate indicates the number of times the module's algorithm is executed compared to the block. For example, if the block scan rate is one, there is a 1:1 ratio. Every time the module scans, the block executes. If the block scan rate is 3, there is a 1:3 ratio and the block is executed every third scan."
So my comment about "goofing up the scan rate" is in regards to these two things. Which wins? If my embeded module has a scan rate of 1 second and the containing module also has a 1 second scan rate, does it execute only when that "module block" is scanned in the containing module? Or does it scan at 1 second intervals on it's own, and then execute again when that block selected to execute based on execution order? Does the module only scan the one time and you may be getting data that is a scan old? Can't this potientially delay your data by a scan? How does the controller actually deal with these module block references at run-time?
In reply to Maarten van der Waal:
In regards to the module block ownership, I found the answers I was looking for by looking up the topic "Ownership Types for Module Blocks." In testing it appears that "Private" means the module is actually embeded in the containing module. When it's "Shared" it's just a reference, in which case the module is actually at the same level as the containing module. Is that my difference for how execution order is determined?
Thanks to you both for the quick reply!
In reply to Tyler Anderson:
Just want to clarify a couple of points. First, module execution order is not based on Alphabetical module names. During a total download, modules are downloaded in alphebetical order, but the controller scheduler balances modules over execution time slices, so that all modules execute at their configured scan rate. If 20 modules with a scan rate of 1 second are downloaded, the scheduler will assign one module to each time slice, spread out over one second. The 21st module will be assigned to the first time slice with the 1st module, etc. If you download 20 modules with a 100 ms execution rate, each module executes 10 times per second, so you would find have the modules in one time slice and the other in the next. As the modules arrive (in alphebetical order), the scheduler balances these time slices to get the same number of modules in each time slice. So execution order is not something you control by naming modules in alphabetical order.
As for Embedded Module blocks, these provide access to the referenced modules, but in now way affect the execution of those modules. When the Embedded block "executes" within the host module, it reads data from the referenced module. The data resides in the referenced module memory space.
As for writes to the embedded module block this is done in two ways: Typically, a value is wired to an exposed parameter on the Embedded block, say "CAS_IN". This parameter is configured in the referenced module as a "Floating Point with Status". This is for convenience in configuration. The Parameter is created in the module and the module is referenced with an Embedded Module block, and the parameter shows up as a connection point. HOwever, at Run Time, DeltaV optimizes this to be a read by the referenced module. The CAS_IN parameter becomes an External Read parameter with the path set to the source of the wired connection. Why? Because using a read allows this module to be in a remote controller and Unsolicited reads bring the CAS_IN value to that location. When the modules are in the same controller, the module reads the CAS_IN Source value from the Embedded block host module at the time it needs it.
If the Host module uses an expression to write to the Embedded Block CAS_IN connection, the parameter will not be changed to an external read and the Write will be made when the host module executes the write. This is fine if both modules are in the same controller. IF the destination module is moved to another controller, these write will still work, but should be done by exception, and should be avoided. If this is a continuous write (ie a cascad Master to Slave loop) you should use the wired connection and let DeltaV perform the execption reporting between the nodes.
Both these methods behave very similar in runtime. If you read the slave loop's "CAS_IN Parameter, the controller redirects you to the source parameter memory location, so you get the value you expect, except it comes from the source, not the destination. If you write with an expression, the CAS_IN will hold the value written, and if you read this parameter, you get the same value. In both cases, if you read the BLock/CAS_IN value in the slave loop, it will not hold the new value until that module executes and the transfer of the wired connection is made.
The Ownership level determines whether the block can be embedded in multiple modules or whether it is deditcated to a single "Master", as in the case of a typical Cascade loop. You can still make references to a Slave loop that is owned by a master, but you cannot embed the module as a block if it is owned by another module. This avoids wiring up the same parameter in two or more modules.
The Embedded Module Block is provided to aid in visuallizing a complex strategy using the upper level module, and seeing how data is moved between the modules by the master module. For instance, a lead/Lag controller of Fuel and Air flows controlled by the Boiler master. The BG Station provides the SEt point for both fuel and Air, but cross limiting is applied so that Aire leads fuel on increase and lags fuel on decrease. This lead lag logic can be done in the master BG loop, and connection to the two Flow loops done with embedded module blocks. Alterhantively, the cross limiting could be done inside each of the two flow loops, but you would not be able to "Tune" this behavior along with the excess air curve, in the master BG module. One might argue that doing the cross limiting in the BG module adds delay between the two flow loops, but in reality, this is inconsequential to the header pressure loop that drives the BG, and the dominant lag in that loop.
So, to recap, Embedded Module Blocks have no effect on module execution rates or order of exectuion. Order of execution is not controlled by configuration, other than to use different scan rates where appropriate, such as a faster scan rate on the flow loop of a cascade Level control. The Master will be slower due to its overall time constant.
Andre Dicaire
In reply to gamella:
I would say forget the Embedded Block when thinking about module execution. It has no effect on the modules referenced by the Embedded module blocks. The "container" modules has its own execution scan rate, as do the two modules refernced by embedded blocks. When each module executes, it executes its function blocks in their configured scan order. When the embedded Module block is "executed", it reads the values from the refeferenced module, nothing more. Now these values are in the container module and if wired to other blockes, those blocks will use these values. The read data comes from the source module memory locations and are what ever that module set them to the last time it ran.
In your example, Block A would read data from its module and expose that value in the output connector. neither Module A or B are not executing at this time. Next, Embedded block B will read data from module B. Assuming the output connectors are wired in the container module to other blocks, the data from the embedded modules moves to those blocks and they execute using data from the referenced modules A and B. The container block finishes. At some point Module A executes, reading the wired input data source defined in the Container. Module B then executes and does the same, based on their configured execution scan rate and completely independent of each other and the container module.
Typically, the data read into the container module is manipulated in some way, (high/low select, characterisation, etc.). It would be unusual to see the output of one Embedded module block wired directly to the input of a second Embedded Module block. Why not make this connection directly between the two modules? I think that container module will first retrieve the value and the second module will read from the container, placing the container module between the first and second module, adding latency in the tranfer of data. But I'm not sure. I'd suggest a test. Create a container module that runs every 10 seconds. Insert two embedded blocks, one that has a 1 second counter or ramp and the wire this to a Floating point parmaeter in the second module. If the value passes through the Container, you'll see a step like change every 10 seconds in the second module. If DeltaV changes the Floating point to a reference directly to the first module, you'll see the ramp in both modules.
In reply to Andre Dicaire:
Answered my own question. Configured two slave modules into a Master module. I cross connected the slaves to each other, but on one connection I added a SUM block to force the Master module to act on the parameter, and have the Embedded module read from the ADD1/OUT parameter. The Master module runs at 10 Sec execution and the two slaves at 1 sec.
The direct link updates in the destination every second, while the ADD1/OUT link updates every 10 seconds. This confirms that when wiring to an embedded block input connector, DeltaV changes the Embedded module to read the source value. If the source value is another embedded module, the link is defined to get the value directly from the source, bypassing the container module. Excellent....
I looked in the download script for the embedded modules and sure enough, the source path is explicitly defined to read from the source, and in this case, the other embedded module.
This has an interesting implication. If you change the configuration in the Master Module by changing the source of a wired connection, you actually have to download the embedded module for this change to take effect. In my case, I deleted one wired connect to insert a Summer block located in the master module. This changed the wired link from the embedded module source to the Master/ADD1/OUT path. I downloaded the master module, but the embedded module still retrieved its value from the original source. Only after I downloaded the Embedded module did the link update and start reading from the ADD1/OUT source.
So the important point here is that if you use a Master module to link data between two embedded modules, if the links are direct, they will execute as reads directly between the modules and are not delayed by the master. Links made to the master module parameters will as expected, require the master module to execute for these values to update. Remember to download the embedded modules if you make changes to the links that write to these modules.
h with a signal generator at a 60 second sine wave(Bias of 50 and ammplitude of 50). Wired the output to an Ouptut Parameter so it would show up as an output connector in the Embedded module block. Added a Floating point input parameter in each of these blocks. Then created a Master module and embedded these two modules and cross connected the inputs and outputs. I set the master module to a 10 second execution and the two slaves to 1 second exectuion.
Surprise. Both slaves see the data every second, though the Master module executes every 10 seconds. This confirms that the inputs are reconfigured to point to the source data, which is in the other slave.
Hi Gamella,
Even if this is better & exciting new visual way to implement control strategies; Please remember the negative points involved as well.
The controller loading increases due to need of the 'container' module. The time taken to execute this module is irregular, based on scan rates of the embedded modules. If number of module blocks are more, then the module execution time may exceed recommended values, & the execution is split into 2 cycles to accomodate asynchronus tasks in between, effectively degrading the total loop performance.
Also, the container module execution rate has to be slow, so any graphic updates done through this module are slow. We generally use this concept to create 'equipment modules', "Ignore" feature is very general to be used with EQM design. But looking at the configuration & loading requirements, for simple cascades, this becomes an overkill.
BOL topic "Function Blocks - General Information" says:
"Use this feature for cascade control. For example, combine the two loops required for cascade control into one module, as long as the scan rate for the outer loop is a multiple of the scan rate for the inner loop."
Hi Andre,
Interresting findings. Thanks for the tests & sharing the results.
Amodbobade. The Embedded blocks are simply visualizations of data from the referenced modules. This does not create "Irregular" execution. The module loading of a container module is minimal as the referenced modules are NOT part of the container module execution.
As for using this to "visualize" control strategies, I don't think a container module should be created to manage data transfer between modules. The intent of this is to allow dependent modules to be visible within the "upper" or "Outer" module strategy such as a CASCADE loop. If you simply used a container module to connect references between embedded modules, you would be editing the container to define links, but need to remember to download both the container and the embedded modules as the wired connections to the Embedded block inputs require a download to that module for the link to be defined.
So a Cascade Master/Slave makes sense, with the outer loop running slower than the inner loop. The "level" controller is the primary control while the "Flow" loop is used to improve the level control by providing a volumetric control input to the tank rather than a valve position. Boiler cross limiting control via the Boiler Master module makes sense as the cross limiting is on the SP signal to the Flow loops, and this is in the Header pressure control which is a relatively slower loop. The cross limiting logic is a combination of multiple signals, which would also include an excess Air curve. You would be able to "Tune" the boiler from this module.
So like any tool, using it correctly is beneficial. Now that you have a new hammer, try not to look at everything as if it is a nail...
Tyler, When a module is Private, it appears in Explorer underneath he module it is "embedded" in, but it remains an independent module with its own execution schedule. The module will only be embedded in that one module and the data links are optimized to always read. When the module type is shared, the module will be at the same level in the Explorer tree. You can then embed that module in multiple modules. Care must be taken that you don't attempt to write to the same parameter from two differnent container modules.
For a Cascade loop, you would use Private as the Slave loop should only be associated directly with the Master loop. Because the slave loop is under the Master loop in the Explorer tree, you can download the Master and any subordinate modules from Explorer in one download request, ensuring any changes in links are made to both the container and embedded module.
In either case, the embedded module executes on its own schedule.
I spoke with a customer today and he had a boiler master module, which had several embedded control loop modules (Fuel flow, air flow, O2 trim). By wiring the Boiler Master signal to these three loops in the master module, and implementing the cross limiting logic in the master module, the overall boiler control can be visualized. THe master module should not be involved in the closed loop execution of the embedded blocks, but provide the supervisory setpoints and cross limiting signals, which provide the boiler master control. Like a cascade loop, the slave loop makes the master loop more effective, but the slave loop works independently for closed loop execution of the PID.
So remember that embedded modules are not scheduled by the master module. The execution order on the embedded block has no bearing on the execution of the module itself. The embedded block simply allows for visualization of the embedded module in context of the broader host module strategy, facilitating transfer of parameter data via wired connections. the Embedded modules should not rely on the master module for execution of closed loop control.
There is also a KBA related to this with some explanations: AP-0800-0077