Program Execution

[KSchex]

Hello All,

So that I can more effeciently program my ISY, I need to better understand the architecture of the internal system.  I have the following questions:

 

1-Is the ISY continusouly evaluating the IF statement in each program one after the other, in a round-robin fassion?

 

2-Once an IF/THEN is executing can it be interrupted by another "program"; ie:  time, wait, etc?

 

3-If a device is commanded does it wait for return status before moving to the next program or the next THEN/ELSE statment within the program?

 

4-Assuming the ISY executes one program then the next then the next....On an average, how many miliseconds does it take for one loop iteration assuming one simple program commanding one device?  I realize there are a lot of variables that would effect this. 

 

Thanks very much....

 

 

 

[larryllix]

Hello All,

So that I can more effeciently program my ISY, I need to better understand the architecture of the internal system.  I have the following questions:

 

1-Is the ISY continusouly evaluating the IF statement in each program one after the other, in a round-robin fassion?

 

2-Once an IF/THEN is executing can it be interrupted by another "program"; ie:  time, wait, etc?

 

3-If a device is commanded does it wait for return status before moving to the next program or the next THEN/ELSE statment within the program?

 

4-Assuming the ISY executes one program then the next then the next....On an average, how many miliseconds does it take for one loop iteration assuming one simple program commanding one device?  I realize there are a lot of variables that would effect this. 

 

Thanks very much....

1) Maybe. The ISY engine evaluates any logic statement containing the element if the element changes value.

 

2) Yes. Programs voluntarily give up CPU control at Wait, and Repeat statements.

 

3) NO. It's a multi tasking system that continues with or without ACK / NAK

 

4) See all above

[oberkc]

I would differ from larrylix (perhaps better described as an attempt to clarify) on the response to question 1. I would definitely NOT (no maybe about it) describe the evaluation of program conditions as "continuous". Program conditions are only evaluated upon triggerining events, with those events being driven by each of the statements in the program condition.

 

To offer an example...a program condition such as:

 

If time is from sunset

To sunrise (next day)

 

will be evaluated exactly twice each day.

[KSchex]

Thanks all...I think I have an idea now. 

[stusviews]

Programs are not evaluated continuously. They await a trigger much as a device awaits an Insteon signal.

[larryllix]

I would differ from larrylix (perhaps better described as an attempt to clarify) on the response to question 1. I would definitely NOT (no maybe about it) describe the evaluation of program conditions as "continuous". Program conditions are only evaluated upon triggerining events, with those events being driven by each of the statements in the program condition.

To offer an example...a program condition such as:

If time is from sunset

To sunrise (next day)

will be evaluated exactly twice each day.

I kind of figured the OP may be referring to the ISY programmer/user's point of view but he did post.

 

..."architecture of the internal system."

 

and the reason I posted "maybe".

 

While UDI has never really released the hidden secrets of the ISY execution engine I see a few ways of doing what they have done.

 

1) On a time clock basis you scan every line of code and see if any factors have changed. Not likely and maybe the way the antique v4 and earlier versions worked.

 

2) Every time any event occurs you scan every logic line to see if anything is affected and run accordingly. Maybe?

 

3) Each time any event occurs, ISY scans a specific and particular link table for that event/device. From there you branch out to evaluate those and only those logic lines or programs involved. Much more economical for CPU cycles and I believe this is the major change to the ISY v5.x event logic engine.

 

Reading this UDI is probably doing some hidden snickering behind the scenes (not Insteon scenes).

 

 

So while the ISY user / program writer, only sees the ISY magic, behind the scenes the "little ISY engine that could", is polling and scanning at high speed constantly, so the user doesn't have to.

 

This is why I laugh when people suggest linear languages would be so much easier and simpler. I know they haven't written an event based trigger OS yet and most likely will bog down somewhere around the two to three year mark, doing it "My Way".

 

There is always somebody that wrote the code, and doesn't believe in the magic, so that we can.

[KSchex]

I kind of figured the OP may be referring to the ISY programmer/user's point of view but he did post.

 

..."architecture of the internal system."

 

and the reason I posted "maybe".

 

While UDI has never really released the hidden secrets of the ISY execution engine I see a few ways of doing what they have done.

 

1) On a time clock basis you scan every line of code and see if any factors have changed. Not likely and maybe the way the antique v4 and earlier versions worked.

 

2) Every time any event occurs you scan every logic line to see if anything is affected and run accordingly. Maybe?

 

3) Each time any event occurs, ISY scans a specific and particular link table for that event/device. From there you branch out to evaluate those and only those logic lines or programs involved. Much more economical for CPU cycles and I believe this is the major change to the ISY v5.x event logic engine.

 

Reading this UDI is probably doing some hidden snickering behind the scenes (not Insteon scenes).

 

 

So while the ISY user / program writer, only sees the ISY magic, behind the scenes the "little ISY engine that could", is polling and scanning at high speed constantly, so the user doesn't have to.

 

This is why I laugh when people suggest linear languages would be so much easier and simpler. I know they haven't written an event based trigger OS yet and most likely will bog down somewhere around the two to three year mark, doing it "My Way".

 

There is always somebody that wrote the code, and doesn't believe in the magic, so that we can.

I am OK with time slice, interrupts, polling flags, whatever.  It just makes a difference to me in how I code certain devices and alarms.  Sometimes, depending on the process, you can get carried away with features slowing down the system, especially on an "embedded" device even though you try to make it as tight as possible..As long as the processor is fast enough it should not matter.  What bothers me is these "IF" statements can multiply quickly if you have 20 or more devices along with automatic enables and disables together with driving visual and audible annunciation...I guess I don't have a good feel for it yet and am trying to predict performance.  Thanks again..