Program stops executing in the middle of the script when triggered condition changes

[booger]

HI all,

Little problem here.  If the variable $Gate_in_motion_closing changes back to  0 before the program finishes executing, for some reason, it stops the execution.  I've never had an experience where the execution was effected by the state of the trigger after processing started.  The state_19 var is just to understand what's happening.  Can anyone give me some insight on preventing this behavior?

Just for clarification, If the state of $Gate_inmotion_closing changes back to 0 while "wait 15 seconds" is still blocking, the execution will remain blocked indefinitely.

Thanks for any help

Steve

 

Gate Confirm fully closed - [ID 0026][Parent 001C]

If
        $Gate_inmotion_closing is 1
 
Then
        $State_19  = 11111
        Wait  15 seconds
        $State_19  = 16616161
        Enable Program 'Gate Set Error not fully Closed'
        Run Program 'Gate Set Error not fully Closed' (If)
        Wait  5 seconds
        $State_19  = 55555
        Disable Program 'Gate Set Error not fully Closed'
        $State_19  = 0
 
Else
   - No Actions - (To add one, press 'Action')
 

[larryllix]

Welcome to trigger based programming!

This is expected behaviour from ISY994 programs. There are several ways to work-around this. Here is one.

Program1
If
      someTrigger
Then
      Run (If) program2
Else
     ----

 

Program2  [disabled]
If
   ---
Then
     disable Program1
     do some stuff
     wait for timeout if desired
     enable Program1
Else
    -----

[booger]

Thanks for the reply Larry,

Is there any documentation of this behavior and it's work arounds?

Steve

[hart2hart]

Thanks for the reply Larry,
Is there any documentation of this behavior and it's work arounds?
Steve

ISY trigger is not like normal program. It reevaluates the If condition during at least the Wait statements. This means your variable gate in motion closing changes values before the program ends and is caught during a wait statement. That’s why doing as Larry suggested will work around it or slightly differently-/—


If some condition
Then
Run then program2
...

The enable and disable will eventually bite you if power loss or other ISY reboot. I never use them. Instead, I use variables so ISY will restart in a predictable state.

[larryllix]

1 hour ago, hart2hart said:

ISY trigger is not like normal program. It reevaluates the If condition during at least the Wait statements. This means your variable gate in motion closing changes values before the program ends and is caught during a wait statement. That’s why doing as Larry suggested will work around it or slightly differently-/—


If some condition
Then
Run then program2
...

The enable and disable will eventually bite you if power loss or other ISY reboot. I never use them. Instead, I use variables so ISY will restart in a predictable state.

Run Program2 will retrigger Program2 every time the Program1 trigger happens anyway. It makes no improvement over the retrigger situation.

However, if you use the disable/enable technique and set the program to "Run at Startup" it can be corrected after any power failure like this.

If  [enabled or disabled] [Run at Startup]
      some trigger
Then
       Run (If) Program2
Else
      Enable Program1      (yes... self)
 

When the "Run at startup" happens the If section may be evaluated as False and Else will run, and re-enable the program, whether disabled or not.

If the some trigger is true at the "Run at Startup" time, Program2 will correct the disabled Program1 properly anyway.

[hart2hart]

Run Program2 will retrigger Program2 every time the Program1 trigger happens anyway. It makes no improvement over the retrigger situation.
However, if you use the disable/enable technique and set the program to "Run at Startup" it can be corrected after any power failure like this.
If  [enabled or disabled] [Run at Startup]
      some trigger
Then
       Run (If) Program2
Else
      Enable Program1      (yes... self)
 
When the "Run at startup" happens the If section may be evaluated as False and Else will run, and re-enable the program, whether disabled or not.
If the some trigger is true at the "Run at Startup" time, Program2 will correct the disabled Program1 properly anyway.

Point taken. I didn’t include the variables to control flow that prevents re triggers but that auto corrects without anything special at startup.

[larryllix]

6 hours ago, hart2hart said:

Point taken. I didn’t include the variables to control flow that prevents re triggers but that auto corrects without anything special at startup.

The variable method does look less messy, so I like it better, but it also doesn't reside in one place, making it harder to associate sometimes, but I have had trouble with variables in the past not being ready on time for programs to use them properly. OTOH: That may have been a quirk on some version that should have been corrected by now IMHO.

[oberkc]

16 hours ago, booger said:

Is there any documentation of this behavior and it's work arounds?

There is some discussion of this in the wiki.  A quote:

"What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause)."

[hart2hart]

There is some discussion of this in the wiki.  A quote:
"What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause)."

Which in OP post the else clause is empty so outward appearance is that it stops.

It will finish execution of statement in process with the exception of the Wait statement.

[oberkc]

5 hours ago, hart2hart said:

Which in OP post the else clause is empty so outward appearance is that it stops.

Agreed.  Just responding to the question about whether there was any documentation on this.

 

5 hours ago, hart2hart said:

It will finish execution of statement in process with the exception of the Wait statement.

Exceptions also include "repeats", I understand.

[booger]

Thanks for the reply's everyone,

After reading a few comments I realized that I need to be thinking ladder logic instead of procedural coding.  I appreciate the tips, after I got past my resistance to the spaghetti this creates, I was able to easily implement a solution.

Steve

[hart2hart]

Exceptions also include "repeats", I understand.

We were both just stating same in different terms on first item. I’m was not aware of repeats exceptions but I don’t use them often. Thanks.

[larryllix]

18 hours ago, oberkc said:

There is some discussion of this in the wiki.  A quote:
"What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause)."

This paragraph is quite misleading. While true, it implies that the state of the if section must change logic.

If the If section is true, and any line gets re-evaluated to true or false, whichever section is running will be stopped at the next time slice surrender point. ie. any Wait or Repeat program line, and either section, Then or Else, will then start to process at it's first line.

The same process will happen when the Else section running.

IOW: Whichever section is running, or none,  is not relevant to the result from a new trigger event. The quoted text implies the result is related to what is currently happening in the same program. That is incorrect.

Sent from my SM-G781W using Tapatalk
 

[hart2hart]

It depends on how you use the variables but yes it can.  Feel free to post what you need and we can take a look and provide feedback.