Emerson Exchange 365

• Not Answered

Making a Composite block with simulate option

I want to make composite block of soft AI, but how can I make the internal simulate  enable option and value as we have in other delta v blocks, because in some libraries this option is available and this parameter in the parameter list of modules shows its type as simulate with floating point but such type of option is not available in the parameter list, so is there any method to add this parameter , all of the internal logic for simulation is OK but how to define this parameter to activate the simulation of the particular composite block. please provide your valuable feedback. 

Thank you

Yawar Khan

• 5 Feb 2016 4:42 PM
• Cancel

13 Replies

• Andre Dicaire

  

  • 5 Feb 2016 6:39 PM

  I have to say that I am not a fan of a Soft AI block that "behaves" like a real AI block. There have been several iterations of these in configuration libraries, and what they all do is waste valuable CPU time. In my book, the Alarm block provides all you need for a Soft AI tag. It gives you the ability to "wire" in the signal, and apply alarms if needed. The extra AI block features, like L_Type, XD_SCALE, low flow cutoff, Field value percent, Block Error, Bad and abnormal active, etc. are important for field IO signals, but Soft IO tags are a significant step removed from raw signal processing. Making these "look like" a full function IO signal has been done so that the Operator Interface configuration is the same whether the IO is physical or soft. The argument is that it makes configuration easier, and additional CPU can be purchased rather having two types of dynamos or faceplates to pick from.
  
  Normally, soft AI tags come from PLC integration, where there can be a significant number of values to be represented. Having a bloated "Soft AI" composite that is 5 times the CPU load as an Alarm Block can quickly consume and limit the control capacity of a controller. This added load comes from a combination of CALC blocks and other manipulations that are combined with the Alarm Block that provides the Alarm function, as well as simply wiring the value multiple times through out the composite. A wire connection in the diagram means the CPU moves the 32 Bit float and status from block to block, which makes up part of this added CPU load.
  
  With the release of v12, soft Tags from Serial data set can now be referenced directly by an AI block without adding licensing cost. So for v12 and later systems, Soft AI tags should be a thing of the past for PLC integration. What is left are calculated values from other control modules in DeltaV. These certainly don't need all the trappings of an AI block (XD_Scale, low cutoff etc.). The Alarm Block works very well, and provides for scaling of 0-100% inputs, Block Error for BAD PV, and a reference SP for deviation alarms.
  
  The Alarm block does not give you a Simulate option. but since the signal originates from another module or is wired to the block, you can Force the IN parameter in debug mode to test/troubleshoot. Or you could add a transfer block to allow a simulated value, which could be mapped into the Detail faceplate in a similar fashion as the Simulate parameter, though with two parameter rather than SIMULATE.CV and SIMULTE.ENABLE.
  
  But I wonder why the AI block doesn't simply have the same input option as the Alarm block or PID block, that is add an IN parameter along with the IO_IN so that the AI Block can be used either for IO or wired Soft tags. Then the need for a "Soft AI" block would completely disappear.

  Andre Dicaire

  • Cancel
• Lou Heavner

  

  • 5 Feb 2016 7:22 PM

  Andre,

  I agree with you in general, but sometimes it is helpful to use Psuedo AI blocks for PredictPro when layering it on a 3^rd party DCS and bringing in values via OPC.  We have a dummy AI and a Dummy PID mainly to pass scale, status, and value in a way PredictPro requires.  Carl Sheehan first developed these dummy blocks.  I have used them.  I wonder if the Spartan APC group is still using them.  Carl and Terry Chmelyk did present them at Emerson Exchange a few years ago.

   

  • Cancel
• Rachelle McWright

  

  • 5 Feb 2016 7:27 PM

  In reply to Lou Heavner:

  Thanks for the insights, Lou. Ive added the @ symbol to tag Carl & Terry to see if they can provide some additional information on their experiences for the community. Carl Sheehan and Terry Chmelyk

  Best Regards,

  Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • Cancel
• gamella

  

  • 5 Feb 2016 10:27 PM

  In reply to Andre Dicaire:

  Another option is to replace AI block with a PID on with several specific settings :
  - Keep AI1 name for the PID block.
  - Disable CAS, RCAS and ROUT modes. Set Normal and Target mode to AUTO
  - Set Structure to P action on error, D action on PV
  - Set Rate = 0 (no derivative)
  - Set BAL_TIME=0
  
  
  In this way, graphical items for conventional AI blok will work with this one, no need to create new dynamo, FP or DT.
  As PID provides IN and IO_IN it provides flexibility in order to attach input to HW channel, a modbus register directly wired to a pure soft parameter (typically a landing module referencing PID/IN parameter)
  Scaling can be configured setting appropiate values on OUT_SCALE, IN_SCALE and then using a value in GAIN to perform scaling (OUT_HI/LO limis must be changed as well to avoid clamping the value).
  Although MAN mode is not normally used on an AI block, it will work too on this PID based version.
  Simulation works as well.
  
  NOTE: Maybe or configuring PID in BYPASS mode could work too but i've did not tested that...
  
  Regards

  • Cancel
• Andre Dicaire

  

  • 6 Feb 2016 12:07 AM

  In reply to Lou Heavner:

  There is definitely a need for a Pseudo AI, or soft Tag AIm, and unfortunately, the Alarm Block is not meeting everyone's requirements. (No simulate parameter, no OUT or MODE) And for integration of 3rd party systems, a pseudo PID would be great, rather than having to create one as a composite block.
  
  I just want to caution that wide use of Psuedo AI blocks consumes a significantly larger CPU than the Alarm or AI blocks, so use them judiciously. With v12, Serial Dataset registers can be directly referenced by AI blocks in control modules without incurring DST licensing, making it possible to avoid passing registers through a "Marshalling Module", which creates the need for Psuedo AIs. For PLC integration via Modbus, this change simplifies access to the registers and reduces CPU loading. If you don't have v12 installed, Psuedo AI's or Alarm Block are your available options (or a simple parameter).
  
  Also, in v12, an Alarm block in a module assigned to an Application station no longer requires a DST license. So maybe the Alarm Block will make a comeback for OPC tags landing in DeltaV?

  Andre Dicaire

  • Cancel
• MPHymel

  

  • 19 Jul 2018 9:17 PM

  In reply to Andre Dicaire:

  I am about begin creating a dummy PID composite to represent a PID block which is running in a third party system. It looks like they must do something similar with the FF PIDs since these are executed in a FF device. Has anyone ever come forth with the Pseudo PID mentioned earlier?
  
  I want this animal to work with our PCSD faceplates so I was going to gut an existing PID class, and stick this dummy PID in it and name it PID1. It would have all the same parameters so the various faceplate tabs wouldn't gripe about anything because of a missing parameter.
  
  From the getgo, this is hard, simply because I don't know how to make a parameter type with an option bitstring. I really don't want to figure out every think the faceplate might need, I was just going to create a parameter of the same datatype and name as a PID and put this guy in my class.
  
  I can't be the first guy who ever needed to do this. Has anyone cracked this nut elegantly?
  
  BTW, we are running Version 12.3.1 and have a 2014 era set of PCSD classes and associated dynamos and faceplates.

  • Cancel
• chip.burge

  

  • 20 Jul 2018 11:20 AM

  In reply to MPHymel:

  I've built the composite you describe for integration with a PLC that contained the PID loop in question. Probably the most efficient solution was to create the composite, wire it up and then make a list of unresolved parameters that appear within operate run when the faceplate / detail is opened. You could also search for @MOD@/PID1 within the faceplates from operate configure to generate a list of parameters before you get started.
  
  As far as replicating the bitstring options e.g. CONTROL_OPTS I don't believe that there is any way for a configuring engineer to replicate these. I believe I substituted an integer in in its place just so the datalink would resolve.
  
  Hope this helps

  • Cancel
• JoseCarias

  

  • 20 Jul 2018 11:30 AM

  From my point of view, the most efficient way will be having the pid as ROUT and map the output of the pid on the PLC back to your pid on DV. That way you will now that the control it’s taking place outside of DeltaV and at the same type you keep all the functionality of PCs
  
  

  Sent from my iPhone

  Jose​ Carias | Project Manager II

  Control Southern Inc. | 3850 Lakefield Drive | Suwanee | Georgia | 30024

  T: 770-495-3100 | M: 770-243-0619 | F: 770-623-3663

  Jose.Carias@controlsouthern.com

  Products & Services | After Hours Emergency

  Check out our website!

  www.ControlSouthern.com ​A Member of the Emerson Local Business Partner Network

  
  On Jul 20, 2018, at 7:24 AM, chip.burge <bounce-chipburge@emersonexchange365.com> wrote:
  
  

  <EmersonLogo_5F00_150x42-jpg_2D00_150x42x2-jpg> Update from Emerson Exchange 365 <4TW4WXPPNG4N-jpg_2D00_70x70x2-jpg> chip.burge I've built the composite you describe for integration with a PLC that contained the PID loop in question. Probably the most efficient solution was to create the composite, wire it up and then make a list of unresolved parameters that appear within operate run when the faceplate / detail is opened. You could also search for @MOD@/PID1 within the faceplates from operate configure to generate a list of parameters before you get started. As far as replicating the bitstring options e.g. CONTROL_OPTS I don't believe that there is any way for a configuring engineer to replicate these. I believe I substituted an integer in in its place just so the datalink would resolve. Hope this helps View online   You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here. Flag this post as spam/abuse.

  • Cancel
• MPHymel

  

  • 20 Jul 2018 12:31 PM

  In reply to chip.burge:

  Yes, I ended up making these as integers. The other issue was the various named sets that I couldn't find, I can replicate those if necessary, but as you suggested, I will only for anything the faceplate would require. Thanks for that tip on the @MOD@PID1, that will be very useful to analyze the hooks the FP is looking for.

  • Cancel
• MPHymel

  

  • 20 Jul 2018 12:33 PM

  In reply to JoseCarias:

  Jose, thanks for that advice, I hadn't considering using those parameters, but it is really the perfect solution.

  • Cancel
• Michael Krispin

  

  • 20 Jul 2018 3:33 PM

  In reply to MPHymel:

  I had developed one time a PID composite which had included most of the Top-Level functionalities of PCSD. The customer don't wanted to see all the staff around the PID and other basic function modules like Valve/AI/DOS etc. but only his own logic on top level of the CM.
  So there are ways to do that. Your case look more simple for me.
  Could you please clarify what you want to do from DeltaV? Shall this PLC/PID be fully operable from DeltaV, means want you also send SP, Mode, Tuning-Parameters down to the PLC or do you want only indicate the main points like Mode, PV, SP, OUT maybe SP- or OUT-limits in the DeltaV HMI?
  In general can say that a PID function block is very simple on PLC side (Siemens/CODESYS etc). There is no standard SP-Limit, just Gain, Reset, Rate and PV-Filter.
  The DeltaV Dynamo need only some basic parameters. The faceplate must be reduced to that what you really active use. The mode must be calculated to adapt into the mode parameter by a calc-block in your composite. The rest are then external references where you must take care if you want read and write down from/to the PLC.
  Anyway, your question, someone had must this before is a good one. I program both worlds and often thought about a low budget system which combines PLCs and DeltaV for small plants where a full DCS would be a bit oversized :-) . Plant-Web 250DST or the new PK10 where an option for that. It would be helpful to have such shadow block for basic functions in a standard library
  Best Regards
  Michael

  • Cancel
• MPHymel

  

  • 20 Jul 2018 4:12 PM

  In reply to Michael Krispin:

  I was trying to redevelop an existing strategy, the existing was overly complicated and we will be modifying some of that. It is rare that we ever implement a PID in a subsystem, in fact, I believe only 4 exists at our facility. We have to have code executing to have the DV OUT track the read back PLC output when the dV module is in AUTO, and also write the SP signal when in AUTO, but when in MAN, code needs to have the SP track the PV, and the PLC logic is then outputting the dV OUT and internally tracking it, as well as performing its own SP tracking.
  
  The original method left us with persistent bad statuses which we visible on the various dynamos. I was hoping to not have to chop up any PCSD faceplate or dynamos, just have a class that manipulated the IO as we needed and played well with the graphical elements by having any parameters that were necessary. I suspect that we would manually set some internal status values before it was all said and done, but in the end we'd a have a streamlined template to follow for any future applications.
  
  I recall Yokogawa actually had a function block that was made to do just this, granted it still took a bit to set it up correctly, and since their system is more of a canned package, there was less potential for different "flavors" of the core module and graphical elements.

  • Cancel
• Andre Dicaire

  

  • 4 Jan 2021 4:45 PM

  In reply to Lou Heavner:

  Lou, Some how came across this post. The suggestion to add an "IN" parameter to the AI block is to allow it to do exactly what you use the Dummy AI for. The native AI block consumes less than 20% of the CPU as those dummy AI blocks that are "full Featured". They were created to fill the void, that is an AI without an IN parameter. Using an ALM block accomplishes the same thing but does not map to all AI Faceplate and detail display parameters. There are different ways to solve this, but none would beat having native support for parameter references in the AI block.
  
  Happy new years...

  Andre Dicaire

  • Cancel