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?
Andre Dicaire
In reply to Andre Dicaire:
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.