Concurrent "Run Program"

[bktong]

Need some help with ISY programming language.  I have been using ISY for a few years and computer programmer by trade.  Some top-down design programming languages execute a statement then the next.  If a function or a sub-program is called, normally it runs the next statement after the function or sub-program is done.  However, I notice the RUN PROGRAM in ISY language executes as soon as the calling program is started.  It doesn't execute one statement after another.  I know I can put a WAIT statement to wait for the called program to complete.  

For example, I want to assign a variable after a RUN PROGRAM statement.  The program calculates some values but the variable has assigned a wrong number because the program right before the assignment statement is still running.   I even put Wait statement in the called program doesn't help.  

Is ISY programming language working as designed? I assume if I have multiple RUN PROGRAM statements within a program, all of them would run concurrently? 

If

     Time is 12:00AM

Then

    Run Program 'Calc Temperture' (Then Path)

    $Variable = $Cur_Temp

Else

- No Actions

 

The $Variable would get $Cur_Temp from last night or last run of the program.  

Is WAIT statement the only way to control the run sequence?  

Thanks. 

Fireware v.5.0.12 and UI also is v.5.0.12. 

Edited May 19, 2018 by bktong

[oberkc]

I don't believe that you can assume that the "run program 'calc temperature' (then path)" must complete before the variable is updated.  A wait statement could work, but you may also try a third program:

if

time is 12am

then

run program calc temperature then path

else nothing

Add to the calc temperature program an action such as:

"run third program (then path)

Create a third program

if

nothing

then

$Variable = $Cur_Temp

[bktong]

That's my point the Calc_temperature might not be complete but the Variable has been executed; therefore, wrong number has been assigned.  If I create a third program to have 2 Run Program statements, both programs will run concurrently.  I would still get a wrong number assigned to Variable.

[mwester]

"Run Program" is not like calling a subroutine or function -- it is not intended to be synchronous to anything at all.  It's more like launching a Windows service or a Linux daemon.  A "WAIT" statement in your program may or may not result in you getting the correct value; it depends on all sorts of things including how busy the ISY is at that moment.

In general, the ISY is an event-driven programming model -- it's regrettable (IMO) that they borrowed some concepts from procedural programming models, and forced them into that event-driven model (it doesn't work well and often confuses more than it helps).

In such an event-driven system, if you want to model your "call subroutine" approach, you'd have to do it as below.  (Note that there are probably better, more efficient ways to do this -- I'm just illustrating how to do the "call", not trying to build a specific optimal solution!)

 

Program A:
If Time is 12:00:
  Run Program "Calc Temp"

Program Calc Temp:
If <nothing>:
  <perform computations>
  <save result in STATE variable RESULT

Program A2:
If RESULT changes:
  <continue with whatever you wanted to do after the temperature was calulated>

 

[larryllix]

30 minutes ago, mwester said:

"Run Program" is not like calling a subroutine or function -- it is not intended to be synchronous to anything at all.  It's more like launching a Windows service or a Linux daemon.  A "WAIT" statement in your program may or may not result in you getting the correct value; it depends on all sorts of things including how busy the ISY is at that moment.

In general, the ISY is an event-driven programming model -- it's regrettable (IMO) that they borrowed some concepts from procedural programming models, and forced them into that event-driven model (it doesn't work well and often confuses more than it helps).

In such an event-driven system, if you want to model your "call subroutine" approach, you'd have to do it as below.  (Note that there are probably better, more efficient ways to do this -- I'm just illustrating how to do the "call", not trying to build a specific optimal solution!)

 

Program A:
If Time is 12:00:
  Run Program "Calc Temp"

Program Calc Temp:
If <nothing>:
  <perform computations>
  <save result in STATE variable RESULT

Program A2:
If RESULT changes:
  <continue with whatever you wanted to do after the temperature was calulated>

 

This also leads to just putting "Program A2" Then Lines, inline after the code in "Calc Temp" if the code lines are simple and easily followed years later.
I usually prefer the mwester way to keep things modular (state engine style) . Trigger event based  programming can be tricky to follow at times. Especially for season inline programmers. Culture shock. LOL    

VB could be used as event based  so many have the concept already.  I miss those days.... Interactive forms in one hour, while you wait!

 

For ISY think of the Wait and Repeat like the Windoze 3--,  with it's voluntary time slice surrendering or OS thread launching.  Code lines together will execute contiguous without interruptions. Wait and Repeat lines surrender the time slice back to the ISY engine to distribute time wherever it sees fit.

Edited May 20, 2018 by larryllix

[bktong]

Thanks all.  I have to re-think my programs.