• Not Answered

Interruption of module execution and synchronization of data

I would like to understand how the execution of a module can be interrupted, because I need to synchronize/order the flow of data between some modules.  I'm used to another system (not DeltaV) that runs each module without interruption, that is, the inputs are read, the function blocks executed and outputs sent before starting on the next module.  I know this is not the case with DeltaV.  Let's say I set up a module to read an input using an external read parameter, pass that input through a function block and write it to an output parameter.  If I have another module read those input and output parameters, it's possible that the output parameter will be a scan late.  I have seen this.  So it appears then that when a module executes, it reads inputs first, then it may be interrupted by other modules so that it's function blocks execute later, and then at some point it's outputs are written.  Can anyone explain what really happens?  I have already seen posts about how DeltaV schedules modules such that the order of module execution can not be manipulated.  This question is more about execution within one module.  When the inputs are read, does that happen all at once without interruption?  Are function blocks executed all at once in the configured order without interruption by other modules?  Are the outputs written at once with no interruption?  If an external input or output is encountered within a function block, like a CALC block, will that interrupt function block execution?

7 Replies

  • Mark, M Once a module starts execution it is not interrupted by other modules, but may be interrupted by higher priority tasks that require immediate attention. At least, that is the case with controllers previous to the PK controller. (M series and S Series) I've not heard any change to that for the PK. Module execution can be interrupted by higher priority tasks, but a module is not interrupted by another module.

    What you describe in your observation would be explained by execution order. If both modules read the same external reference and Module B also reads the result of Module A's Output result, Module B could scheduled immediately before or after Module A.

    Another thing to consider is that if you read an external reference parameter from another module, you are reading the source value not the value in the module.
    For instance, Say Module A reads a value from TEST1/OUTPUT, using a parameter called Param1. The source parameter is a counter incrementing every second. MODULEA is executing at 5 second scan rate and calculates the difference between the current scan and last scan value of PARAM1, which will typically be a value of 5.

    Module B is configured to read MODULEA/Param1 and executes every second. Module B will see the value update every second. That is, MODULE B sees the external reference path in MODULEA and reads the value directly from TEST1/OUTPUT. Even though MODULE A is executing every 5 seconds, MODULE B sees the value change very second.

    If MODULE B used the LAST VAL parameter of MODULEA, it would only see a change every five seconds.

    In fact, if you use WATCHIT to read MODULEA/PARAM1, it too will show updates every second, even though MODULEA executes every 5 seconds.

    I hope I explained that clearly enough.

    External reference parameters don't hold the value they read. They pass the value into their module, but other modules referencing the external reference parameter get the path and they read directly when they execute. That way, the source does is not dependent on the execution of one module. If you wanted to know the value that MODULEA used, then MODULEA needs to store that value and MODULE B would read that parameter, which would only update when MODULEA executes.

    Andre Dicaire

  • In reply to Andre Dicaire:

    I'll add a little bit to what Andre wrote. Module-level input parameters (not external references) are updated at the beginning of the module scan. Then each block executes in configured block order. As each block executes, it's inputs are updated, the block executes, and then the block's output parameters are updated. Internal references, like external references, do not have storage locations of their own; they are updated whenever the parameter to which it points updates. If a module-level output parameter is wired, it updates after the last block executes. E.g., if a CALC block has an output wired to OUT_PARAM and a later ACT block references OUT_PARAM, it will be referencing the value from the previous scan. If you want the ACT block to use the 'this-scan' value of the parameter, either the ACT block needs to reference the CALC block's output instead or OUT_PARAM needs to be an (unwired) internal reference to the CALC block's output.

    In the case of the value that MODULEA last used in Andre's last example, if MODULEA has that external reference parameter wired to a function block (e.g., a CALC block), MODULEA could have an internal reference to that block's input. As an internal reference, it would update only when the source parameter is updated, which would be when the CALC block executes, which happens during MODULEA's execution (i.e., the value that MODULEA last used).
  • In reply to SBPosey:

    So when you have an input or output parameter configured as an internal reference, and you read that parameter with an expression, you are reading the referenced path at its source. Like SBPosey says, configuring an OUTPUT as an internal reference to CALC/OUT1, and using an ACT expression to read OUTPUT, the expression actually reads the CALC/OUT1 value which has been updated in the module.

    What can confuse observations of module execution with external references is that the workstation also reads values from the source of the path reference. That can give the impression that one module is "interrupting" another module.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks, Andre. I didn't realize that referencing an external reference parameter refers to the source. If in MODULEA the external reference parameter is wired to an output parameter, then MODULEB could read that output parameter and know what value MODULEA had seen. Or if the external reference parameter is wired to a function block, I suppose MODULEB could read the input of that block, but that doesn't seem like the right thing to do.
  • In reply to Mark Bendele:

    This was a good topic as how data moves through Internal and External references is not discussed in depth in BOL. Thanks for bringing it up. I had investigated this decades ago, but checked it again today to make sure it worked as I expected. As for referencing the Input of a block, that is possible, and in some cases valid, but not very common I think.

    SBPosey helped me realize that using an internal reference for Output parameters could be better than wiring to them. Wired, they update at the end of block scanning and the value is stale if read by an expression in the module. With internal reference, you can use the Output parameter internally and the value returned is always fresh.

    Andre Dicaire

  • In reply to Andre Dicaire:

    In my facility, we never have a module drill down into another module's block parameters; we always have a module-level parameter for the other module to reference. This permits us to change the structure of module without impacting other modules that reference it. The same rationale is used for faceplates: faceplate displays only reference module-level parameters. This lets the same faceplate handle different types of modules. Different faceplates are needed for modules with different interfaces. E.g., a vanilla analog modules has need of PV, PV_SCALE, description, etc., but a loop needs additional parameters: SP, OUT. We do allow Detail displays to drill into block parameters since they are designed with a particular module structure in min: Need an interface into an AI block if the module has one (showing things like XD_SCALE and block's OUT_SCALE and allowing access to the block's SIMULATE attribute), but don't if the module just uses fetched values (flows based on level depletion or complex calculations).
  • In reply to SBPosey:

    Fully agree with that approach. Note it also improves higher level configuration where Module Blocks are used, EQMs and Batch, as application interface for each module it is clearly defined.