Wonderware intouch aknowledge all

Dear All,

We are using the alarm viewer control in wonderware intouch.
We have two buttons "Acknowledge selected" and "Acknowledge all".
This means that if you push one of these buttons the alarm(s) will be acknowledged both local and in the PLC.
The "Acknowledge selected" is always working.

But the "Acknowledge all" button we have some trouble with.
When pushing this button a new window opens up that contains a script to check what kind alarmlimit it is and sends a ack value down to the plc based on this. The script runs through all visble unacknowledged alarms in the window and acks automatically.

The problem is that sometimes a few alarms will only be acknowledged locally and not in the PLC. So the alarm viewer will be empty but on another window where we test on the status for that alarm it is still in alarm. This means that the ack value has not been written to the PLC.

The problem is actually that the alarm viewer is local and event triggered, it should have been possible to test on a bit in the PLC before the alarm is acknowledged locally.

Have anybody faced this problem before?

Does anyone know a better solution for acknowledging all alarms in the PLC?

Best regards
Robin Holum

Could it be possible that it is working, and they are being acknowledged, but the alarm condition still exists and so it is "coming back" right away?

Can you post whatever scripts you've written as a reference?

Hi xCOMMAND0x,

Thank you for answering.
Im sure that the alarms is not being acknowledged.

When pushing the button "Ack All" a new window opens,
which has the following scripts:

On show:

Read_Status_101= RowCount - 1;
IF IntAlarmViewerAlarms <= 8 THEN
Read_Status_102= IntAlarmViewerAlarms;
ELSE
Read_Status_102=8;
ENDIF;
Temp_BottomRow=BottomRow;
#AlarmViewerCtrl9.UnSelectAll();

While running (250ms):

Read_Status_101 = Read_Status_101 + 1;
Read_Status_102 = Read_Status_102 - 1;

IF Read_Status_101 > Temp_BottomRow THEN {Change amount of alarm points to read}
HideSelf;
ELSE
Tag3 = #AlarmViewerCtrl9.GetItem(Read_Status_102, "POINT");
Tag20 =#AlarmViewerCtrl9.GetItem(Read_Status_102,"Alarm Comment");
Tag500 = #AlarmViewerCtrl9.GetItem(Read_Status_102, "TYPE");
Tag900 =#AlarmViewerCtrl9.GetItem(Read_Status_102,"Value");
Tag700=StringLeft(Tag3,2); {Put 2 first char in Tag700 and use it for ack FAults}
Tag800=StringLeft(Tag3,2); {Put 2 first char in Tag800 and use it for ack AP alarms}
Tag20 =#AlarmViewerCtrl9.GetItem(Read_Status_102,"Alarm Comment");
#AlarmViewerCtrl9.SelectItem (Read_Status_102);
#AlarmViewerCtrl9.AckSelected (Tag20);

AckTag_Int.Name="iAP_" + StringRight(Tag3,4) + "ACK";
AckTag_Int2.Name="iAP_" + StringRight(Tag3,6) + "ACK";

IF Tag500=="HI" THEN
AckTag_Int=1;
AckTag_Int2=1;
Tag500="";

ENDIF;
IF Tag500=="LO" THEN
AckTag_Int=2;
AckTag_Int2=2;
Tag500="";

ENDIF;
IF Tag500=="HIHI" THEN
AckTag_Int=4;
AckTag_Int2=4;
Tag500="";

ENDIF;
IF Tag500=="LOLO" THEN
AckTag_Int=8;
AckTag_Int2=8;
Tag500="";

ENDIF;

IF Tag500=="DSC" AND Tag800=="AP" THEN
AckTag_Int=1;
AckTag_Int2=1;
Tag500="";
Tag800="";

ENDIF;

ENDIF;


On hide:

Temp_BottomRow=0;


Do you know another way of acking both local in alarmviewer and in the PLC at the same time?

Best regards

At a first glance, it looks like your scripting does some calculations right away to detect how many different rows of alarms, or alarm entries there are, then reads the values and tries to acknowledge them.

You said it sometimes acknowledges some, but not all of your alarms. Here's a few questions/tests I'd run:

1. Are only the first few rows getting acknowledged, and nothing past that?

2. If you simulate so you ONLY have 1 alarm, and do an Ack_All, does that work?

3. If you simulate so you ONLY have 3 alarms, and do an Ack_All, does that work?

I'm thinking there might be issues if there are more than 8 rows...

Check out pages 89 and 441 of this guide

Hi again,

I actually changed the amount of rows from 16 to 8 and this is looking much better but the problem is still there.

I tried to simulate both 1 alarm and 3 alarms, no problem.

Is it possible that it can have something to do with timing in the OPClink?
I am collecting alarms from 5 PLC's and have about 15 access names.

Best regards

It definitely could be...Based off of what I can read in the script I have a pretty good feeling it has to do with detecting the number of rows, or a timeout issue.

You have a line of code along the lines of:

While running (250ms):

Is your script only running for 250ms? If there are in fact 15 different Topics then it could absolutely be a timeout issue.

I'd suggest changing the time of your script to make sure it has enough time to fully execute. Perhaps add different "Flags" to see how far your script is getting.

Also, why limit to "8" or "16"? What if there are more? I mean, you don't want to arbitrarily set a number of maximum alarms, do you? You want it to dynamically detect how many there are and execute the script on each and every one.

For testing, try setting your script to 3000ms and change the number from 16 to something higher like 100 (depending on how many alarms you have).

This can help you narrow down if it is a timeout issue, or if it is a not detecting the number of alarms to acknowledge, etc.

Hi,

Thank you, i will try your suggestions.

The reason for limit to 16 or 8 is that i want to acknowledge only the alarms that the operator can see. The viewer size is big enough to show 16 alarms. So when acknowledging 16 alarms goes away and shows the 16 next alarms.

Best regards

Is it possible to "push" an alarm to the alarmviewer again?

If so then i can probably change my script so it can test on the ack bit in PLC and if it's not set then it will generate a new alarm for that point.

Best regards

RobinH said:

Is it possible to "push" an alarm to the alarmviewer again?

If so then i can probably change my script so it can test on the ack bit in PLC and if it's not set then it will generate a new alarm for that point.

Best regards

Click to expand...

When you acknowledge the alarms, are they disappearing from the list or just changing status to indicate they have been acknowledged? They shouldn't disappear.

Alarm Cycle:

1. New Alarm Arises (example - TemperatureABC.HiHi)
-Alarm shows in Alarm list as RED

Case 1 - Alarm condition goes away before acknowledgement
-Alarm changes color/status
-When "Acknowledged" alarm disappears from list, because condition no longer exists

Case 2 - Alarm condition is still current
-Alarm stays red/color of choice
-When "Acknowledged", alarm STAYS in list, but changes status to indicate acknowledgement.

An alarm should only disappear from the list if the condition that triggered the alarm is gone, AND it has been acknowledged. Acknowledging an alarm should not make it disappear from the list, unless the trigger condition is gone.

Make sense? Your alarming scheme seems to be different than every type of alarming scheme I've seen across numerous HMIs/PLCs.

Hi,

We have the same scheme as you describe, but we have actually two alarm viewers, one showing only unacknowledged alarms (the alarms im having problem with disappears from this alarm viewer) and we have one viewer for only the acknowledged alarms. (the alarms is in here but they are not acknowledged in the PLC).

Best regards

I've done something similar with InTouch.

We have an alarm object that queries only "unack" alarms. For the event trigger "NewAlarm" we run an activex event script that sets a memory discrete to true. The memory discrete triggers a while true condition script that runs every 1 second. I've not encountered issues with the below solution. Hope this helps.


{Contents of Condition Script While True}
DIM liRowCnt AS INTEGER;
DIM liIterationCnt AS INTEGER;
DIM liRowIdx AS INTEGER;
DIM lmAckTag AS MESSAGE;
DIM lmAlmTag AS MESSAGE;

liRowIdx = 0;

liRowCnt = #AlarmACKViewerCtrl.UnackAlarms;

IF liRowCnt > 0 THEN

{Do no more than 25 ACKS every second!}
IF liRowCnt < 25 THEN
liIterationCnt = liRowCnt;
ELSE
liIterationCnt = 25;
ENDIF;

{Extract ACK (ACK) Tags from Alarm View Control and Ack both ACK & Alarm (ALM) tags}

FOR liRowIdx = 0 TO liRowCnt - 1 STEP 1
lmAckTag = #AlarmACKViewerCtrl.GetItem( liRowIdx, "Name");
lmAlmTag = StringReplace( lmAckTag, "_ACK", "_ALM", 1, 1, 0);
idAlmACKAckTag.Name = lmAckTag;
idAlmACKAlmTag.Name = lmAlmTag;
idAlmACKAckTag.Ack = 1;
idAlmACKAlmTag.Ack=1;
NEXT;

{Refresh our counts to ensure nothing is left in the view control}
liRowCnt = #AlarmACKViewerCtrl.UnackAlarms;
ENDIF;

{Do we still have alarms left to ACK?}
IF liRowCnt == 0 THEN mdAlmACKNewAckDetected = 0; ENDIF;
{End of Script}

Dear PCMusicGuy,

Thank you for your answer. I will try to modify your script to see how it works for me.

I believe that i can test if the alarmviewer (unacknowledged alarms) is empty. If empty then i should run through all alarms in the other alarm viewer (acknowledged alarms) and ack everyone again to be sure they are being acked in the PLC.

Will check it out and let you know the result.

Best regards