"Timeout" event reverts data to default

[danthecoffeecan]

I have a VI with a while loop which constantly checks and updates values in the VI. In the loop I have an event structure that executes when the "update" button is pressed, which performs some calculations which is returned to the wire, "Errors," which is highlighted in yellow:

I noticed that once the "timeout" event is executed after "Update value change", the data is lost and when the loop exits, the "Errors" wire is reverted to all 0. To my knowledge, there isn't a shift register for case structures. How can this data be saved after the "timeout" event executes?

[Intaris · Accepted solution]

Shift register on your loop and wire through all event cases.

[danthecoffeecan]

Ah, thank you!

[GerdW]

Hi dan,

---

@danthecoffeecan wrote:

I noticed that once the "timeout" event is executed after "Update value change", the data is lost and when the loop exits, the "Errors" wire is reverted to all 0.

---

THINK DATAFLOW: you set those tunnels to "default if unwired"!

---

@danthecoffeecan wrote:

To my knowledge, there isn't a shift register for case structures.

---

But for loops. Like this WHILE loop…

[billko]

---

@GerdW wrote:

Hi dan,

---

<snip>
THINK DATAFLOW: you set those tunnels to "default if unwired"!

<snip>

---

Warning: Pet Peeve ahead!

I HATE that the event structure default tunnel is "default if unwired".  It's an unnecessary point of failure.  I can only think of one possible reason you would want this, and that's so you can be lazy and use that for your loop exit - e.g., "Exit" Boolean default to FALSE, you only need to wire a TRUE constant to the event (or events) that are supposed to exit the loop after executing.  IMO, anything else being "default if unwired" is asking for trouble of the subtlest (and therefore hard to find) kind.  Having it this way for one use case is not the best strategy.  I'd much rather the default behavior being an "open" tunnel like all the other structures.  (This wasn't always the case, but that's a story for another topic.)

[JohnRich71]

It looks like you got your reply, but I have one observation. From what you posted there does not appear to be any code inside the timeout case. If there is not code in the timeout case then you should get rid of the timeout completely.

[danthecoffeecan]

Without the timeout, the VI gets stuck at the event structure if the button isn't pressed. The solution I implemented was to use a shift register on the while loop with the "max errors" wire going straight through the timeout event with a 10ms timeout.

[johntrich1971]

Are you running other code in the same loop as your event structure? Is that what you mean by getting stuck? An event structure is normally the only code in a loop.

[User002]

---

@billko wrote:

---

@GerdW wrote:

Hi dan,

---

<snip>
THINK DATAFLOW: you set those tunnels to "default if unwired"!

<snip>

---

Warning: Pet Peeve ahead!

I HATE that the event structure default tunnel is "default if unwired".  It's an unnecessary point of failure.  I can only think of one possible reason you would want this, and that's so you can be lazy and use that for your loop exit - e.g., "Exit" Boolean default to FALSE, you only need to wire a TRUE constant to the event (or events) that are supposed to exit the loop after executing.  IMO, anything else being "default if unwired" is asking for trouble of the subtlest (and therefore hard to find) kind.  Having it this way for one use case is not the best strategy.  I'd much rather the default behavior being an "open" tunnel like all the other structures.  (This wasn't always the case, but that's a story for another topic.)

---

For those who haven't seen it, there's an Idea Exchange to change this:

Output tunnels from event structure should default to NOT "Use Default if Unwired"

Loosely related Idea Exchange posts

Spoiler

1. A better way to define the output of unwired output tunnels (Worth mentioning, though I didn't Kudo it.)
2. Shift Register - Retain value if unwired (right terminal) (I really like what wiebe@CARYA and @Intaris made out of the discussion - if it were applied to all structures, it could be used to set defaults, too. I'm not actually in favor of the original idea by itself.)