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