When the alarm is switched off via the screen, an alarm is still sent out

Hi, when testing via the debugger and then applying a breakpoint, the code is running correctly and the code to send an SMS or email for an alarm is skipped.
However, during testing, in reality, an SMS / email is still sent when this should not be allowed.

With tag AL_Inhibit is a PLC tag witch inhibits the alarm to be sent or not.

MOVED TO STAFF NOTE (201.5 KB)

ProcessAlarm: Onerror "goto EndCount" If (AL_Inhibit@ = 0) Then b% = Getsys Prg, "NBTAGS" b% = b% - 1 REM index gaat van 0 tot NBTAGS-1 For i%=0 To b% ONALARM -i%, "GOSUB SmsAlarm" Next i% EndIF EndCount: Onerror "" END

Instead of having a timer that runs every second to check if the AL_Inhibit tag is active or not, could you just use an OnChange and then have that have it check the value of the AL_Inhibit tag and disable the sendsms/email part of those tags?

Hi Tim,

I try to elaborate on the matter my colleague tries to explain if I may. :slight_smile:

The “Al_Inhibit” is a checkbox on the display to give our technicians the ability to shut-down the alarming if they are working on the installation.
If I read your post correctly, you do a “onchange” on the AL_inhibit variable?

We want the alarms to be checked continiously (every second or so) and sent out as soon as they happen, that’s why the 1s-timer…
With the onChange we cannot write “1 or 0” to the “Alarm enabled” section of the tag because there are also other tags which are only historical tag or user tags… in this case we set/clear the alarm enebaled bit for every tag no?

The “smsAlarm” section, which is called (when the tag goes in alarm or rest status) is being used to fetch the custom “text to be sent” for the message to a custom sendlist. so how would we call that section then correctly?

br
Peter

If you’re doing alarms (not through basic but at the tag level) they should be checked constantly each time the value changes.

With the AI_Inhibit you could do an onchange that would make it so your alarms are enabled on the tags you want if the value is high, and turn them off if the value is low.

More or less it would be the same as hitting this button on a tag

@Tim_hms,

I am a bit afraid this discussion is talking beside each other…

Our alarming is going through Basic, and we would like to keep it that way.
=> The problem is that the “If() … endIF” isn’t working like it should be.
=> If the script was smaller, without historical logging, SD-card this part worked perfectly… :confused:

The solution, as proposed by you, would make the script again larger (getting tag, writing tag, saving tag… also more wear-out of the disk of “cont.” writing of tags (on/off))?
The onchange brings yet again a new “label/section” and the 1s-“label/section” will still be there except the “If (AL_Inhibit@ = 0) Then”-part in it… no? :thinking:

Syntax wise, our code should work also no? It worked before… :face_with_raised_eyebrow:

BR
Peter

Could you put some print statements in the part of the code where it should be enabling and disabling the email to make sure it’s getting to that section of the code? Also does it seem like there’s any errors in the console?

Hi Tim,

When activate the checkmark onscreen (AL_Inhibit = 1) and we put a break point on the line 23
image
the execution stops on that line… when we push “continue” in the debug, the execution jumps over towards the “Endif” statement and no Alarm is being send out…

If we clear the breakpoint on line 23 and let the script run at usual execution pace, the alarms are being sent out (Al_Inhibit is still 1…)

In the console we don’t get any error-messages.

br
Peter

Can you put a print statement after the “if (AL_Inhibit@ = 0) Then” line and write something like

print “made it here”

Then run it again? I’m wondering if it’s just going straight to the SMS alarm subsection and ignoring the if statement. We might need to try and make the SMSAlarm a function instead

Hi Tim,

I have found a solution by moving the IF statement behind the subroutine SMSAlarm. In this way, the automatic triggering of an alarm, when it should not be triggered, is stopped by checking the high bit in the subalarm and not in the first part.

The problem would have been with the ONALARM which was triggered anyway.
How is it possible that this ONALARM is triggered when it is in an IF statement, is the IF statement is ignored by the program?

Below is the reworked code (in bold the changes).

ProcessAlarm:
Onerror “goto EndCount”
//
b% = Getsys Prg, “NBTAGS”
b% = b% - 1
Test% = 0
For i% = 0 To b%
ONALARM -i%, “GOSUB SmsAlarm”
Next i%
//
EndCount:
Onerror “”
END

SmsAlarm:
IF (AL_Inhibit@ = 0) Then
Index% = GETSYS PRG,“EVTINFO”
SETSYS TAG,“LOAD”,Index%
M$= GETSYS TAG,“AlHint”
A% = ALSTAT(Index%)
IF A%=2 Then
M$= M$ + “,Alarm”
ENDIF
IF A%=0 Then
M$= M$+",Herstel"
ENDIF
SENDSMS sendlist$,M$
AL_HIST@ = 1
ENNDIF
RETURN

Kind regards,
Jonas

1 Like

I believe any of the ON statements are active unless they are commented out and will run regardless of their location.

Glad to hear that you found a work around for this though