Long Alarm Filters

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.

Parents
  • 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.
Reply
  • 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.
Children
No Data