As you know, CSLS has limitation on creating maximum 16 SIS modules and only module names are searchable through DeltaV Live not Function Blocks.
In my case, Operation team is looking for a way to search SIS AI, DI, DO tags (function blocks or at least LSAVTR or LSDVTR) via HMI. Any solution?
Let us build success,
- Bryce H. Elliott, P.E.
In reply to Bryce Elliott:
In reply to Tadeu Batista:
Zohaib. Just to be clear, the SIS Modules are not necessarily created as individual SIFs. One SIS module can hold multiple SIF's. You can build the system with each SIF in its own module, but you will be limited to 16 SIS modules in the CSLS. With Up to 48 Outputs you might have applications with more than 16 SIFs in a Logic solver, and that would be resolved with multiple SIFs per SIS Module.
earlier versions of DeltaV SIS did not have the Alarm Group feature, and the solution was to build shadow modules in the SZ (or M-series) controller to abstract the LSAI and LSDI blocks to the DCS with a dedicated "module Tag" and associated alarms. So although the SIS Module data was available to the consoles and trends, everything was relative to the SIS module name. The Shadow tags allowed each LSAI block to be treated as an independent AI Module.
Alarm Groups were added, I think in v13, to provide this signal granularity and avoid the need for the Shadow Modules, as Tadeu explains. Since a SIF can include multiple AI blocks, the Alarm Group may not necessarily represent the SIF. It is intended to bring clarity to alarms and display the related AI to the operator.
The Alarm Groups will be searchable in the Live Search tool like all other modules.
Bryce brings up a good point. I've created an SIS Module with a single SIF with three LSAI blocks and associated Alarm blocks. These must all be named uniquely in the SIS Module. I then created three Alarm Groups each with an LSAI and an LSALM block assigned to the Alarm Group. I have assigned the same FP and DT displays and have a display GEM for my LSAI blocks.
After Download, the OPC Watchit browser shows only the Alarm Group tags with no subordinate references or alarms:
However, the Watchit utility and OPC Watchit both return a value for PI-101A/LSAI1/OUT.CV
Live Search now finds there three Alarm Groups:
But since my FP and DT displays are built around LSAI1 and LSALM1ALM, they only work with the PI-101A. Also, the GEM for displaying an LSAI will only work with the PI-101A.
I admit I've never used this feature before. So I don't know what I am missing here. It may be that we need to create a number of items, such as an AI_LSAI1_FP, AI_LSAI3_FP and associated DT and GEMs that will work with various block names. Not sure. I guess for the GEM, we can specify the FB name, and add logic to adjust Alarm name information to create a flexible GEM that works with various blocks. SImilarly, an FP could be made to read the suffix and adjust block name references to the appropriate block. I don't know. Or maybe there is an alias table for the Alarm Groups that I did not find.
Anyone have any insight on this? Or are we still using Shadow modules in the SZ controller so all the LSAI alarm Groups are abstracted to a common structure that uses one set of FP, DT and GEMs. (or Dynamos)?
In reply to Andre Dicaire:
Andre Dicaire (ADicaire)
If you create an Alarm Group, an namely differently from the LSFB you have in the Control Module,
Then you will have them as two separate entities within the Control Module, and is is how the OPC client will see them.
But if the Alarm Group name matches the LSFB, in this case a Composite LSFB, or in the case of the request, it could be the case for a single LSAI:
Then the OPC client will find all the objects inside the same entity.
When an alarm is created within the Control Module, using a parameter from an FB associated to an Alarm Group, the alarm will be automatically associated to the Alarm Group, if there's no association, the Alarm Group column stays blank, and that particular alarm will be associated with the Control Module.
One thing that is not clear to me, is why the suggestion for using the LSALM FB?
Tadeu, Thanks for the response. The OPC item was a lost leader. It was an observation that naming the Alarm Group a unique tag does not result in a browsable path, but as I indicated, the Tag and contained blocks do work if you enter the path explicitly.
I see that in your AG configuration dialog, there are Block/Param assignments. So I created an Embedded block and added the LSAI1 block to this embedded block. I named this embedded block PI-101A and defined an Alarm Group by the same name:
Now I have a browsable path to three separate LDAI1 blocks that fit the expected references in my FP, DT, and GEM designs, which all reference LSAI1.
There are two key design requirements here for the Alarm Group to replace the Shadow module behavior:
WIth the LSAI1 inside the Embdded block called PI-101A, and the Alarm Group also named PI-101A, there are two valid paths to the LSAI1 parameters:
AG_TEST/PI-101A/LSAI1/PV.CV (SIS Module path to the Embedded Block called PI-101A)
PI-101A/LSAI1/PV.CV ( Alarm Group Path, but only because Alarm Group has same name as Embedded Block)
There is still one issue though. If I have three Alarm Groups for three pressure signals, and I want to create three Low Pressure alarms, these cannot have the same Alarm Name in the SIS module. I added the LS1ALM block to the PI-101A Embedded Block and Assigned the Alarm in the SIS module. I also have to Assign the LSALM block to the Alarm Group to have the alarm linked to that group. If I had created an boolean alarm parameter in the embedded block, and linked an alarm to that, it would have automatically been part of the Alarm Group of the Block.
So if we add alarms, they must still be uniquely named at the SIS module level. They can be assigned to the Alarm Group by making sure their Parameter field links to a block that is explicitly assigned to the Alarm Group. But since the Alarm names must be unique per module, this will break typical Detail Display alarm references, but the FP alarm summary will work fine. GEM's could have Custom Alarm Names to allow the GEM to link to the right Alarm.
Does that sum it up correctly. I could not find these details in BOL. If it is documented, could some one please point the rest of us in the right direction.
As for why I had the LSALM block, i wanted to add a low alarm and the LSAI does not have alarm assignments. Using the LSALM allows a Limit Parameter to be associated with the Alarm as a field, which makes the limit accessible through the Alarm Path. It is also available via the LSALM block path. I had the LSAI and LSALM at the root level of the SIS module not knowing they must be in a composite or embedded block to create the familiar Tag/FB/PV.CV path structure.
In reply to Zohaib Jahan:
This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.
User Groups |
World Areas |
Community Guidelines |
Legal Information |
Contact Community Manager
Website translation provided by
© 2015-2022 Emerson Global Users Exchange. All rights reserved.