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

[CAI_Support]

No, we have not implemented IPx{y}.
I was wondering if IPEDGE could help Tim.
We are reluctant to implement IPRx[], because it will use 8 IO IDs.  But this seems can save a lot of troubles to switch inverting, or using several line of code to calculate. 
 
This is also help for you and Ross to implement communication protocol to other sensor or device.

 

[az1324]

I think the following should be implemented:
 
IPINV
IPEDGE
IPTS
IPx{y}
 
Using IPINV with IPx[y] is not much trouble.  IPINV should be readable too.
 
Few lines of code is a small price to pay for easier to understand.

 

[CAI_Support]

I think IPINVx[y] and IPx[y] can do IPx{y} suppose and better.  Because IPx{y} requires to run IPEDGE first,
IPINVx[y] and IPx[y]  does not need to.  They return the same result.
 
For IPEDGE command, we also need clarification if we need to clear the internal counter from previous result, because the time was counted from either falling or rising edge.

 

[az1324]

IPx{y} does not require one to run IPEDGE first if one only wants to determine whether the input has not changed since IPEDGE default is both.
 
IPINVx[y] and IPx[y] are too confusing.  One would have to use several lines of code to get the equivalent of IPx{y} when IPEDGE is set to both?
 
Yes whenever IPEDGE is changed it should reset the timestamp if it is not valid.
 
IP is high and IPEDGE changing from falling to rising:  invalid
IP is high and IPEDGE changing from falling to both:  invalid
IP is high and IPEDGE changing from rising to falling:  invalid
IP is high and IPEDGE changing from rising to both: valid
IP is high and IPEDGE changing from both to falling:  invalid
IP is high and IPEDGE changing from both to rising:  valid
 
IP is low and IPEDGE changing from falling to rising:  invalid
IP is low and IPEDGE changing from falling to both:  valid
IP is low and IPEDGE changing from rising to falling:  invalid
IP is low and IPEDGE changing from rising to both: invalid
IP is low and IPEDGE changing from both to falling:  valid
IP is low and IPEDGE changing from both to rising:  invalid

 

[CAI_Support]

Thanks for you detailed analysis, we really appreciate your expertise. To better understand these proposed commands, we thought about them and have some observation to discuss here. We thought about these and think because IPEDGE may clean out timer, IPx{y} and IPTS could return wrong reply for certain situation.  If not running IPEDGE, directly check IPx[y] and IPINVx[y] will not have that problem.

 

[az1324]

Yes that's possible but it is up to the user to use the commands properly.  The IPx[y] and IPINVx[Y] don't give any way to get the actual length of the pulse if you want to measure it.  They are too limiting.

 

[CAI_Support]

If IPTS already provided timestamp for last state change, would be IPx{y}  still useful?  Since PLC logic immediately knows from last state change it should be 0 or 1.

 

[az1324]

Shortcut & given in milliseconds.
 
SET RAM1 IP1{10000}
 
is equivalent to
 
IPTS RAM1 1
TSTGE (value of 10 seconds in ticks here) RAM1 RAM1

 

[CAI_Support]

Thanks for demo code. I thought  IP1{10000} will return TRUE or FALSE, not timestamp.
 
 It would be like
IPEDGE 1 1
 IP1{10000}
 
vs
 
IP1[10000]
 
or if input is inverted
 
IPINV1[10000]
 
to get TRUE or FALSE. To find out the state change time stamp, it still has to use IPTS
 
Anyway, I think we should implement IPINVx, IPEDGE, and IPTS first, that seems helps to solve certain needs.  We want to reach to a version that will be for standard shipping.  Then add other features as alternate firmware. 

 

[az1324]

IPx{y} is true or false but not depending on state of the input only timestamp.
 
Whereas:
 
IPINVx[y] only true when input is low
IPx[y] only true when input is high
 
So I guess you would have to OR them to get the same result.  Confusing.

 

[CAI_Support]

If we converted our internal timestamp to millisecond, it would be a slow process. We will just provide a time stamp number, hope user can figure out without us converting it to milliseconds.

 

[az1324]

You don't convert the timestamp to ms you convert {y} to ticks.  You can even do it in the javascript.  Isn't that how it works with [y]?

 

[CAI_Support]

I am talking about IPTS returned timestamp.  This is from running inside PLC engine.
 
In the implementation, we also noticed IPEDGE could cause IPTS not function properly, because when setting timestamp only being updated for falling edge or rising edge, it will cause in some case, IPTS not getting certain last state change timestamp.
 
Since we are implementing IPINVx[y], we can skip this IPEDGE actually, so that we record timestamp all the time.

 

[rossw]

I am talking about IPTS returned timestamp.  This is from running inside PLC engine.
 
In the implementation, we also noticed IPEDGE could cause IPTS not function properly, because when setting timestamp only being updated for falling edge or rising edge, it will cause in some case, IPTS not getting certain last state change timestamp.
 
Since we are implementing IPINVx[y], we can skip this IPEDGE actually, so that we record timestamp all the time.

 
Sorry, I've been away from the office a lot recently and not really involved in this as much as I would have liked.
 
ipinv will surely tell us a static state, quite different to edge-detection.
with inp or ipinv, the user will need to store the last state and manually detect the edge.
My intention with suggesting ipedge was an internal opcode that would return true exactly once for a selected edge, even it that edge was some time ago (in real terms) - but that the plc code would see that the condition was met - and could execute the required code just once, without needing additional storage and logic.

 

[CAI_Support]

Hi Ross,
 
Thanks for joining the discussion.   With new logic,
IPx is still the same as before with current state either 1 or 0.
IPx[y] will be true if 0V->5V pulse last longer than y milliseconds otherwise false
IPINVx[y] will be true if 5V->0V pulse last longer than y milliseconds otherwise false
I think the above will meet Tim's need.
 
IPTS  x  y will return in x a number indicate the length of time since last state change, either direction for input y.
 
So you want to make IPEDGE different from AZ1324 proposed to set what edge to record, you want to read back what was last edge change and since how long ago.
For example,
IPEDGE x y z
x is input ID can be 1 to 8
y can be VAR or RAM, stores the current state 0 or 1, with that you know the previous state must be negate of y value
z can be VAR or RAM stores the time since last state change.
 
You have done communication over the IO line, would these added command and data type help?  If not, what would be a better way to do.