iFIX 5.5 alarm area counters out of sync

[shanefaulkner]

iFIX 5.5. We have alarm count database tags with SIM driver and I/O address = "C:AREA-SD:ACK" which is suppose to count the acknowledged alarms in the AREA-SD alarm area. The problem is some of the counters are showing a value >0 when there are no tags in alarm (acknowledged or otherwise) in that area.

A reboot solves the issue temporarily but the problem always returns.

I am thinking a load empty database, clear alarm areas database, and a re-import of all tags might help but that could be tough to schedule.

Just wondering if anyone has seen this and knows of a solution.

 

[shanefaulkner]

Forgot to add, no SCADA redundancy here, just the one SCADA.

 

[harryting]

Ya, it's a common issue but I don't know of a solution.

 

[tlf30]

Yep, we have had the same issue all the way up to the new 6.x versions (no fix yet). Redundancy just makes it much worse (especially on a failover).

Our name for iFix is "iBroke uFix"

EDIT: We do not need a reboot to fix it. Just ack all alarms on the server itself. Login to the HMI on the actual server and spam the ack button. It may take a few tries, and then wait a couple minutes and try again if the alarm counter is not to 0 yet. Especially on a failover, sometimes the alarm counter will re-increment after a couple minutes with alarms that do not exist.

 

[cardosocea]

Yep, we have had the same issue all the way up to the new 6.x versions (no fix yet). Redundancy just makes it much worse (especially on a failover).

Please tell me you're joking. This still not fixed????

EDIT: We do not need a reboot to fix it. Just ack all alarms on the server itself. Login to the HMI on the actual server and spam the ack button. It may take a few tries, and then wait a couple minutes and try again if the alarm counter is not to 0 yet. Especially on a failover, sometimes the alarm counter will re-increment after a couple minutes with alarms that do not exist.

On a failover, usually I'd have to revert the server that was master back to master so that they'd clear.

 

[TheWaterboy]

Happens with some frequency, always when the database gets disturbed through online editing or redundancy.
If memory serves.... look in database for the New Alarm Field and set them all to NO. That should clear the counters or at least show you the alarms being counted.

I'm using v2022 and it still does this.

 

[shanefaulkner]

A query of New Alarm = YES returns no tags.

 

[TheWaterboy]

Do you have a counter value at this time?

 

[TheWaterboy]

If you look up "Ghost Alarms" on the iFix site you will find some info about it. (or maybe not, the iFix site really sucks now)

 

[shanefaulkner]

tag AREA-SD_ACK has SIM I/O address C:AREA-SD:ACK and has current value = 4.

Query all tags with any alarm area = "AREA-SD" and it returns 6 tags, all of which have current alarm = OK and New alarm = NO.

 

[TheWaterboy]

Just a shot in the dark, leave out the AREA-SD part of the query and see what you get just for new alarms

 

[shanefaulkner]

Query just new alarm = "NO" returns nothing. Even tried new alarm != "YES" on a whim

 

[TheWaterboy]

My query for Ghost alarms is:

{Tagname} = "*" AND {NEW ALARM}="YES"

If that doesn't get there, I might not be clear on the issue. I don't use SIM for anything so maybe it has additional fields.

 

[shanefaulkner]

Misspoke earlier: Query of New Alarm = "YES" returns nothing.

The first part of the suggested query Tag Name = "*" and New Alarm = "YES" is redundant, but I tried it anyway. No tags reported.

 

[TheWaterboy]

Misspoke earlier: Query of New Alarm = "YES" returns nothing.

I assumed as much

The first part of the suggested query Tag Name = "*" and New Alarm = "YES" is redundant...

You would think so but in my experience, missing the tagname portion of the query will not give you any results at all. I found that an annoying requirement indicative of GE making things Almost Right.

Perhaps that got fixed in a SIM at some point if you are getting results without it. Habit on my part then.

I'm out of ideas then.