LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stop button during program wait in a state machine

Solved!
Go to solution

Hi,

 

I am trying to create a state machine in order to control a conveyor, mixer, pump, and linear actuator. Each component runs in a sequential order all the time, so I figured that using a state machine would probably be the best program architecture.

 

The problem I am experiencing is that there are some states that require extra time before the next state begins. For instance, I need to be able to run the pump or the mixer for a different period of time. I understand that simply using the wait VI is not a good idea since it removes the ability to stop the program in the chance that something goes wrong (at least until the wait function completes execution). I tried using clock timing in order to force the program to wait for a specified time between states, but I ended up with nested while loops for each state that require separate stop buttons which ends up making the program convoluted (this is what is seen in the attached VI).

 

I looked on other threads that mentioned using notifiers or event structures, but since I am using a state machine, I am not sure how to use them with mutliple states.

 

If there is any way to force timing between states while maintaining stop button control and possibly the ability to run other code during the wait, please let me know. I have attached the VI I am working on, and the main focus is on the "Wait for hatch to open" state.

 

Thanks.

0 Kudos
Message 1 of 15
(4,843 Views)

Make a common state called wait that you can use.

 

In this state put an event case with a timeout for your wait period. Add a case for a stop button. If the cases timeouts then go to the next case. If the user hits stop then go to your safe shutdown state sequence.

 

mcduff

0 Kudos
Message 2 of 15
(4,817 Views)

What you need to do is have the wait state call itself if the wait condition has not completed.  Here is a very quick example to show the idea.  But what this does is allow for checking of stop conditions or other things you have to be constantly aware of.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 15
(4,815 Views)

Can wiring the wait time to the timeout case in an event structure that the stop button operates with work? That way it will wait the time specified unless the stop button is pressed, and if the stop is pressed the event will immediately change to the stop event.

0 Kudos
Message 4 of 15
(4,810 Views)

State machines can be quite limiting actually, but since youre already started with one a simple solution to your problem could be to put a secone loop with an event structure outside the state machine and write to a local variable if the state of the stop button changes.  Youll have to reinitialize the stop button though.

 

Attached is a simple example. 



-Matt
0 Kudos
Message 5 of 15
(4,803 Views)

@matt198717 wrote:

State machines can be quite limiting actually, but since youre already started with one a simple solution to your problem could be to put a secone loop with an event structure outside the state machine and write to a local variable if the state of the stop button changes.  Youll have to reinitialize the stop button though.

 

Attached is a simple example. 


A hammer is quite a limiting tool also, but if the problem is a nail, then it's the right solution...

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 6 of 15
(4,792 Views)

Hi crossrulz,

 

Thanks for the reply. 

 

This seems like a solution that would work, but how would I be able to tell the program which state to proceed to next if the wait state is shared between the other states? I assumed that the strings are supposed to represent the states, so now I am confused about a solution to change the "Complete" state to correspond to the next state (which changes depending on the previous state). Also, I would need to be able to change the Time Target depending on the previous state as well, but I don't want to have to use shift registers that carry values that don't change.

 

Thanks.

 

0 Kudos
Message 7 of 15
(4,727 Views)

I would suggest that you look into the JKI State Machine and refactor your code. You can download it via VIPM. It has a built in event case.

 

There are lots a things that you can do to make your code better, for example, have a State called current status, that way you wire directly to the indicator not write to a local variable.

 

Cheers,

mcduff

0 Kudos
Message 8 of 15
(4,720 Views)

victorzhao wrote:  but I don't want to have to use shift registers that carry values that don't change.

What I do is use strings for my state and then add parameters to the string.  So I might have a state string of "Wait:1.5:Complete".  I would use Match Pattern to get the state to actually go into (for the case selector) and then parse the rest of the string to know to wait 1.5 seconds and go to the "Complete" state when the time has elapsed.  The JKI State Machine does something very similar.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 15
(4,716 Views)
Solution
Accepted by topic author victorzhao

Let your state machine shift register be a cluster.  First item is an enum to tell the next state to go to.  Second item is a numeric that would define how long to wait if the next state is a wait.  Third item is another enum like first to tell which state to go to after the wait ends.

 

Beginning of your state machine loop, unbundle the first item to know what state to go to.  In your wait state, when you've determined the wait is done, unbundle the 3rd item.  Set the state machine cluster's first item to be that same enum so it goes onto the next state.  Basically let the state machine's shift wire carry along with it other state state, not just the next state, but also what the following state would be when the next state is complete (in the event there are multiple choices.)

Message 10 of 15
(4,703 Views)