az1324 is correct, to track the input state change, inside WebControl, non-blocking delay using tick, at 41MHz clock speed, each tick is about 24-25us. Each us is 1/1000 of ms. Obviously, there are only 32bit number we can use to keep track these time length. That is max for non-blocking delay. To convert this tick to larger scale number is doable, but a slow process, because the little processor does not have 32bit register to do that calculation, so it will be like take 100 ticks or more to do the conversion. Like Ross already suggested, if user want to store the longer pulse, it is easier to use CTS. Because the 32bit number can not store long time in ticks, using this timestamp to calculate pulse length may not always give correct answer.
Non-blocking delay might be confusing in certain situation. However, it does not stop PLC execution. not like normal DELAY. So when TTL input bouncing up and down, WC firmware is tracking how long the input stay at that level without holding off other PLC command execution. In actual TTL input connect to any real switch, it will have bounces. If setup WC as alarm, any bounce must trigger alarm. For other control, non-blocking delay is for de-bounce the TTL input noise. For Tim's use, to measure a power on or off condition last long enough.
We do plan to implement using timer to measure the pulse width with very accurate result. However, here is to discuss what to do to improve the 8 TTL inputs functions. What do we want to know from IPEDGE, do we want to record only rising edge OR falling edge timestamp? If so, how to handle the IPTS may get half the timestamp problem. Or IPEDGE is for reading status. What do you want to read? We have IPINVx[] and IPTS implemented and testing in our lab. We want to decide what to do with IPEDGE command, so that we can ship that to Tim for testing.
