OK folks, troubleshooting a recursion loop and need a little S+ sanity check...
Summary question is if you have a wait/delay inside a change event, does the code after the wait/delay evaluate the input as the value that triggered the event or at the value that it is currently at when the wait expires?
As generic example as possible:
ANALOG_INPUT MyInput;
INTEGER MyValue;
CHANGE MyInput
{
WAIT(500)
}
MyValue = MyInput;
}
}
Lets say at 0 seconds, MyInput is set to 5d which triggers the initial change event. At 3 seconds (before the wait expires) MyInput gets changed again to 10d.
So my understanding is that the Change event would get called twice, but at the expiration of the first 5 sec wait MyValue would = 10d, then at 8 seconds (when second wait expires) the value would be changed to 10d again (even though it's already there. Is this correct?
Now lets assume we add the new THREADSAFE keyword infront of the Change:
THREADSAFE CHANGE MyInput
{
WAIT(500)
}
MyValue = MyInput;
}
}
In this case, assuming the same changes as described above, the second change at the 3 second mark should be ignored and a second change event should not be triggered. But... at the conclusion of the first 5 sec wait, MyValue should still be equal to 10d because it will evaluate to whatever MyInput is at the time that line of code actually runs, correct?
Also, will a CHANGE EVENT be triggered if a value changes to the same value? I.e. lets say you have 0d sitting at an input, if your Simpl code "twitches" so that the 0d is re-propogated, will S+ see this as a change event and retrigger?
Whoever replies, thanks in advance for the sanity check; my head is spinning here trying to figure out where my loop is happening (that is way to deep to get into...)
- Chris
