Elk Rule engine question

Guy Lavoie

Active Member
I was posting a suggestion on the Elk M1 dealer site forum and then a question came to mind concerning how the rule engine worked. The following code is intended to dial a different number every 15 seconds as long as the system is still tripped (output 2 is still on) until the last number is dialed. My question is this: will all the rules begionning with "WHENEVER output 201 state is turned off" evaluate as true at the first occurance? If so, will they all be seen in the order the rules are presented below? If this is the case, then I run the risk of having the M1 queue the numbers to dial all at once since the 2nd rule sets the counter to 2, then the following rule looks for the counter being set to 2...then it fires and advances the counter to 3, etc.


WHENEVER output 2 is turned ON
THEN dial 1st number
THEN counter1 = 1
THEN Turn output 201 ON for 15 seconds

WHENEVER output 201 state is turned off
AND counter1 = 1
AND output 2 state is ON
THEN dial 2nd number
THEN counter1 = 2
THEN Turn output 201 ON for 15 seconds

WHENEVER output 201 state is turned off
AND counter1 = 2
AND output 2 state is ON
THEN dial 3rd number
THEN counter1 = 3

...


WHENEVER output 201 state is turned off
AND counter1 = last one
AND output 2 state is ON
THEN dial last number
THEN counter1 = 0


If this were an Ocelot, it would indeed behave this way. To get around it, I would either reverse the order of the rules as shown below, or use a SkipTo statement to skip over the remaining rules that are also looking for output 201 turning off.


WHENEVER output 201 state is turned off
AND counter1 = last one
AND output 2 state is ON
THEN dial last number
THEN counter1 = 0


WHENEVER output 201 state is turned off
AND counter1 = 2
AND output 2 state is ON
THEN dial 3rd number
THEN counter1 = 3


WHENEVER output 201 state is turned off
AND counter1 = 1
AND output 2 state is ON
THEN dial 2nd number
THEN counter1 = 2
THEN Turn output 201 ON for 15 seconds


WHENEVER output 2 is turned ON
THEN dial 1st number
THEN counter1 = 1
THEN Turn output 201 ON for 15 seconds


How does the Elk rule engine work here?
 

Spanky

Senior Member
Whenever an output changes state, all rules that have a WHENEVER tied to that output change state will be evaluated. If the AND part of the Rule is TRUE, then the RULE will be processed.

Multiple Rules with the same Whenever part will be evaluated in order from the 1st Rule to the last.

In the case of the Rule below:
WHENEVER output 201 state is turned off
AND counter1 = 1
AND output 2 state is ON
THEN dial 2nd number
THEN counter1 = 2
THEN Turn output 201 ON for 15 seconds

WHENEVER output 201 state is turned off
AND counter1 = 2
AND output 2 state is ON
THEN dial 3rd number
THEN counter1 = 3

The second Rule will also be processed because all the elements are TRUE where counter1 was set to = 2 from the previous processed Rule.

Maybe use multiple outputs and sequence the outputs. When the output 201 turns off, set output 202 to 15 seconds, etc.
 

Guy Lavoie

Active Member
Ok, so it works like the Ocelot.

Before C-Max 2.00 (ie: before the SkipTo statement) the solution was to reverse the order of the tests so that the values we wanted to detect last were placed first, avoiding the "just set" value rippling effect.

Thanks.
 

dscline

Active Member
Spanky said:
Whenever an output changes state, all rules that have a WHENEVER tied to that output change state will be evaluated.
Can I interject for a clarification? You specifically mean when the output is tied to the whenever line, not one of the AND lines, correct? The first line is the only trigger, and subsequent ANDs only further qualify after the trigger?

I'm new to this, so just trying to make sure I understand correctly.

Thanks!
 

Guy Lavoie

Active Member
Yes, that's right. In the Elk, the first rule is hardcoded as being the trigger that's looking for a change, event or wait time (for the WHENEVER EVERY X SECONDS style statements). Any AND statements look for conditions that are true at the time the WHENEVER statement fires.

Contrary to other ladder logic controllers, the Elk does not loop constantly looking for things to do, but instead waits for any of the possible triggering events to occur and if something happens, then runs through the rule list once to see if any WHENEVER statements are looking for this event as a trigger.
 

Spanky

Senior Member
Guy is entirely correct. The WHENEVER line is the event or happening that triggers the rest of the RULE to be evaluated. The optional AND lines are states of an input like: AND the state of the door is OPEN or AND the control is armed away. If all the lines are evaluated as TRUE, all the THEN statements are executed.

I have been looking at adding an END or RETURN statement that could be added to a THEN statement which would stop further RULE processing of the triggering event. Sometimes this would be handy.
 

Guy Lavoie

Active Member
Spanky said:
I have been looking at adding an END or RETURN statement that could be added to a THEN statement which would stop further RULE processing of the triggering event. Sometimes this would be handy.
Yes, that could be used like the SkipTo statement (of the Ocelot) that I was referring to.

Count my vote in!

Maybe you could call it ENDEVENT in order to indicate that it is only ending the rules evaluation for that particular event.
 

dscline

Active Member
Thanks very much for the clarifications... that was what I thought, but wanted to make sure I was clear. :)
 

Guy Lavoie

Active Member
I don't see a direct way to test that (such as if an output is so many seconds away from turning off) so you would need to simulate it by using a counter to keep track if intermediate steps in your routine and increment (and test) the counter every time you turn on the output for the next step. Something like this:

WHENEVER output 201 state is turned off
AND counter1 = last one
THEN do last step
THEN counter1 = 0
...

WHENEVER output 201 state is turned off
AND counter1 = 2
THEN do 3rd step
THEN TURN Output 201 ON FOR z SECONDS
THEN counter1 = 3

WHENEVER output 201 state is turned off
AND counter1 = 1
THEN dial 2nd number
THEN TURN Output 201 ON FOR y SECONDS
THEN counter1 = 2

WHENEVER (triggering action)
THEN do first step
THEN TURN Output 201 ON FOR x SECONDS
THEN counter1 = 1

Note that the order of the events we're looking for is reversed in the rule order. This is to avoid having the second step trigger immediately because the first step just changed the counter for the second step right before it, etc.
 

mikefamig

Senior Member
Spanky said:
Guy is entirely correct. The WHENEVER line is the event or happening that triggers the rest of the RULE to be evaluated. The optional AND lines are states of an input like: AND the state of the door is OPEN or AND the control is armed away. If all the lines are evaluated as TRUE, all the THEN statements are executed.

I have been looking at adding an END or RETURN statement that could be added to a THEN statement which would stop further RULE processing of the triggering event. Sometimes this would be handy.
 
I am responding to this old message posted by Spanky in hopes of reviving the topic of adding an END command to Elk rules language. It is an idea that I proposed in a message thread a short while back and I think that it would be a great addition.
 
The way I understand rules to work now seems unnecessarily difficult to me. Each time I add a new rule I have to study all of the existing rules and all Whenever statements an be very careful not to cause a problem with them. And the fact that the WHENEVER  statement looks for a "change of state" while the "AND" looks for an existing state is a problem in that I do not know how long that "change of state" exists before it becomes an "existing state" that will satisfy an "AND" statement.
 
An END command that quits execution and bugs out would simplify things greatly.
 
Mike.
 

mikefamig

Senior Member
sda said:
An explanation from Elk on how the rules are evaluated would go a long way.
I agree and I made that request at the elk support forum but never received a reply. If you read this entire message thread above that I quoted here Spanky does explain it to some degree.  It helps me to understand that  "whenever" looks for a change  of  a device's state and the "and" looks for the existing condition of a device's state.
 
But again, at what exact time does a change of state become an existing state? What is the lifespan of a "change of state"?
 
Mike.
 
mikefamig said:
I am responding to this old message posted by Spanky in hopes of reviving the topic of adding an END command to Elk rules language. It is an idea that I proposed in a message thread a short while back and I think that it would be a great addition.
 
An END command that quits execution and bugs out would simplify things greatly.
 
Mike.
Unfortunately only so much memory in the panel and the hardware hasn't really changed in almost 10 years. Hell, they updated the XEP and nuked the web interface that many of my accounts use when traveling abroad. I'd love it if they put a little more power and some other options on the main board, but until they do that, I think there's only so much that can be done.
 
I'm still begging for an addressable fire loop or the ability to support multiple 2 wire fire zones natively on the board or via a "bolt on".
 
I remember a training class that I sat through for the Radionics (now Bosch) 9000 series panel-their largest flagship at the time, and the instructor and engineer were asked why they only put a single on-board relay on the panel but had sockets for 2 others that you could buy the plug in relay for....answer was they'd have to charge about $10-15 on top of the base panel cost per relay on the board and the push back from the installers for a panel cost increase of $25 or so for a couple of relays that may never be used in 90% of the installs out there didn't make sense.
 
I understand the need or desire for such, but the cost increase to add X feature that may never be utilized in many installs would definitely cause pushback. Hell, I'd love if the panel offered the event based boolean or true boolean like access or a FACP but it's not going to happen in a sub $400 panel. 
 

mikefamig

Senior Member
DEL
 
Everything you say makes good sense but it's still good to get ideas out here as a future version request. I also made a request over at the elk support forum for an improvement to ELKRP2. I just installed it on a laptop with 14" screen and with the resolution set to 1920x1080 the fonts are so small that I can't read the screens. It doesn't work with touchscreen pinch and zoom and there is no way to adjust the font size in the application so I had to turn my screen res down to 1280x720 which isn't so good for many of the other apps on the pc. Hey it can't hurt to ask.
 
I especially would like to get some info on how the elk rules engine operates and I'm  thinking that there are members here who know a lot more about it than I do.
 
Mike.
 
Top