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

[CAI_Support]

I would remove TSTEQ from the picture, just say what ip1[1000] return.  That is simpler to comprehend for me.
For low to high going pulse, if say the pulse is low one hour, 5V for 500ms, IP1[1000] will return FLASE.
Same pulse, for high to low logic, the logic expect IP1[1000]  to return TRUE all the time.
 
The expectations are directly conflict.

 

[rossw]

I would remove TSTEQ from the picture, just say what ip1[1000] return.  That is simpler to comprehend for me.
For low to high going pulse, if say the pulse is low one hour, 5V for 500ms, IP1[1000] will return FLASE.
Same pulse, for high to low logic, the logic expect IP1[1000]  to return TRUE all the time.
 
The expectations are directly conflict.

 
That is exactly my point.
Using the tsteq and the value seems to me to be FAR more readable and "logical". It works, without needing to jump through hoops to tell the underlying code which way to expect the pulse to be. It means the SAME code could (for example) be used to decode slow NRZI data streams etc.

 

[CAI_Support]

TSTEQ only causes additional confusion, because evaluating each variable value is first step before TSTEQ compare.  Combine them in the discussion not helping.  By combine them, you are trying to say: when I compare with 0, I imply I want negative going pulse being counted, if I compare against 1, I expect IP1[1000] to count positive going pulse length.  That is good wish, but all compiler underlayer logic does not work that way. It always first evaluate each oprand's value, then compare.  The reason is that IPx[] already determined what kind of pulse will be ignored.
 
In logic, if you consider 5V is logic TRUE, you can not at same time treat 0V as logic TRUE.  If you say both 5V is TRUE and 0V is TRUE then I don't know what to do.
 
In addition,
TSTEQ IP[1000]  1
should get same value for IP1[1000] as
SET VAR1 IP1[1000].

 

[rossw]

SET VAR1 IP1[1000].

 
*IF* you interpret   "IP1[1000]" as meaning "HAS INPUT 1 CHANGED IN THE LAST 1000ms" this this is entirely unambiguous, and will always return "false" if IP1 has changed states from 0->1 or 1->0 (which includes 1->0->1 pulse or 0->1->0 pulse) in the last second.

 

[CAI_Support]

Okay,  you are saying we will deviate from what az1324 suggested before that when non-blocking delay is over, return current state, rather totally ignore current state, just return true or false based on if the delay is over.  That can be done, if that works.

 

[rossw]

Okay,  you are saying we will deviate from what az1324 suggested before that when non-blocking delay is over, return current state, rather totally ignore current state, just return true or false based on if the delay is over.  That can be done, if that works.

 
I'm not saying the other way is wrong, but there's so much confusion and uncertainty about how it works, and so many "built-in" limitations it becomes increasingly specialized in its application.
 
You know what the "current" state is by just reading the input.
If you wanted to know what the "original" state was some time ago, it probably should have been stored in a variable. That, or you will already intuit what the state was by where things are now (and that they're stable).
 
I'd love to see some "real world" applications where the requirement for "return true for a while, then return whatever the original value was" (or false, as the case may be).  How do those applications (or the firmware as described) handle multiple change-of-state within the time period? What is the "original" level for (say) a square-wave with noisy leading and trailing edges?

 

[az1324]

That seems ok.  I always try to think of how everything can be reduced to one line of code, but in this case it is too confusing.
 
IPx[y] only returns TRUE if the last state change of IPx is >= y ms ago
 
You will have to stop calling it a delay though.
 
What about VARx[y]?

 

[TJF1960]

But why think of it as the last state change. Why cant it just be if ipx has been 0 or 1 for [x] then true, if not then false.
I do agree it should be named something else and leave non block delay as is. Changing the code now could screw people up who already have working code using it.

 

[CAI_Support]

That seems ok.  I always try to think of how everything can be reduced to one line of code, but in this case it is too confusing.
 
IPx[y] only returns TRUE if the last state change of IPx is >= y ms ago
 
You will have to stop calling it a delay though.
 
What about VARx[y]?

So for Tim's PLC logic, in two sections, one expects IP2 stay low normally FLASE, going up 30 second will be TRUE, and the other section, IP2 normally stay high TRUE, going down 30 seconds will be FALSE.
 
After this logic change, consider there is no jitter noise, please note for each one of them, only during state change is FALSE, before IP2 state change and after state change plus delay, both will be return TRUE.
 
I don't think we want to change VAR or OP, their current work fine.

 

[az1324]

Yes that is fine so if that 30 second test returns true then you test the value of the input.  If it is not true then you don't bother reading the input and return.

 

[rossw]

So for Tim's PLC logic, in two sections, one expects IP2 stay low normally FLASE, going up 30 second will be TRUE, and the other section, IP2 normally stay high TRUE, going down 30 seconds will be FALSE.
 
After this logic change, consider there is no jitter noise, please note for each one of them, only during state change is FALSE, before IP2 state change and after state change plus delay, both will be return TRUE.
 
I don't think we want to change VAR or OP, their current work fine.

WIthout much thought, I'd probably do something like this:
This code will loop, waiting for ip2 to be unchanged for 30 seconds.
WHEN stable, it will execute either the "falling" code block or "rising" code block only ONCE for each transition.
(at least, I think it would, if the [delay] works to just return true or false for the specified condition)
 

main:
   tsteq ip2[30000] 0   ; has ip2 been stable 30 seconds or more?
   goto main   ; no, it has not.
   xor ip2 ram1b1  ; stable, but has it only just become so?
   bz main      ; no, so
   tsteq ip2 1 ram1b1  ; Is input 2 high? (Set ram1b1 to state of ip2 at same time)
   goto rising    ; This is the rising edge. Do something.
falling:
   (do other stuff here for the falling edge, ip2 just gone off for 30 seconds)
   goto main
 
rising:
   (do stuff, send email, turn on or off outputs etc)
   goto main

 

[CAI_Support]

Okay,  I am drawing a picture to show you what original logic would do and what you proposed would result:

 

[az1324]

Yes we realize it has a completely different output.  But you can still use it in combination with additional code to get the same result.  And it is easier to understand and more useful in the GENERAL SENSE.  You can't design a feature to one specific customer's requirement.
 
For example to get the same result as the old logic, just graph (IP2[x]' & IP2) where IP2[x]' is the new proposed value and IP2 is the realtime value of IP2, & is logical AND.

 

[CAI_Support]

To most users, I think it is a lot easier to understand the original logic, and add command to allow user to change IP2[x] to detect negative going pulse. That is a lot clear in logic.  If we implemented the proposed way, I don't even know what that called, totally do away from non-blocking delay.
 
In current shipping firmware, the logic will detect the positive going pulse longer than the non-blocking delay. If user has negative going pulse, he can configure the TTL input to invert.  I think that is very clean implementation. For this particular customer, he needs to detect both positive going pulse longer than certain time, and negative going pulse longer than certain time, in two different sections of PLC code.  Our proposed solution is to add another command, so that when he need to detect negative going pulse, he run this command, so that that particular TTL input will be inverted.  This way, it also has no impact on existing users who only need to detect one direction pulse longer than delay.

 

[az1324]

Ok.  I support the addition of a PLC command that will invert the input logic.  I don't necessarily agree that it is easier to understand or should be called a delay rather than a filter (since it filters all positive pulses less than [x]).
 
So with the existing behavior what if I want to detect a long pulse but also sample the input in realtime?  Is the delay going to prevent that?  For example:
 
TSTEQ IP1[1000] 1
CALLSUB MYSUB
SET VAR1 IP1
 
Maybe IPx{y} could return the test for last change suggested above. (curly braces)