Different behaviors of an IF-statement

Darkside

BlackLabel wrote:

In the corrct running version of the code, all parameters are same except the positions of the two conditions of the IF ((condition1) AND (condition2)) are swapped.
If COFFEE_ACTIVE is condition1, the code fails, if COFFEE_ACTIVE is condition2 everything is fine.

Weird indeed.

My note about the position of the coffee_active flag is related to the note about multiple beeps - not the incorrect logic.

Did you end up swapping the time and alarm time around?

BlackLabel

This is a review of the changes I checked:

Swapping TIME and ALARM_TIME from IF (TIME = ALARM_TIME) into IF (ALARM_TIME = TIME) did not take any effect.
I'm sure, that it's no problem with the time part of the statement, because I checked the following code:
IF ((COFFEE_ACTIVE = 1) AND (TIME = '01:00:00')) - and my coffee maker did start at the defined time, ignoring the state of COFFEE_ACTIVE.


My next idea was to avoid using the word "ACTIVE" as part of my variable (if the compiler could misunderstand this as a keyword):

I tried to change the variable COFFEE_ACTIVE into COFFEE_PLEASE - same problem as long the time part remains on second position of the rule.

I defined a new variable COFFEE_FLAG and tried to use IF ((COFFEE_FLAG = 1) AND (TIME = ALARM_TIME)) after setting it to zero in the DEFINE_START section - same problem

While my tests, there was no possibility, that COFFEE_ACTIVE or COFFEE_PLEASE or COFFEE_FLAG could carry a different value than 0 (zero).

In my actual (correct running) code, I changed the position of the COFFEE_ACTIVE = 0:

IF ((TIME = ALARM_TIME) AND (COFFEE_ACTIVE = 1))
    {
	COFFEE_ACTIVE = 0
        ON [RELAY,12]
	SEND_COMMAND TP,'WAKE'
	SEND_COMMAND TP,'PAGE-INFORMATIONS'
	SEND_COMMAND TP,'BEEP'
	SEND_COMMAND TP,"'!T',152,ALARM_TIME,$0D,'COFFEE MAKER STARTED...'"
    }

I've got no idea about the reason for this mysterious behavior.

Joe Hebert

I think the TEMP_TIME test that Brian suggested and the results have eliminated TIME as the culprit because now the second condition is a simple string to string comparison. If you try something like this…

DEFINE_VARIABLE
TEA[8]
MILK[8]
COFFEE_ACTIVE

DEFINE_START
TEA=’TEA’
MILK=’MILK’
COFFEE_ACTIVE = 0

DEFINE_PROGRAM

WAIT 100 MILK=’TEA’
IF ((COFFEE_ACTIVE = 1) AND (TEA = MILK ))

...and the relay closes 10 seconds after the program starts then the keyword TIME is not the problem.

Maybe it’s having a problem when the last condition is a string comparison. I wonder what would happen if you added a third condition that is an integer comparison. I realize the IF should fail immediately after the first condition you have set but none of this is making any sense anyway.

Does the time really need to be sent to the touch panel a billion times a minute? It only changes once a second. I think a WAIT 10 is in order. Sorry, I know it’s got nothing to do with your original post.

Stephen Bolton wrote:

Aside from the fact that this routine is misbehaving, the reason it beeps seven times is probably because your 'lockout' flag is at the end of the routine.

The placement of the flag will have no affect on the number of beeps because the IF statement will not be evaluated again until it has finished executing the code inside the IF and finished executing the rest of whatever is in mainline.

Interesting thread….

Edit: Dyslexia correction.

BlackLabel

Hi Joe,

it's not depending on the TIME:

IF ((COFFEE_ACTIVE = 1) AND (TEA = MILK)) <-- switches RELAY#8 ON after 10 seconds and ignores the state of COFFEE_ACTIVE
IF ((TEA = MILK) AND (COFFEE_ACTIVE = 1)) <-- is running properly and switches RELAY#8 ON if COFFEE_ACTIVE is TRUE

And as before, the correct running code compiles one byte larger.

I'll be offline for the next days.
I'd like to wish Merry Christmas and a Happy New Year to all the helping people here in this group.
Kind regards
BlackLabel