Multiple WAIT_UNTIL on same variable
Spire_Jeff
Posts: 1,917
Anyone know how WAIT_UNTILs are evaluated? Take this example:
Will all three events fire at when the connection is made? If only one event fires, is the WAIT_UNTIL queue FIFO, LIFO, ....???? Any ideas?
Jeff
function1(){
wait_until(bConnected){
bConnected = 0;
do something;
}
}
function2(){
wait_until(bConnected){
bConnected = 0;
do something;
}
}
function3(){
wait_until(bConnected){
bConnected = 0;
do something;
}
}
button_event[dvTP,1]{
push:{
function1();
function2();
function3();
}
}
timeline_event[tlComm]{// fires once every 10 seconds
fnConnect(); //sets bConnect = 1 on successful connection
}
Will all three events fire at when the connection is made? If only one event fires, is the WAIT_UNTIL queue FIFO, LIFO, ....???? Any ideas?
Jeff
0
Comments
I will see if I can run a quick test and post the results.
Jeff
Jeff
wait_untils are evil. A puppy dies every time you use one.
Paul
and who said programmers don't have a soft side!
I use wait_until regularly for warm up times on equipment. I have a few simple rules to make sure they never cause me any trouble:
1) Make absolutely sure what you are waiting for is really going to happen.
2) Take another look at rule #1.
3) Name your waits so they can be canceled and so they stack properly.
4) Stick to very, very simple and SHORT timing situations. Anything even remotely complex should be in a timeline.
I think that #3 is the issue for the OP. Name those waits and it should work as expected.
I agree with 1, 2 & 4. 3 is situation dependent. In my case, I don't need to cancel the waits at any time so naming them is not necessary. Because I am calling them from functions, the wait is only created at one place in code so NetLinx will prevent multiple instances based on the default identifier.
The way my actual code is written, the execution of the code inside the waits is conditional and if they do get executed out of order, it doesn't matter. Basically, I only send one command each time the web connection is opened. Step C is the important step, but step C requires that step A and step B have been done based on a specific part of Step C. The program tries to execute C as long as there are queued commands. They way it is written, it doesn't matter which order the functions are called because only the appropriate step will actually be executed. Upon execution, it kills the connected variable and ensures that only the one command is sent during the connection. I am sure that in a week or two I would be horrified with the complexity I have created and I might be able to rewrite it to be more human friendly, but at this point, it works reliably and does not seem to overload the processor, so I am temporarily happy with it
Jeff