LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed state machine

I want to implement a state diagram with the following states;

state one - if input is pressed stay in state 1

if 10s has passed or input 2 is pressed for more than 1.5s  moved to state 2

 

state 2- if input 3 is pressed move back to state 1

if 10s has passed moved to state 3

 

state 3 - if input 3 is pressed moved back to state 1

 

I having trouble trying to use the time elapsed function as it keeps resetting the timer. I want to find a way to reset the timer when in a certain state rather than when an event occurs (input triggered).

I have used the state diagram toolkit.

0 Kudos
Message 1 of 23
(5,950 Views)

CFarrelly wrote: 

I having trouble trying to use the time elapsed function as it keeps resetting the timer. I want to find a way to reset the timer when in a certain state rather than when an event occurs (input triggered).

I have used the state diagram toolkit.


Show us your code.

0 Kudos
Message 2 of 23
(5,944 Views)

An important feature of a state machine is that you can Abort it any time. So you should not have a state where you just purely wait. Imagine, you have one state where you would get stuck for 10 seconds. You cannot do anything (no abort, no other state transition) during this wait!

Solution: split up the waiting into small chunks! For example, there could be a "Check if time elapsed?" state where you check the elapsed time (Either using the Elapsed time express vi, or you code yourself a FGV Timer).

The trick is that, during a wait, your state machine keep "bouncing" between a "New action or abort requested?" and the ""Check if time elapsed?" states. You can put a Wait function with a small value like 10 msec into the "New action or abort requested?" (here you have different options, you could also put the 10 msec wait function into the "Check if time elapsed?" after time check, or using a timeout at the "New action or abort requested?" state, etc...) state...

 

If you do so, your state machine will Wait for the requested time target (like 10 seconds), but can be Aborted/moved to other state in 10 msec ANY time!

 

Right now I do not have time, but later I might put together a small example for you.

0 Kudos
Message 3 of 23
(5,941 Views)

Check out the JKI state machine. (VIPM can load it)

 

It has an event loop and timeout case built in. Set your timeout and if it expires do your next action.

 

mcduff

0 Kudos
Message 4 of 23
(5,888 Views)

Added my code here.

0 Kudos
Message 5 of 23
(5,864 Views)

That is one of the weirdest block diagrams I've ever seen. Unknown functions with no help, wires that can't be deleted and while loops attached to something else. I've never used the state diagram toolkit, but if that block diagram was created by that I might stay away from it. Seems like it's just going to make things harder in the long run. Look up basic state machines and go from there would be my advice.

0 Kudos
Message 6 of 23
(5,852 Views)

Hard to follow what's going on, but what is the value of the "reset" wire going into some of the elapsed time express VIs. Since the booleans controlling these values are in the outer loop, any changes you do while the inner loop is running will not be read, of course.

 

Then there are very convoluted code constructs such a the presence of three different elapsed time express VIs stacked and combined into a single blob (picture). I am not ever trying to figure out what this is supposed to do. 😄

 

timetimetime.png

0 Kudos
Message 7 of 23
(5,821 Views)

Hi Farrel,

Checkout the code attached. Is this you need?

0 Kudos
Message 8 of 23
(5,804 Views)

Kannan_Kn wrote:

Checkout the code attached. Is this you need?


Blatant over-use of local variables!!! Bad!

  • If you would place the boolean indicator (state x) terminals after the case structure, you would not need any of the local variables for them!
  • If you would place the boolean controls (input x) before the case structure, you would not need any local variables of them either.
  • It is not intuitive to have "switch until released" toggle switches. Use buttons!
  • ...

See if you can fix it!

0 Kudos
Message 9 of 23
(5,798 Views)

CFarrelly wrote:

state one - if input is pressed stay in state 1

if 10s has passed or input 2 is pressed for more than 1.5s  moved to state 2

 

state 2- if input 3 is pressed move back to state 1

if 10s has passed moved to state 3

 

state 3 - if input 3 is pressed moved back to state 1

 


Description seems incomplete. There are missing scenarios:

  • What should happen in state 1 if the input 1 is released?
  • What should happen in state 2 if input 1 is pressed?
  • What state should happen if no input is pressed?
  • What should happen if input 1 or 2 is pressed while in state 3?
  • What should be the state when the program starts?
  • You use "switch action" booleans, so the notion of "pressed" is poorly defined. Are you talking about switched from OFF to ON?
  • etc.
0 Kudos
Message 10 of 23
(5,789 Views)