What value for a timeout of an event driven state machine

[Soleil20]

Hello everyone,

I am using a simple event driven state machine for a test stand. Means I have a event structure with timeout and some other events within a while loop.
At the moment I call the timeout-event every 100 ms. With this setting I have problems in typing-in values in my front panel objects. I can type in something but if I press enter or tab or click somewhere else I need to have luck that this value was saved in that object and will be displayed there.
Has anyone any suggestions what could be a proper value for the timeout?


Thanks a lot!

Best regards,

Soleil20

[GerdW · Accepted solution]

Hi Soleil,

I am using a simple event driven state machine for a test stand. Means I have a event structure with timeout and some other events within a while loop.

Why do you need a timeout state at all?

I can type in something but if I press enter or tab or click somewhere else I need to have luck that this value was saved in that object and will be displayed there.

This problem is related to your VI. Unfortunately you did not attach that VI…

Has anyone any suggestions

When you have problems with your VI you should attach your VI!

[Soleil20]

Hello Gerd,

I did not attach my VI because the whole VI is programmed in german and this forum is in english and the main problem is, that I have restrictions to upload my source code.
I am using this structure because I want to switch between certain states (displaying certain tabs) with certain buttons like you can see in the picture. In the timeout event I handle the certain states.
You see for example in this picture that I am in the timeoutevent where a state called Messvorgaben exists. In this state I let the user interact with the front panel and am waiting for input in certain elements. Until the user don't want to go to another state (with for example one of the radio buttons) he stays in the Messvorgaben-state and the program is waiting for an event/input.

So again. If I type in something for example in a string indicator, there is a 50 to 50 chance that the input stays there and ist not deleted. I am sure, that this problem is linked to the value of the timeout.

Best regards,

Soleil20

[GerdW]

Hi Soleil,

I did not attach my VI because the whole VI is programmed in german and this forum is in english

Which is no problem for me… (Do you know the German www.labviewforum.de ?)

the main problem is, that I have restrictions to upload my source code.

Nobody forces you to upload critical code.

You can always create a mockup VI to explain/demonstrate the problems with your code!

I am using this structure because I want to switch between certain states (displaying certain tabs) with certain buttons like you can see in the picture. In the timeout event I handle the certain states.

- In the timeout event of the outer event structure you should not handle other states.

- there should be no "outer" and "inner" event structure at all! Rethink your program design!

You see for example in this picture that I am in the timeoutevent where a state called Messvorgaben exists. In this state I let the user interact with the front panel and am waiting for input in certain elements. Until the user don't want to go to another state (with for example one of the radio buttons) he stays in the Messvorgaben-state and the program is waiting for an event/input.

Rethink your program design…

So again. If I type in something for example in a string indicator, there is a 50 to 50 chance that the input stays there and ist not deleted. I am sure, that this problem is linked to the value of the timeout.

This most likely is related to your heavy overuse of local variables! Race conditions everywhere!

Rethink your program design!

[irPaul]

I side with Gerd on this.

Having two nested Event-structures is a bad idea, because now the nested structure can only respond to inputs when the "parent"-loop is in Timeout. Why are you using two loops? I can't see the full design, but usually one loop should suffice to capture all the Front Panel Events, and the inner state machine can act accordingly.

As for the local variables: they are nice, but cause race conditions. You *could* use Property Nodes and its error in/output to force proper flow control. But it would be better to re-think the VI structure, when & how to access Front Panel data. One advice could be to ring a cluster with your running variables.

[Soleil20]

I have this event loop in there because I have two buttons "load" and "save" on it. I thought at first on case structures with true and false handling, but it took to much space. So I decided to use a event structure. Maybe I should switch back to the first thought.

A cluster is a nice idea. I'll try this one.

But although the other stuff. The outer event structure should last and for that event structure I need a proper timeout. At the moment I switched it to 1s. So the problem minimized to a chance of 30-70. I tought that someone could have experience with UI inputs.

Best regards,

Soleil20

[GerdW]

Hi Soleil,

The outer event structure should last and for that event structure I need a proper timeout. At the moment I switched it to 1s.

The outer event structure cannot handle it's timeout event when it is busy with some other events…

I tought that someone could have experience with UI inputs.

I guess we have some experience with UI inputs. And we tell you to rethink your program design, so you use only one event structure…

[irPaul]

Can you supply some more information about the events and states? Preferably with a VI that is stripped of sensitive code, or otherwise at least an overview.

I am certain it is possible restructure the VI so you can handle *all* events in one Event-loop and the embedded Case-structure. Certainly you *have* to change it, because the current nested event-structure simply cannot achieve the desired predictable program flow (/behaviour). I'm speaking from experience - I also had to restructure my larger event-driven state machines more than once..

We just need some more info to think with you. 

[Soleil20]

Thanks for the tips. I will overthink the whole project.

Best regards,

Soleil20

[Ben]

I suspect the issue is you are using the FP controls to store data. While in simple code you can get away with that but for the most part FP controls and indicators should be viewed as I/O devices that allow users to enter info or view the info.

Store the data somewhere else (like an Action Engine) and then you can control when it get changed.

Ben