is there a race condition between events and newValue in case?

[Hummer1]

I am using the change value event to kick off and event structure.

Withing the enent structure, I want to do one action if the new value is True and a different one if the new value is false, So:

I place a case structure inside the event structure to sort out what kind of value change I had.  Here's the problem.

When the event fires, I am using the "NewValue" terminal of the event structure to get the "NewValue" of the control that changed, and using that to control the Case Structure T/F selection.  It seems that the event fires, and the NewValue is still the OldValue, because the case that runs is the case defined by the state that the control used to be in.

Example:

I cause a Value Change event using the Property Node Value(Singnaling).

The Value is changed to True.

The Event which runs in response to the value change runs.

The Case within the event, which is selected by the NewValue of the Event Structure, selects the False Case...which runs.

I cause a Value Change event using the Property Node Value(Signaling)

The Value is changed to Fales

The Event which runs in response to the value change runs.

The Case within the event, which is selected by the NewValue of the Event Structure, selects the Trus Case...which runs.

Any thoughts?

Sorta Humming Along

[mikeporter]

I use this functionality extensively and have not run into this issue. Can you post your code for us to look at? It sounds like there might be something else going on...

Mike...

[altenbach]

I agree with Mike. I've never encountered a problem.

Could it be you have some wires crossed? (Maybe the wire is actually connected to "oldval")?

What is the mechanical action of the boolean?

Here's a quick test case that works 100%.

Message Edited by altenbach on 06-20-2008 07:51 AM

[Hummer1]

I can't post the code...or send it to you.

Let me build a sample on the same machine and see If I can reproduce the effect.  In the mean time I will make sure the case T/F definition is connected to the right terminal.  If It is supposed to work, then I will look elsewere for the problem.

Thanks.

[TCPlomp]

I can think of one source:

Is your Event structure up to date?

If you generate two value signalling events in a row, each of them will be processed. It can happen if you have wrong setup (the event structure isn't directly executed but waits at some point) you could get some history.

Ton

[MScap]

hi

there should not be any problem with the event structure, as others mentioned.

if you cannot post your vi, send a screenshot of the B.D, which might give us a clue.



Message Edited by MScap on 06-23-2008 06:53 AM

[Hummer1]

Thanks,

I am working on the example to try and construct it as I am using the features.  It will take a bit.

Thanks...It may very well be a history issue...it it pretty reliably alternating between the present value and the past value.  Let me play with it a bit and then add to this thread if I figure out what is actually happening.

[Hummer1]

Well, why anyone would want to do this, I don't know, but here is a sample.

Under some conditions, the led's behave as you would expect.  Under others, they do not.

If switch 1 is set to true and goes to false...then switch 2 is moved from true to false, noting happens, since there has been no "change".

Interesting.  I don't know if this is the problem I have set up in my code, but it is an interesting example of "overtaking the plumbing" as Scotty would say.  (My apologies if you are not Star Trek fans).

Humm

[altenbach]

You need to know that firing a "value changed" event via a value signaling property ALWAYS fires the event, event is the old and new values are the same.

[GerdW]

Hi Humm,

after removing almost all of your RubeGoldberg code the vi works as expected
But why do you use "value (signalling)" property nodes for your indicators when you only check events for the "switch" controls???



Message Edited by GerdW on 06-24-2008 05:31 PM