Possible Bug - Event Structure Returning Same Values

[Will.D]

I'm not certain this is a bug, but it's certainly not the behavior I would expect.

I am attempting to get the newVal and oldVal values out of the event data node, and make a decision based on what they are.  The problem I'm running into is that they are the same.  No matter what the change.

I've attached a vi which shows this behavior (7.1).

I realize there are workarounds, but it would make my life easier if I could simply use those.  Also, should it not behave in this manner anyways?

Thanks for any comments

Message Edited by Novatron on 06-16-2006 03:56 PM

[Jonnie_5]

I think there's something weird going on because you're wiring data to the actual "success" terminal AND the value signaling property node (which is redundant).  Normal behavior happens if you delete the wire from the comparison to the "success" terminal.

[altenbach]

You are creating a classical race condition, because your value(signaling) property write lags one iteration behind the direct terminal write. You compare n-1 and n-2 in the shift register instead of n and n-1. BY the time the event triggers, the old and new values are the same.

(Note that a signaling value property write always fires the associated event, even if the actual value does not change. This can be very useful.)

I would recommend NOT to write to the terminal AND the property node at the same time, this is redundant. Also note that you only need one stop button and that the timeout case is not needed at all.

See attached.

[daveTW]

---

@altenbach wrote:

(Note that a signaling value property write always fires the associated event, even if the actual value does not change. This can be very useful.)

---

And it is always useful to read your posts. I didn't know that behaviour of Val(Sgnl). Five stars!
Dave

[Will.D]

Thanks to all for their replies. I should have realized this myself, but it was a very long week (no excuse though!).

Altenbach - In my actual program where I was using this I did not have two stop buttons, but a queue which controlled the stopping of more than just the two loops seen in the example I posted. I added them with expedience in mind. I do however appreciate always seeing faster and more efficient ways to accomplish things!

---

Altenbach said: (Note that a signaling value property write always fires the associated event, even if the actual value does not change. This can be very useful.)

---

I understood that the value(signaling) property fired an event regardless of whether the value changes, but I have a follow-up question. If the value(signaling) only appears in the true case of a case structure (as in my provided example), does the event fire every loop iteration anyways, simply because the property node is in the loop? I guess a less convoluted way to word the question is - If there is a value(signaling) property node in a loop, does it throw the event regardless of whether it is 'seen' during any given loop iteration? If so, why?

Thanks, Geoff

[altenbach]

No, it will only fire if the case containing the signaling property is active (TRUE case in this scenario).