03-26-2015 07:31 AM
Clint,
The reason that the Event Structure is inside the State machine (actually the Case Structure) is when a "Idle" or "Wait for Events" state has happened, it will go into that state and will sit idle until a user event happens, like a button press, without pooling for which button was pressed or some other non-GUI user event. This is the only area where you will see it.
03-26-2015 07:48 AM
I looked at State Machine Fundamentals.vi This shed a lot of light on my questions!! It allows me to do more. I think my code worked but this one is more robust...a picutre is worth a billion words..
Thanks everyone..
03-26-2015 09:12 AM
@Clint_Eastwood1000 wrote:
I have a state machine in side of an Event Structure. The user selects, for example, a menu driven event such as Funtional ( boolean chgs state) or Self Test etc. Once that event is selected the code runs changing from one state to the next until all the states have completed and the codes waits for another event to occur. One of my requirements is to make sure that the user doesn't open a door. The door is tied to an interlock read by a boolean in my code. I also have to constantly monitor an ABORT button (boolean) also. Is there a way to constantly monitor ABORT and the interlocks while running the events and then the state machines so that if either of these booleans become true I can run another vi ( ie: "soft shutdown"??)
Thanks..
If, instead of an internal state machine, you'll send user events with the state you want to perform, other events have a chance break in and abort the whole shebang.
/Y
03-26-2015 10:52 AM
Clint_Eastwood1000 wrote: I don't want the cal menu button or the self test menu button to do anything until I've completed functional test ( state to state) . Ones the user selects functional test button menu I want whats inside the statemachine in the event to complete before I monitor for another event such as cla button or self test button being pressed.
Use the Disabled property on your buttons. I recommend Disable & Gray Out for when you want to disallow the pressing of a specific button. This also helps the user know when something can't be done.
03-26-2015 11:29 AM
"""Actually, he has the structure as it should be. I have seen too many examples of programs that lock up because the developer forgot to get back and check for events. As I have demonstrated, building a state machine in the timeout event is a powerful way of structuring things.
Mike..."""
What I like about reading (Mikeporter) your blog (and I havn't read all of it yet) is that you have made a new discovery so to speak about state machines and
use of event structure; effectively turning the architecture inside out to address the common problem of state transitions taking away from the UI thread activity which we all know can make for a non responsive UI.
For me the jury is out on the implementation of your 'new way' versus careful implementation of the so called 'old way',
but again I have not yet read all of your thesis with total focus yet.
Nevertheless, what I really appreciate is that you have apparently not made such a big deal out of it as to go and call it an invention requiring a license. Thank you for sharing your very good ideas with all of us. I am a fan of your blog whenever I have extra time to read.
03-26-2015 02:42 PM - edited 03-26-2015 02:42 PM
@Clint_Eastwood1000 wrote:
So here is my program. Its stripped down a bit but I hope the idea is still there.
I know that I am a bit late to the party... and I know that you have reworked the code a bit, but I wanted to make a comment about the state machines you posted.
They aren't state machines.
What I mean is there is no logic going on between the states you have set up. It goes from "cal1" > "cal2" > "cal3" > "end". It does no logic. What you have built here is basically a complex stacked sequence structure. I have seen this farily frequenly where people call something a state machine, but have just a linear progression through "states".
04-06-2015 11:45 AM
So your example a statemachine would always be a choice between 2 or more different states based on something hapening? Where as in mine something is done in the "cal's x" and the next state ( sequence) always occurs?
04-06-2015 11:53 AM
04-06-2015 11:58 AM
@mikeporter wrote:
A state machine needs to have some possibly of taking a different path -- even if it's just to handle an error.
Like aborting your loop when there is an error.
04-07-2015 05:24 AM
Guess I should have understood the deinition of a statemachine better before I proceeded.. Now it makes better sense what previous posts were getting at. I thought what I had was a SM when in fact it was just " a sequence structure with all the inherent limitations of that pattern" Thanks..