UI: Timeout

[Francois Normandin]

Hey guys,

I've played around with "JKI - String-Based Queued State Machine (Basic) v1.0" template and I find it really useful.

I'm implementing it in many of my new code. As I'm sure this is not the last version we see of this, may I suggest this simple addition for the next version?

 

Adding "Timeout" to the Core Cluster & "UI: Timeout" to control it. To have the ability to change timeout on the fly like UI: Timeout >> 100 command would be really useful.

 

[Jim Kring]

Hi,

 

I'm glad to hear that you're using the JKI State Machine in your projects.

 

Here is a trick that I like to use, that might accomplish your goals in a slightly different way:

 

Check if there are No Remaining States (no work on the queue). If so (no work), then wait forever for an event. Otherwise (if there is work still on the queue), check for events once (with a zero ms timeout). Then, when you are constructing work, you can interleave a "Check for Events" state (note that I have added the "Check for Events" string to the "Idle" frame of the state machine's Case Structure).

 

 

This bit of logic makes sure that the state machine's loop is only executing when it needs to be doing work. Otherwise, it's just waiting for events.

 

Now, if you really need to have wait states with specific timing requirements, you can either put a Wait (ms) function in your work state or have a "Wait" state that accepts a ms timeout argument, such as "Wait (ms) >> 100".

 

Thanks,

 

-Jim

[Francois Normandin]

Thanks Jim for the tips.

I will surely modify this template for many different applications. This particular example was for a modification to use the template as a FGV (note the Data:Initialize only on first call). I needed it to execute without delay and exit right away. But you're right, my problem is easily managed with Wait (ms) >> xyz. I don't really need all this overhead for a FGV, but I liked the idea of error handling, cleanup, etc. since speed is not an issue.

[Jim Kring]

Thanks Jim for the tips.

I will surely modify this template for many different applications. This particular example was for a modification to use the template as a FGV (note the Data:Initialize only on first call). I needed it to execute without delay and exit right away. But you're right, my problem is easily managed with Wait (ms) >> xyz. I don't really need all this overhead for a FGV, but I liked the idea of error handling, cleanup, etc. since speed is not an issue.

 

Oh, I see. Yes, when using the JKI State Machine as a Functional Global Variable (FGV) you might not even want an event structure at all.

 

I'm looking forward to hearing about the tweaks you find useful for other scenarios, too. At some point, we'll want to create a catalog of how to implement various design patterns with the JKI State Machine.

 

Thanks,

 

-Jim

[Francois Normandin]

I'm looking forward to hearing about the tweaks you find useful for other scenarios, too. At some point, we'll want to create a catalog of how to implement various design patterns with the JKI State Machine.

If this FGV design works good for me, I'll report my experience in "Tips & Tricks".