• Not Answered

How to make a "dynamic" Simulate selection on the Detail Faceplate

This question concerns the AI blocks and PID blocks 

One situation, we have control modules that contain the JUST the PID block (For example 9-PIC-101) and then the AI block feeds the PID block from a separate module (9-PI-101 for example)

the other situation is, We have control modules that contain both the PID block and the AI block. (for example 9-PIC-101 contains an AI block and a PID block)

The main problem with these two different standards is that the Detail Faceplate does not quite work for every situation. Our goal is to simulate at the Source; The AI Block not the PID block 

Since there are thousands of modules that all look at the same generic PID detail faceplate it would be more efficient to edit that faceplate to have a visibility that looks at if there is an AI block present. If the block is present then show the Simulate enable/ disable, if not then don't show it. I am not sure how to make this happen or what Emerson generated parameter exists to display if something exists. I've tried using Watchit and it shows a value of 60 when a parameter is not present but I cant get the visibility expert to work on that value. 

Has anyone tried this before or have an idea on how to make this possible? 

3 Replies

  • There are likely several ways to handle this. Without getting into a debate about whether the AI block should be in a separate module, the architecture of DeltaV modules is based on having the AI, PID and AO in the same module. This follows the rules for FF where devices must be on the same segment in order to be scheduled and executed in sequence. Within the DeltaV Module, we have the Block_Error, Mstatus and MError parameters that will monitor and roll up a status if any block is in Simulate. When the control loop is split across two or more modules, we lose some of the built in tracking of the loop and function blocks.

    By having a combination of implementations, you get the added challenge of having to address two or more scenarios. We can't use the Block_Error Simulate active in the PID module when the AI block is in a different module. But if we were to create a "fake" AI block in the PID class that links to a separate AI module, we could name it AI1 and add an external reference parameter called Simulate and point it to the AI Module. Now when the AI module is in simulate, the PID module would report that to the PID detail. you could also add a Simulate_IN parameter pointing to the AI module's AI/SIMULATE _IN. That would allow you to use the same Detail faceplate and show the Simulate status of the AI block .

    The down side is you would have to download this new "block" to those PID modules with remote AI. But it would have minimal loading as it does nothing.

    In Operate, we have the extension [CONFIG_NOT_OK], or something like that to ignore issues if the parameter is not present. The Detail display would be able to suppress errors when opening, and you could hide the simulate information or point to the PID block, but what you want is to reflect that the PID loop is in simulate since the AI block in the other module is in simulate.

    In some libraries, a Pseudo AI block was used to allow the PV to come from a different module, but I'm not a fan as this composite would eat up 5 or 10 times the CPU of an native AI block because it had every feature of an AI block. You don't need that. You could make a light version that plays no role in the data path, and only has the two simulation parameter references to satisfy the Detail Display.

    If you have a Simulate Alarm, that should remain in the module with the simulated block. No need to set simulate alarm on the PID module as that is not where the simulation is happening.

    Another approach:
    Now if you were to read the $REF path of the External Reference to the AI module that feeds your PID loop, the display could have a script to extract the module name and AI block path, append the right parameters and dynamically point to the source AI block, theoretically. If the AI/simulate does not exist, look for the "input.$ref" and define the path of a variable. The Detail faceplate would find "AI_MODULE/AI1/SIMULTE" and be able to display in the PID Module detail. That might get you a solution with no downloads to modules. Maybe have two groups with data links and hide the one that does not apply. Hmm. what do you think?

    Andre Dicaire

  • In reply to Andre Dicaire:

    Andre,

    Thanks again for the great information. I think for simplicity sake and the amount of modules this will affect, extracting the external reference on your last recommendation would work best.

    So from what I'm understanding... the best way to do this would have two identical simulate groups. One that would look at @MOD@/AI1/SIMULATE etc if the AI block lives in the same module as the PID block. The other one looks for the "input.$ref" and load that to Input.$ref/AI1/Simulate etc.

    The part I'm not sure about is how to write the script to extract that external reference and how to write a visibility script that looks for an existing AI on both the groups.

    Where would i find some resources to help me develop this script? is it Ifix Automation BOL?

    Thanks,
    Shamusk
  • In reply to Shamusk:

    Architecting a working solution is a lot more work.  This reminds me of a UPS commercial where consultants tell the client all sorts of things the client can do to improve his business.  Client says "Great, let's get started".  Consultants say "well... we don't actually "do" all those things we said, you should call UPS".  It's funny, though maybe not for the client...

    I've not done this.  But I would start with two test modules that represent how your classes are linked.  Then, in a test Detail display, I would create some Datalinks and display variables that can show all the data I need to read and act upon.  Using the [NOT_CONFIG_OK} extension, you should be able to create one detail assigned to both modules.  You want to confirm the AI block references do not cause any messages on the module without the AI, and vice versa.

    Use a data link to the $Ref field.  This will give you the syntax of the string and from there you can figure out how to extract the Module name and such.  Does the reference point directly to the AI block or is there an interim parameter wired from the AI1/OUT.  What can you use here to create the link to the AI block.  Once you figure out the correct how to create the correct paths, you need to read these values.  

    I'm thinking you can use a pair of Variables to represent the SIMULATE.ENAB and SIMULATE.VALUE.  Based on whether you can read the Input $REF value you can set the variables to point to the $ref module reference, or to the current module that has the AI block in it.  

    The logic is basic:

    IF AI1Block exists, set variables to AI1/SIMULATE paths. else

    If INPUT.$ref exists, then set variables to $REFModule/AI1/SIMULATE

    END.

    The OPerate Configure HELP books on line discusses the available datalink modifiers.  Note that to access this, you need to have a Display Open:

    From Help, select "DeltaV Operate Picture Help", and select Help Topics.  

    There you will find [_I_QUALITY_] and {_NOT_CONFIG_OK_]  

    Use I_QUALITY to determine the structure of the Module (Does it have AI block or External Reference).  I would check both incase there are outlier modules with neither structure as expected.

    Point the Variables to the required locations and make them visible.  

    Either you are using the Current Module name or you use the Module name from the $ref to define the path for the variables.  You should first prove you can get the data via the variables by hard coding them and referencing them.  Then you know the structure will work and all that is left is to make the variable paths dynamic when the Detail display opens.

    Hope this is useful.

    Andre Dicaire