• Replies 5 replies
  • Subscribers 584 subscribers
  • Views 220 views
  • Users 0 members are here
Options
Related

Long Alarm Filters

Matthew

Hi.

The citect help files state:

If a requested filter is too complex (for example, it contains too many conditions or too many nested brackets), the filter is cleared (no filter is used). The hardware alarm "Too many alarms in filters" is generated on the client components, and a tracelog error message is logged.

I have a large (1000's of instances) equipment hierarchy. I have added information to the custom fields in equip.dbf that I'd like to use to generate a list of equipment to filter an alarm list on. Something like:

EquipBrowseOpen("CUSTOM1=xyz","NAME")

Then iterate through each record and append each entry to an alarm filter.

Is there a way to filter an alarm list on 10/100/1000/10000 equipment instances without running into a "too complicated alarm filter" error. Users will often filter the alarm list based of equipment X.Y.Z and all it's children, but sometimes they need to filter the alarm list in way that is irrelevant to how the equipment hierarchy is structured and will just end up being a very long list of equipment in different parts of the hierarchy.

  • I suggest adding the content of your equipment CUSTOM1-field to one of the custom fields in your alarms as well. You can then filter directly on that alarm custom field without using EquipBrowse or any other cicode.
  • Hi Patrick,

    A few of the alarm custom fields are in use already, and I'd like to retain the others as spare for future use.

    The bigger problem is that instead of being able to tag a piece of equipment with an identifier, I'd have to tag the 50 digital, analog, advanced alarms assigned to that equipment instead. And then maintain it into the future as alarms are added, changed and removed.

    One of the filters I was considering was equipment Location, which is already defined property of equipment. It would be a substantially better solution to EquipBrowseOpen("LOCATION=AREA_1","NAME") and then pass the resulting list to an alarm filter, rather than checking which equipment an alarm is currently associated with and then copying/pasting that equipment Location in an alarm custom field.
  • The whole point of Equipment is to decrease manual actions needed on your tag and alarm databases, if done right.

    In the definition of your Equipment Types, just link the equipment field you'd like to use to one of the spare custom fields of your alarms, following these steps in the Equipment Editor:

    1) Create or modify an Equipment Type
    2) Add or modify an Equipment Item (select Digital Alarm as type, for example)
    3) Add a Field (for example CUSTOM8)
    4) Enter {equipment.LOCATION} to use the location field of your equipment instance
    5) Repeat this for all alarm definitions of all equipment types you have.

    When generating tags and alarms using the Update Equipment command, every CUSTOM8-field of your digital alarms will be filled with the ID you provided in your equipment definition. No manual copy-paste needed.
  • If this were a new project then yes. But it's an old brownfields upgrade and so we're not using equipment types. There is too much variability in tags and alarms between equipment. We're just trying to use the equipment hierarchy for alarm filtering and counting. Which is fine for 'filter on this equipment and it's children in the hierarchy', not so fine for 'filter on all equipment in e.g. location X'. It is a significant reduction in usefulness for an equipment hierarchy - object orientated model.
  • Ah right, that scenario had't crossed my mind. I'm sorry.

    Only way to avoid alarm filters getting too long though is to use a filter expression that filters on alarm properties. I don't think there's a way around needing a CUSTOM field for that, unless fields like PagingGroup or AlmComment haven't been used yet.

    What about creating a cicode script that iterates through your equipment, and writes to the alarm property field of your choice? This could either be:
    - Alarm properties in runtime; by performing a TagWrite to your <AlarmName>.PagingGroup
    - Alarm dbf file(s); by using DevOpen/DevFind/DevSetField functions (recompilation needed afterwards)

    It would avoid manual editing and you only need to run this script after a change in the alarm definitions.

    Regards,
    Patrick
© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.