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

[CAI_Support]

When should IP1 state change recorded?  During delay, it should not record any change, am I correct?
If so, the only chance to record state change is when that delay is expired, at that one time, then start new delay.
next time, because the new delay already started. IP1 state change may not get recorded again.
 
That same line TESTEQ IP1[5000] 0
could have been executed 100 times to have the non-blocking delay expire.   What to do if IP1 state checking has non-blocking delay and no delay mixed,

 

[az1324]

What is "new delay" and "expire"?
 
The timestamp should always be set when the value of the input changes. 

 

[CAI_Support]

During non-blocking delay, the input state change is ignored, Only when that non-blocking delay is over, we will start reading IP1 input again and update during execute next IP1[] call.  With the next IP1[] call, it will start a new delay, whatever in that [].
 
There are only two state variables, current and previous. If we update current, we will update the previous at the same time. In all past version, we constantly read and update IPx states.  We sent to Tim a test firmware that only update IP1[] state when non-blocking delay expired.
 
So called expired is that if you set a 5 second non-blocking delay, you don't necessary come back and check this state, PLC logic could come back next hour to check the state, during that period of time, the non-blocking delay is expired.

 

[TJF1960]

Cai, az1324, not to change the subject but I am still wondering why in the example below with 30 second delay op1 turned off at the same time IP2 turned off, but changing to 5 seconds OP1 turned off 5 seconds after IP2 turned off. With the setup and everything being equal why would the 2 delays result in completely different outcomes?
 
START
                TSTEQ VAR7 2
                CALLSUB MEDIAOFF
END
MEDIAOFF:
                TSTEQ IP2[30000] 0
                SET OP1 0
                TSTEQ OP1[5000] 0
                SET VAR7 0
                RET

 

[CAI_Support]

I think that has something to do with your
TSTEQ OP1[5000] 0
                SET VAR7 0
line, which VAR7 value affecting how soon CALLsub mediaoff being called.

 

[az1324]

During non-blocking delay, the input state change is ignored, Only when that non-blocking delay is over, we will start reading IP1 input again and update during execute next IP1[] call.  With the next IP1[] call, it will start a new delay, whatever in that [].
 
There are only two state variables, current and previous. If we update current, we will update the previous at the same time. In all past version, we constantly read and update IPx states.  We sent to Tim a test firmware that only update IP1[] state when non-blocking delay expired.
 
So called expired is that if you set a 5 second non-blocking delay, you don't necessary come back and check this state, PLC logic could come back next hour to check the state, during that period of time, the non-blocking delay is expired.

 
I'm still not clear on what happens codewise.

 

[CAI_Support]

Let just think how the logic works, since I can not display the actual code. In posting #14, you suggested
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.
 
My question is, should IP1 state kept being updated all the time even during delay, or only when it being referenced updated checking the actual state?
When should the state be updated?  Are you suggesting that current state can change all the time, just keep a time stamp for the change, then each time reference it, update
 
Also, if no delay, IP1 just return current state.

 

[CAI_Support]

az1324,
 
 
 
I think it is confusing because the IP1 should returned value is compound with TSTEQ result.
 
Let consider just IP1[5000} should return what kind of value.
 
could your suggested logic  for IP1 value be simplified as
 
If last time IP1 changed over 5 seconds?
Yes: return current
No: return false

 

[az1324]

Well that is the problem.  Using non-blocking delay on inputs for other things than TSTEQ.  I am not sure how that would be useful or why you would want to freeze the state of an input program-wide.  I guess that is basically like setting your own sampling rate?  It seems like there is too much going on in the background that isn't documented such as how the following code would actually run:
 
START
SET VAR1 IP1[5000]
TSTEQ IP1[1000] 1
SET VAR2 IP1
END
 
or whether the following code would effectively sample the input every 10 seconds and the rest of the program could use that cached sample:
 
START
ADD 0 IP1[10000]
END

 

[CAI_Support]

az1324 and Tim,
 
We have logic can update the IP1 all the time, that was in the current shipping. Then we made change for Tim only update IP1's value when delay expired.
The idea for non-blocking delay on input is for remove small spikes.
SET VAR1 IP1[10000]
is a good test. 
If PLC code calling 10 second delay in one place, and 20 second in another, that will be a problem, so that if IP1 has non-blocking delay, everywhere reference IP1 should use same length delay..
 
What would be the correct value in VAR1 you think for this line for the IP1 terminal is 0, 1, before, during, and after delay:
SET VAR1 IP1[10000]

 

[TJF1960]

Then we made change for Tim only update IP1's value when delay expired.

I never could get the non-block delay code I was using to work so I ended up going a different route, but thank you very much for the effort.
 
 
 
I think the manual does need to go into much more detail in explaining the how's and whys of the non-block delay, for IPx, OPx and VARx. I have read the non blocking sections in the manual and read other posts which all seem to indicate that when an IPx or VARx change state it is time stamped. When a non-blocking delay line is called it is referenced to the last state change time. If that is the way it worked my code would have worked. But now with your explanations it turns out its not that simplistic. Which I am not sure why it can’t be. If TSTEQ IP1[1000] 1 and IP1 has a bouncy signal that line will not turn true until IP1 is stable and high for 1 second, which takes care of the spikes.
 
 
 
Maybe I am off base. If so I apologize.

 

[az1324]

SET VAR1 IP1[10000]
 
I would say it should be 1 only if IP1 is currently 1 and the last state change was >= 10 seconds ago.  If someone needs to trigger on 0 they can invert the input.
 
But if you do
 
SET VAR1 IP1[10000]
SET VAR2 IP1
 
Then VAR2 should always receive the current value of IP1 not the same value as VAR1

 

[CAI_Support]

Okay.
 
If IP1 currently is 1 and last state change was >= 10 second, return 1, otherwise return 0?
Any other thing to consider for IP1[10000] value?
 
So we don't care actually previous state any more,  only base on current value and state change time stamp.

 

[az1324]

That is my opinion, but it is potentially confusing no matter what.
 
It would be nice to be able to access timestamps which would be given in milliseconds ago
 
For example
 
TSTGT IP1TS 1000
CALLSUB MYSUB
 
So that IP1TS returns the # of milliseconds since IP1 last changed value

 

[CAI_Support]

The time stamp does not make any sense to the outside of the firmware, it is not based on second, and it is not the second from 1970, either.
I just send Tim a test code with this logic implemented, hope he can test out.
 
In Tim's original code,
TESTEQ IP1[5000] 0
will be true for non-blocking delay not expired, which should be
TESTEQ IP1[5000] 1
 
correct?  Otherwise, before the non-blocking delay is over, it will execute next line.