What value for a timeout of an event driven state machine

[altenbach]

---

@Soleil20 wrote:

At the moment I switched it to 1s. So the problem minimized to a chance of 30-70.

---

Computer programs are deterministic and if you spend any time minimizing probabilities of correct operation, you are digging in the wrong place.

We really cannot debug your picture (what's in the other event cases or case structure cases? How are the events configured? etc.), but we can immediately tell that the architecture is completely wrong and there are glaring mistakes that will bite you no matter what you tweak. Are you aware that event structures queue up events even if dataflow prevents them from handling them? If they are set to lock the front panel in such a situation, the program will permanently lock up.

All you need is a single outer loop and a single event structure unless some operations are lengthy, in which case you should do a two-loop consumer/produce architecture, handling the tasks out of band from the event structure.

So, sit down and redesign everything with this in mind. Feel free to attach a simplified version so we can give advice.

[Soleil20]

Hello,

I reordered my whole program. I put the events of the inner event structure into the outer, so that I eliminated all event structures and now only have the outer one.

I elimnated nearly every local variable and put there a property node. But for my radio buttons I can't find any proper one. Behind these radio buttons are normal buttons with true or false state.

Best regards,

Soleil20

[GerdW]

Hi Soleil,

I elimnated nearly every local variable and put there a property node.

Better use wire instead of locals or property nodes!

"value" Property nodes per se still allow race conditions, they are just much slower than locals…

But for my radio buttons I can't find any proper one.

Your radio button will have the same "value" property node as any other control: right-click it's terminal and create->property node/local/whatever…

[Soleil20]

       Better use wire instead of locals or property nodes!

For that I should use a cluster, which feeds into a shift register?

      Your radio button will have the same "value" property node as any other control: right-click it's terminal and create->property node/local/whatever…

I know that. But I don't want to get true or false. At the moment I am handing over a type def [Projekt, Messvorgaben, Stoßkreis, Messung, Diagrammaufbereitung, Einstellungen] to the local variable.

[irPaul]

For that I should use a cluster, which feeds into a shift register?

That's the way I do it. Maybe GerdW has even better ideas.

To me it's not clear what you mean with the radio buttons. You have the 5 buttons on the front panel, which essentially dictate the state the program is in, correct? So you just want to change the state-indicator (your typedef) to the corresponding state when one of these radiobuttons switches to True?

[altenbach]

---

@Soleil20 wrote:

I elimnated nearly every local variable and put there a property node.

---

That makes no sense! I assume you mean value property nodes which are functionally the same as local variables. You better replace them again with local variables unless wires are an options (they almost always are). Feel free to illustrate what you are saying with a VI or at least a picture.

---

@Soleil20 wrote:

Behind these radio buttons are normal buttons with true or false state.

A radiobutton control is a special container that only contains booleans (any!) and with the built-in functionality that only one can be true and that the value is the name of the currently active boolean (similar to an enum). These booleans are "inside", not "behind". Something does not sound right.

---

@Soleil20 wrote:

For that I should use a cluster, which feeds into a shift register?

---

 Again, that makes no sense what does a "cluster" or "shift register" have to do with a suggested wire?? You seem to be pulling random terms out of thin air!  Again, you need to illustrate what you are saying with a VI or picture.