How to run a particular case continuously in event based state machine architecture.

[RChoudhary]

I am making a program using event based state machine architecture, it is running as expected whenever i am generating an event, case structure corresponding to that event executes.

we are taking some measurements from oscilloscope e.g. i am having one boolean button for rise time whenever i am pressing that that button it displays the value of rise time, it displays only once( since i have generated an event on that boolean button so it executes only once and displays value for one time and then comeback to timeout state) but in our program what we want, we want it to update value continously once that button is pressed.

Now for a time being i have placed while loop on the case corresponding to rise time but this is not the right approach.

since i am using state machine architecture( event based ), i am not getting how to run particular case continuously ,or if there is any other better architecture that i can use to implement the same application.

Attached below is the program.

[mikeporter]

You could create a timeout event that contains all the stuff you have in the button event now, but get the timeout value from a shift-register that is initialized to -1. This value effectively disables the timeout.

Now when the user clicks the button you mentioned, set the value in the shift-register to 0 or 1 to turn on the timeout. Your code will continuously, but will be interrupted if some other event occurs.

Mike...

[moderator1983]

Say, in the attached program, when the user selects Autoset, it inserts corresponding state (Autoset) and now if you want this state to run again and again, probbbly you can again insert Autoset state while executing Autoset state... ohhh its confusing... check the picture below (A picture is worth a thousand words😞

1. Based on user selection, insert Autoset state.

2. Re-insert Autoset state again and again while executing Autoset state.

3. Now to come out of this loop, based on appropriate event generation, insert any other state AT FRONT (equivalent to Enqueue Element At Opposite End).

[mikeporter]

The OP mentioned that the state machine uses events - not a queue.

Mike...

[moderator1983]

---

@mikeporter wrote:

The OP mentioned that the state machine uses events - not a queue.

Mike...

---

You should check the code that OP has attached. I've just modified the same code to meet OP's requirement.

[RChoudhary]

Thanks mikeporter and moderator 1983 for reply

mike porter

I am using event based state machine architecture in which i am using queues to pass from one state to other .

and as you said i should put the code for boolean button in timeout case, for one button i can do like this but in case of multiple buttons i need to check for every button and second thing our program requirement is like once an event is generated we want it to run continously until and unless stop button is not pressed may be state machine might not be the good architecure for this type of application.

moderator 1983

i implemented the solution you suggested in picture, although with that approach i am able to run my case continuously as required but when i am trying to generate other event, program is hanging.

[moderator1983]

---

@Ritu wrote:

moderator 1983

i implemented the solution you suggested in picture, although with that approach i am able to run my case continuously as required but when i am trying to generate other event, program is hanging.

---

How are you enqueuing other states based on other events..??

I think you should focus on the difference between Enqueue Element and Enqueue Element At Opposite End functions.

Since for queue handling, you're not using LabVIEW native functions but a reusable library (State Machine.llb), you should identify the similar functions...!!

[dkfire]

The problem with moderator1983's change is that your code never gets to the event structure any more, as it will will never get a empty state or the Event handler state.

To be able to do what you want, you need to change the architecture to the Producer/Consumer.

In the Producer you will have the event structure, that alway is ready to handle events.

The producer will be your current state mashine, without the event structure. 

[mikeporter]

Unfortunately, NI keeps delaying the beta testing of the Android version of LV (yes, that's a joke...) so I couldn't look at the code. All I could see is what he said he was doing. The thing is, if you are using events already the queue is totally unnecessary because that functionality incorporates a queue as well. Why would you need two?

I also agree that a producer/consumer design pattern would probably be a good choice -- it all gets down to timing. The magic number to remember is 200 msec, because that is how long people will wait after clicking on a button before they decide that the program is "slow", "unresponsive" or "crashed".

I have built systems where everything is in one loop, but they are rare. I even built one where the program ran on an event structure but built a state machine in the timeout event because that is how the client understood their application -- which is an important point too.

Mike...

[moderator1983]

I admit, this will be a flaw/bug in my suggestion...!!