Modifications to the "Add States(s) to Queue"

[Mikael Holmstrom]

Hi

I’ve updated our version of the “Add State(s) to Queueâ€, with an input I call: EmptyQueueNextState

The value on this input will only be used (if the output value is about to be an empty string)

 

So why do I like this?

I normally use this entry all the time when I need to support queued event in a state and this state don’t have to be followed by a particular state.

It’s like the “Default†state this case will go to, if there is nothing in the queue then you go here.

 

My scenario is like this.

I use this input when I want to go from state A to B to C

But from an Idle state I need to run only B, and then go back to Idle again.

 

I could of cause add all states when I go to A in the queue (A,B,C), but I like it when it’s easier to see what default state a case will go to.

 

Comments?

Cheers,

Mikael

[Jim C]

Comments?

I feel like the jerk in Tom Hank's movie Big, but I don't get it. I make a macro when I want to go from A to B to C. I've gotten to the point where I only want a (non-macro or non-event-handler) state to direct execution to another state in exceptional cases, but not regularly. This makes it easier for me to see/change the sequence. For example, my latest project has a Macro: process UUT state which queues up all of the steps required to process a UUT without any special circumstances occurring. Only something out-of-the-ordinary would interrupt this sequence (like if a user's input fails a validation check). Any event coming from the Idle state would only trigger the state I want. If I want more than one state I'd create a new macro.

 

How does this new input help me?

 

Jim

 

PS - I've read many of your posts on LAVA and respect your work, hence the question.

[Mikael Holmstrom]

How does this new input help me?

 

Hi Jim

I can't answer right away how and if this new input helps you.

But I like to have a default transition from one state to another, but sometimes I like to borrow that particular state and not have that state add anything in the queue that I don’t know about.

This would happen if I use the “State(s) at Back†input.

I’ve attached a state machine where I’ve used this new input, please let me know how you would solve the problem.

I’ve also attached a State diagram of the state machine.

StateMachine_LV85_Main.vi

Cheers,

Mikael

[Jim Kring]

Hi Mikael and Jim C,

 

This is a very interesting discussion. I like exploring new ideas for ways to use and improve the JKI State Machine.

 

It seems, Mikael, that you are using the JKI State Machine as a hybrid between a finite state machine (where each state determines the next state) and a queued state machine (where states are queued up and then executed). For example, each of the work steps (Test A, Test B, Test C, Test D) is driving the subsequent work step, but only when there is nothing left on the queue.

 

What I would usually do in type of situation (as Jim C suggests) is define some macros that invoke all the needed functionality. For example, for a full test, I would create the following macro:

 

Macro: Full Test
  ----------------
  Test A
  Test B
  Test C
  Test D
  UpdateGUI

And, if a half-test is required, I would create the following macro:

 

Macro: Half Test
  ----------------
  Test A
  Test B
  UpdateGUI

The reason I prefer macros, and defining as much of the sequence up front, is that it is very readable. I don't have to scroll through every frame to try to reverse engineer the order in which my state machine will execute. Now, I see that you are using the Endevo GDS UML tool to reverse engineer a state diagram Still, I think that making work steps define other work steps, when it's not absolutely necessary, obfuscates the code by "hiding" pre-determinable sequences (macros).

 

BTW, the explicit call to "Idle" that you make is not required, if it's the last thing you want to do. The JKI State Machine will always go to an "Idle" state when there is nothing left on the state queue.

 

Thanks,

 

-Jim

[Mikael Holmstrom]

Okay, now I understand what you mean, and how you use the Macro concept.

Regarding the Idle case, I always have the habit of explicit put Idle as the next state to remove confusions.

But I see your point when using the Macro-approach.

 

BTW, it was really fun and challenging to develop the State Analyze function to work with JKI’s state machine. Especially when you have a queued sequence A-B-C.

And in State B a new state like B1 is added in the beginning of the queue so the result will actually be: A-B-B1-C

Cheers,

Mikael

[Jim C]

Now I get it! Here's how I'd do it:

StateMachine_LV85_Main2.vi