View Full Version : Intermachine relationship in Isomax
cmmffhc
08-11-05, 03:10 AM
Hi,
I have a fundamental problem regarding the sequence in which the Isopod actually carries out its actions.
Suppose I have 2 machines running in parallel.
Under "CAUSES", which are the actions executed by the machines, will the isopod execute all the actions of 1 machine before doing any other thing? Or will it execute some of the actions, then do other things, then return to executing the action?
My main concern is that i need all the actions to be executed in 1 machine before the other machines executes its actions because there are intermediate values which may affect the other actions of the other machine.
thanks
RMDumse
08-11-05, 10:44 AM
IsoMax(TM) works by sequentially executing the schedule machine chain. Right now a machine chain and a regular definition are the same thing. Later in the development of the language, there may be distinction and type checking.
So if you install two machines in the machine chain (or a definition)
MACHINE-CHAIN ALL
M1
M2
END-MACHINE-CHAIN
only one state in either machine will be active. Associated with that state, there may be a number of transitions. So starting with the last transition (iirc, as currently implemented although you should write your code so order of evaluation doesn't matter), and the CONDITION is tested. If it fails, the next transition CONDITION is tested, and so on, until all CONDITIONs attached to that state are evaluated false, OR! the first CONDITION evaluated true. If a CONDITION evaluates true, then the CAUSES phrase is executed, and the state is changed to the new state and that machine is done and over until the next scheduled run.
After a machine has checked CONDITIONS until the first that is TRUE or until all are evaluated and all are false, then the machine ends and passes control to the next thing in the chain.
So in the above example at the scheduled run time, M1 is executed, which starts down a list of transition CONDITION evaluations, with branch to next CONDITION on FALSE result until the CONDITIONS associated with the active state of M1 are exhausted. Then M2 is executed which starts down a list of transition CONDITION evaluations, with branch to next CONDITION on FALSE result until the CONDITIONS associated with the active state of M2 are exhausted.
So to try to answer your question, no, a machine does none or one CAUSES action - period - then terminates.
The idea of doing multiple actions would imply going into multiple states at the same time, and that is not what the state machine paradigm is about.
HTH, is it clear?
cmmffhc
08-12-05, 03:08 AM
Hi,
Thanks for your prompt reply.
Let me try to sum up what I understand from your explanations. Please correct me if I interpreted it wrongly.
Assuming I have 2 machines M1 and M2 in the chain.
The sequence in which the isopod will execute commands is:
1. Check conditions of active state of M1
2. If all false, do nothing and proceed on to check conditions of active state of M2.
3. If true is encountered, execute actions under CAUSES of active state of M1.
4. Once all actions are completed, proceed on to check conditions of active state of M2.
5. The cycle is then repeated.
Did I get it right?
Regards
RMDumse
08-12-05, 11:22 AM
Let me try to sum up what I understand from your explanations. Please correct me if I interpreted it wrongly.
Yes I think you got it right, but there is a bit of ambiguity, so I'll amplify on a couple points.
The sequence in which the isopod will execute commands is:
1. Check conditions of active state of M1
2. If all false, do nothing and proceed on to check conditions of active state of M2.
3. If true is encountered, execute actions under CAUSES of active state of M1.
4. Once all actions are completed,
Once the first TRUE CONDITION is encountered, or after all CONDITIONS are evaluated as FALSE, ...
proceed on to check conditions of active state of M2.
5. The cycle is then repeated.
When the next schedule run time period passes, then repeat passing through machines.
Now, there are some special features in the language THIS-TIME vs. NEXT-TIME (with NEXT-TIME being the same as TO-HAPPEN).
If you use THIS-TIME you can force a reevaluation of the same machine, rather than the next machine. So in the EXAMPLE if the state of M1 had a CONDITION which evaluated TRUE and ended with THIS-TIME, it would rerun M1 until it either got all FALSE conditionals, or it came to a state transition with NEXT-TIME or TO-HAPPEN ending it.
So normally, a machine can only change one state by one transition with TO-HAPPEN or NEXT-TIME. Judicious use of THIS-TIME can allow the machine to continue to run and switch multiple states in one schedule run's period. The problem with THIS-TIME is it can cause a lock up, if you get two states that constantly switch to each other. So use of THIS-TIME is an advanced programming concept. I mention it now, so perhaps you will understand the normal operation better, the idea of check CONDITIONS until need for a transition occurs, do the action CAUSES associated wtih that CONDITION, and then terminate with a new state selected for the next time it runs.
cmmffhc
08-14-05, 12:13 PM
Hi again,
If M1 found a condition to be true then:
Will the conditions for M2 be evaluated before the actions in the CAUSES of M1?
Or will every action in CAUSES of M1 be executed before conditions of M2 are executed?
Regards
RMDumse
08-14-05, 12:43 PM
If M1 found a condition to be true then:
Will the conditions for M2 be evaluated before the actions in the CAUSES of M1?
No. Each machine runs to termination. Either it exhausts conditions that evaluate false in the current state, or it finds the first condition that evaluates true, does the CAUSES clause, changes state, and terminates.
Then other machines get their chance to run.
Or will every action in CAUSES of M1 be executed before conditions of M2 are executed?
Yes.
cmmffhc
08-14-05, 09:50 PM
Hi,
Thanks for your help!
Regards
vBulletin v3.0.7, Copyright ©2000-2012, Jelsoft Enterprises Ltd.