Non-Blocking Delay on IP2 broken v03.02.17e Bug?

[TJF1960]

I have been going round and around with my code trying to figure out why OP1 is turning off right after IP2 turns off. Here is the block of code:
 
MEDIAOFF:
 TSTEQ IP2[30000] 0
 SET OP1 0
 TSTEQ OP1[5000] 0
 SET VAR7 0
 RET
 
I finally set non-block delay to 5000 then there is a five second delay before OP1 turns off, but 10000 and higher causes the output to turn off right away after IP2 turns off.
 
Cai, can you check if a bug? I didn't have any more time to test other IPx's or OPx's for the same problem.
 
Thanks,
Tim

 

[CAI_Support]

Are you saying you will change IP2 from high to low during the 30 seconds non-blocking delay, which will cause OP1 OFF?
Where OP1 was turned on?
 
Please note when your have
TSTEQ IP2[30000] 0
 SET OP1 0
 
TSTEQ will get IP2 previous state, which is not showing was set to zero or 1 before.  If that state was zero, it will immediately execute
SET OP1 0
line.

 

[TJF1960]

TSTEQ IP2[30000] 0
 SET OP1 0
 
TSTEQ will get IP2 previous state, which is not showing was set to zero or 1 before.  If that state was zero, it will immediately execute
SET OP1 0
line.

The original state of IP2 was 1.
What I am saying is this sets OP1 0 right away:
TSTEQ IP2[30000] 0
 SET OP1 0
 
Whereas this delays OP1 0 by 5 seconds:
TSTEQ IP2[5000] 0
 SET OP1 0
 
Thanks,
Tim

 

[CAI_Support]

TTL input logic has not changed for years.  That portion logic was not changed in V3.02.17e.
We just sent you an update firmware that modified behavior to see if that working for you?

 

[CAI_Support]

We need to ask smart people on this forum about the best way to handle non-blocking delay on TTL input.
WebControl has its IO sub system constantly check input state from all TTL input once it powered on.
When PLC sub system execute and run into non-blocking delay on IPx[] the first time, its previous state could be ON or OFF. That is the value read back from that IPx[].
 
We could change logic for IPx[], once we see in PLC code non-blocking delay, no longer allow IO sub system update IP state, only when PLC non-block delay over check the IPx state, then set previous state at the same time.
 
What is your suggestion on best way handle non-blocking delay on TTL input?  Please note non-blocking delay on TTL input are totally separate logic from OP and VAR. We only discuss for IPx here.

 

[TJF1960]

Cai, Between PM'ing and this thread, I am getting real confused on Non-Blocking Delay (NBD) use for Inputs. So in the interest of public opinion (and since you asked for help from smart people on this forum, of which apparently I am not one) lets continue here.
 
This is the explanation from the manual  (version .17e)
 
"When the delay operator is used on input operands the current value of that input is only used if it has had that
value for greater than the delay period specified between the brackets."
 
So, given that statement, am I correct to assume the following?
 
If IP2 has been 1 for 60 seconds then TSTEQ IP2[30000] 1  would be true, correct?
 
If IP2 has been 1 for 60 seconds then TSTEQ IP2[61000] 1 would be false, correct?
 
 
If IP2 has been 0 for 60 seconds then TSTEQ IP2[30000] 0 would be true, correct?
 
If IP2 has been 0 for 60 seconds then TSTEQ IP2[61000] 0 would be false, correct?
 
Thanks,
Tim

 

[CAI_Support]

Tim,
 
You are one of the smart people here, we appreciate your input very much.  This non-blocking delay has not been changed for a long time. Now, since you are using it and having question, we want to borrow you and other people's brain to get this thing changed to a way everyone think correct.
 
1) If IP2 has been 1 for 60 seconds then TSTEQ IP2[30000] 1  would be true, correct?
Yes, after 30 seconds, IP2 will return 1, but before that 30 second is over, it return previous state.
 
2)If IP2 has been 1 for 60 seconds then TSTEQ IP2[61000] 1 would be false, correct?
It is not necessary correct, it depends on previous state and current state. If IP2 is 1 for 60 seconds than turn it off, it will be previous state.  Please note when you execute this same line PLC code again, it will continue checking the non-blocking delay is over or not.
 
3)If IP2 has been 0 for 60 seconds then TSTEQ IP2[30000] 0 would be true, correct?
the return value is previous state during delay, and 0 after delay is over.  Please note when you run PLC code,  this same line is being execute over and over again, only the first time delay over, current state will be set to 0, previous state has last current state value.
 
4) If IP2 has been 0 for 60 seconds then TSTEQ IP2[61000] 0 would be false, correct?
It will always return the previous state.
 
Now, the last testing firmware we sent to you yesterday will allow IO subsystem update IP2 state once delay is over.  We are thinking maybe once there is non-blocking delay for that IPx[], we will not allow IO subsystem update that particular IPx[]. Only the non-delay logic can change its current state and previous state.
 
We appreciate you keep posting your idea, customer's request is always good input

 

[TJF1960]

Thanks for your patience.
 
I understand your answer to #1, I get that (at least I think). What I don't understand is your answers to #2-4.
 
How about I ask what I want to happen and you help me with some code.
 
Anytime IP2 is 0 for 30 seconds or more I want OP1 0.  (IP2 is either 0 or 1 for long periods of time, like 1 minute or longer, nothing in between.)
 
So I thought that this would work fine:
 
TSTEQ IP2[30000] 0
SET OP1 0

 

[CAI_Support]

There are two sub systems that affecting the reading of IPx state, one is IO sub system, which constantly update IO state, another is PLC engine, each time when it reference IPx state, it will check IPx state,  When there is non-blocking delay, PLC engine will not read IPx state until the delay is expired.
 
These two subsystems operate independently.  Between PLC code execute TSTEQ IP2[30000] 0 line first time and 2nd time, IO subsystem may read IPX state and update its status.  In the test code we provided to you yesterday, we disabled IO subsystem from updating IPX state during non-blocking delay in effect. 
 
Now, if the non-blocking delay running in PLC engine is expired, but have not execute the TSTEQ IP2[30000] 0 line next time, IO subsystem could be able to update the IPx status, if its state could change quickly.  So when your PLC code running on the TSTEQ IP2[30000] 0 line next time, IPx state for current and previous could be changed already.
 
We are proposing to change it so that if any IPx using non-blocking delay then IO subsystem will no longer update that IPX state. Say in your example, you use TSTEQ IP2[30000] 0. then we will let IO subsystem no longer update IP2 state for entire PLC code.  Since both sub systems are on when power up, and PLC logic may not run into TSTEQ IP2[30000] 0 line first time till  few milli second later, IP2 state could still be changed back and forth a few times during power up. 
 
To make things even more complex, user can configure the IPx reversed between ON and OFF. Whatever the logic implemented, we must treat 0 and 1 the same way, otherwise when input reversed logic will not work.

 

[TJF1960]

Still trying to figure out why I am getting mixed results with non block delay.
 
If TSTEQ IP2[30000] 0  is in a sub routine and this sub is called after IP2 is 1 for a few minutes is the previous state then considered to be 0? 

 

[CAI_Support]

The test version we sent to you allowing IP2 state being updated once the non-blocking delay is over.
However, once a new delay is started, it will send previous state for that moment, till non-blocking delay is over.
 
I think it might be helpful to just discuss how do you think this should work, then everyone can contribute his opinion, we can then make change based on that.
 
At the mean time, this portion logic in current deliver version is based on previous logic having not been changed for three years. Once again, this discussion is only about non-blocking delay on the TTL input.

 

[TJF1960]

What I thought I understood is based on this statement from the manual “When the delay operator is used on input operands the current value of that input is only used if it has had that value for greater than the delay period specified between the brackets.” and from Lou Apo’s thread here http://cocoontech.com/forums/topic/22849-cai-webcontrol-non-blocking-delay-function/
 
For the most part it has worked as I thought I understood it. But it can be much more complicated than that. Quite simply I thought that the non blocking delay would test the current value and become true once that value and the time period was met. For instance take this line: TSTEQ IP2[30000] 0. I thought there were two possibilities. 1) If IP2 is currently 1 then this would be false. Once IP2 became 0 for 30 seconds then it would be true. 2) If IP2 were already 0 for 30 seconds or longer then it would be true the minute the line was read.
But it seems it is not as simplistic as that. If the first time that line was read the value of IP2 was 1 then the minute IP2 becomes 0 the line will be true because it is based on the previous state not the current state. That is where I have made my mistake, I thought it was based on the current state.
 
The thing that really baffled me into thinking this was a bug was the way this section of code was working:
 
START
                TSTEQ VAR7 2
                CALLSUB MEDIAOFF
END
MEDIAOFF:
                TSTEQ IP2[30000] 0
                SET OP1 0
                TSTEQ OP1[5000] 0
                SET VAR7 0
                RET
 
Sub routine MEDIAOFF is called well after IP2 is 1 (anywhere from 5 minutes later to a couple of days later). I expected once IP2 was 0 for 30 seconds that OP1 would turn off. What I found was that when IP2 turn off (0) OP1 turned off right away, no 30 second delay. But what really made me think this was a bug was if I changed the 30 seconds to 5 seconds it worked fine (on version 03.02.17e). The firmware you sent me (03.02.17fb3) would turn off OP1 right away whether the delay was 30 seconds or 5 seconds. I understand now why it is working that way.
 
Sorry for the long winded explanation.

 

[CAI_Support]

Thanks for taking time to write them down, Tim.
The idea of non-blocking delay on IPx is to filter out shorter pulses than the delay time. However, there is an issue added complexity, that is we allow reverse IP state.  So that the shorter pulses could be 1 going or 0 going. In addition, before non-blocking delay started, the IPx state could have been up and down many times.  What was the previous state is actually hard to predict.
 
When you make IP2 to logic 1, TSTEQ IP2[30000] 0   will return previous state, that is 0, so that TSTEQ is true.  In another word, if the IP2 was 1 already, the test your performed will get 0 because previous state is that.  You actually want the IP2 return 1, so that next line will not execute.
 
What about change TSTEQ IP2[30000] 0 to TSTEQ IP2[30000] 1
would that work the way you wanted with 17fb3 firmware?  Or if you don't change the code, but configure IP2 to reverse state in IO configuration?
               

 

[az1324]

It should work like:
 
TESTEQ IP1[5000] 0
 
Is IP1 0 now?
No: Return false.
Yes: Was the last time IP1 changed greater than or equal to 5 seconds ago?
No: Return false
Yes: Return true.
 
So previous state should not be relevant.  Only time of last change.
 
 
It would also be useful to have access to these timestamps:
 
SET IP1TS VAR1 //Set VAR1 to the timestamp of the last time IP1 changed

 

[TJF1960]

It should work like:
 
TESTEQ IP1[5000] 0
 
Is IP1 0 now?
No: Return false.
Yes: Was the last time IP1 changed greater than or equal to 5 seconds ago?
No: Return false
Yes: Return true.
 
So previous state should not be relevant.  Only time of last change.

 
Thanks az1324, That is how I thought it should be also (and you explained it in only a 5 lines, took me 15 pages and it still wasn't clear!
 
Cai, wouldn't this logic still work for IP filter?