PDA

View Full Version : Pausing a state machine


gtiani
12-08-06, 09:40 AM
On a ServoPod with IsoMax V0.82:
I would like to pause some state machines then restart them at the exact state they were in. Rather than added code to every conditional, I was thinking of re-defining CAUSES to force a false condition regardless of what the input condition was. Something like the following:

VARIABLE PAUSE-SM EEWORD \ 0 = pause, -1 = no pause

: CAUSESp \ T|F --; pause version of CAUSES
PAUSE-SM @ AND \ force a false if PAUSE-SM = zero
CAUSES ; IMMEDIATE EEWORD

Naturally, that did not work. How can I modify the definition of CAUSES or is there a better way to pause some of the state machines?
Thank you,
Gary

RMDumse
12-08-06, 04:17 PM
Well, how about just adding a qualifier just before the CAUSES statement.

VARIABLE PAUSE-SM EEWORD \ 0 = pause, -1 = no pause

: PAUSE-CHK \ T|F --; pause version of CAUSES
PAUSE-SM @ AND \ force a false if PAUSE-SM = zero
; EEWORD

used

IN-STATE
XXXX
CONDITION
...
PAUSE-CHK
CAUSES
... \ and so on



Another way to pause a state machine would be to take it out of the machine chain. You can UNINSTALL <name> if you used INSTALL to put it in. Or if you use the SCHEDULE-RUNS approach, just schedule another list of machines, with the ones you want to stop running left out. When they're not run, they don't change state. You can add them later, and they'll pick up right where they left off.

gtiani
12-08-06, 07:09 PM
I'm currently using the PAUSE-CHK method like the one you described. I just thought it would be more elegant to define all the checks within the PAUSES word.
I'll try the UNINSTALL and INSTALL method. That seems pretty elegant too. Is it safe to keep UNINSTALLing and reINSTALLing forever (about once every 5 to 30 seconds or so)? Is it safe to UNINSTALL one machine while inside another machine? Are the UNINSTALL/INSTALL words fast (i.e., will they execute within a several millisecond task)? With several machines running, can any sub-group of machines be UNINSTALLED/INSTALLED without effecting the remaining machines?
I know I've put a lot of questions in this post. I just want to make sure I'm not doing something that will cause occasional crashes after many hours of running.

12/11/06
I've had some limited successes with INSTALL & UNINSTALL. But, if I install & uninstall one machine from inside another machine I seem to get unpredictable results (multiple machines stop) and uninstalling a machine from inside itself really causes problems. Are there some rules I can follow when using INSTALL & UNINSTALL to avoid problems?
Thanks,
Gary

Update:
UNINSTALL seems to uninstall the given machine plus machines that were installed after it. Is that the way it should work? Is there any way to uninstall a machine without effecting other machines that were installed later?
Gary

RMDumse
12-11-06, 10:51 AM
Yes, well, INSTALL and UNINSTALL were intended to be used from the foreground for startup, and I doubt their use inside the interrupt routine was ever envisioned. I was a little surprized to hear your idea of using them inside the background routine. I just can't predict their actions there.

The same is true for EVERY...CYCLES...SCHEDULE-RUNS. It also was supposed to be used basically once at startup. it would probably come closer to working in the background interrupt, but again, without a rather extensive study of the actual machine code generated, I just can't predict their actions.

Concerning your question if these words are fast, I seriously doubt any efforts were made to make them so. Instead they were expected to be used basically once at startup, so the controlling paradigm for coding them would have been compact rather than fast.

Maybe the boolean disabling of the causes is the safest way.

gtiani
12-11-06, 11:48 AM
I guess the boolean check in front of CAUSES works fine, so I'll use it.
But, it sure would be nice to be able pause & unpause every state machine individually without adding extra code for every state of every state-machine. It seems like I always want a state-machine to be a little bit more than a just a state-machine.
Thanks,
Gary