Non-Blocking Delay on IP2 broken v03.02.17e Bug?
- Thread starter TJF1960
- Start date
CAI_Support
Senior Member
There are internally 24 non-blocking timers, and twice more for the WC32. Expose them all will require add same number of IO Identifier to the symbol table, which can not add that many any more. We need to think some other way to reference them.
Lets first get this TTL input non-blocking delay work right for Tim. We sent to Tim another test code, also, I think Tim need to change the TSTEQ IP2[30000] 0 to TSTEQ IP2[30000] 1, do you want to turn on output when IP2 is TRUE?
If your TTL signal is negative going, then you need to change the input reverse configuration for that TTL input, still compare against TRUE, not FALSE.
Lets first get this TTL input non-blocking delay work right for Tim. We sent to Tim another test code, also, I think Tim need to change the TSTEQ IP2[30000] 0 to TSTEQ IP2[30000] 1, do you want to turn on output when IP2 is TRUE?
If your TTL signal is negative going, then you need to change the input reverse configuration for that TTL input, still compare against TRUE, not FALSE.
CAI_Support said:
One possible (but slightly inelegant) way to achieve it would be the creation of a new opcode. It wouldn't require any additional symbol table space, but would require an intermediate step.
Eg:
tick IP1 var1 ; load var1 with how many ticks ago IP1 most recently changed state
CAI_Support
Senior Member
Don't know if Tim tested the modified firmware with any success.
I tried it with TSTEQ IP2{30000} 0 and it turned OP1 off right away. I haven't tried reversing the logic yet because the problem with me trying all this continually is that this function is turning my media server power and switch on and off, so when OP1 turns off too soon the server doesn't shut down properly...So I dug out another board I just got back and set up a test jig to test and have not been able to get the board to accept the new firmware update. The board goes into bootloader mode but can not upload the firmware.
Tomorrow I will pull out the other board and hook it up and test further.
Sorry for the delay.
Tim
Tomorrow I will pull out the other board and hook it up and test further.
Sorry for the delay.
Tim
CAI_Support
Senior Member
Tim,
ip2[30000] means any pulse from 0 to 1 must stay high for 30 seconds, otherwise it will return 0.
So if you have pulse that is not going from low to high for 30 seconds
TSTEQ IP2[30000] 0
will result true and execute next command.
Unless you have negative going pulse, you should change that to
TSTEQ IP2[30000] 1
instead.
If you have negative going pulse, please set IP2 to reverse in IO configuration screen.
ip2[30000] means any pulse from 0 to 1 must stay high for 30 seconds, otherwise it will return 0.
So if you have pulse that is not going from low to high for 30 seconds
TSTEQ IP2[30000] 0
will result true and execute next command.
Unless you have negative going pulse, you should change that to
TSTEQ IP2[30000] 1
instead.
If you have negative going pulse, please set IP2 to reverse in IO configuration screen.
CAI_Support
Senior Member
There is a misunderstanding that negative going pulse as trigger is identical to positive going pulse in PLC logic. In PLC logic, TTL input high level is treated as TRUE, TTL low level is treated as false. If your input pulse for OFF state is high TTL level, and ON is low, please use IO configuration screen to set that particular TTL input to reverse. So that PLC logic will work correctly, because TRUE and FALSE in TTL input is not treated exactly the same, especially when using non-blocking delay.
CAI_Support
Senior Member
After discussing with Tim, we now understand his need is to be able to have non-blocking delay on the same IPx for both 0 to 1 delay and 1 to 0 delay. Because in the same PLC code, one section requires logic TRUE us TTL high level, another section require logic TRUE is TTL low level, we think the solution is to introduce a new command, so that user can change TTL input level invert dynamically.
Supposedly his server will be in one of those two states, ON or OFF. Before server turned on, his PLC code will check IPx 0 to 1 pulse is longer than certain length, then count that as TURE. After server turned on, his PLC will set the TTL iP2 invert to ON, then WebControl will check IP2 if its level from 1 to 0 pulse is longer than certain time, it will count that as TRUE.
When WebControl first power on, it will always use the EEPROM stored configuration to set the TTL invert properly.
Does anybody see any problem with this proposed change?
Supposedly his server will be in one of those two states, ON or OFF. Before server turned on, his PLC code will check IPx 0 to 1 pulse is longer than certain length, then count that as TURE. After server turned on, his PLC will set the TTL iP2 invert to ON, then WebControl will check IP2 if its level from 1 to 0 pulse is longer than certain time, it will count that as TRUE.
When WebControl first power on, it will always use the EEPROM stored configuration to set the TTL invert properly.
Does anybody see any problem with this proposed change?
Is it not possible to simply record the timestamp whenever an input TRANSITIONS. (either 0->1 or 1->0)
That way, any operand that includes [time] will *ALWAYS* be false, regardless of current state, regardless if it's active-high or active-low, regard less if it's input or output or register or variable, if (now-transition_time)<[time]
Or is there some other nuance I'm missing?
That way, any operand that includes [time] will *ALWAYS* be false, regardless of current state, regardless if it's active-high or active-low, regard less if it's input or output or register or variable, if (now-transition_time)<[time]
Or is there some other nuance I'm missing?
CAI_Support
Senior Member
Hi Ross,
Are you suggest just remove non-blocking delay feature, instead of returning how long as the last state change and current state?
That is possible to do. However, if we want to keep non-blocking delay, we must treat low to high transaction differently from high to low, unless we allow user to reverse input inverse based on its logic.
For most people who only need non-blocking delay to check one direction pulse length, they don't need to change the input invert in their PLC. We think that is still simple than providing time since change and current state to let user figure out. At least it will save a variable.
Are you suggest just remove non-blocking delay feature, instead of returning how long as the last state change and current state?
That is possible to do. However, if we want to keep non-blocking delay, we must treat low to high transaction differently from high to low, unless we allow user to reverse input inverse based on its logic.
For most people who only need non-blocking delay to check one direction pulse length, they don't need to change the input invert in their PLC. We think that is still simple than providing time since change and current state to let user figure out. At least it will save a variable.
CAI_Support said:
No, I'm not suggesting doing away with non-blocking delay. I'm suggesting what I think is a way to make it work in all cases, without needing to jump through hoops and knowing if it's a high-going or low-going transition.
Basically, I'm suggesting that the firmware in effect, monitors the state of each input and whenever it *CHANGES* - either way, low to high or high to low, regardless of the invert state, you simply set the "last changed" timer for that input to the current timer-tick value.
Similarly any time you change an output or var, also update it's "last changed" timer.
Then, in the users code, wherever the "non-blocking delay" is used eg, [2000], it is simple for the firmware to see if the current timer for that variable, input or output is more than or less than that many milliseconds worth of ticks. If "last changed" time is more than 2000ms in this example, it will ALWAYS return "true". If less than 2000, return "false".
I could be missing something here, as when I tried to use the non-blocking delays, I had "inconsistent" results. Documentation seemed incomplete, and things I'd tried gave different results on different versions of firmware, and different to descriptions posted in this forum. Fortunately most of my delays are in the "seconds" range, so I wrote "non-blocking delays" using a calculated second-of-day (or later CTS), but this doesn't have the granularity for milliseconds of course.
CAI_Support
Senior Member
Hi Ross,
Non-blocking delay are handled differently for VAR, TTL Output and TTL Input. The reason is that VAR and TTL output is simple last value and current value. TTL input could be up and down and up again.
We had logic like you said inside, however, it does not handle the FALSE state is high voltage situation. If you invert the TTL input for that IP2, then it will not handle the low to high situation. Because non-blocking delay is counting how long the TRUE is, if the time is not reached, it will return false. The net result is that smaller pulses being filtered out. However, smaller pulses for low to high has same effect as huge pulse from high to low on the same input pin. So that the logic you recommend, which is what have been shipping, does not work for both. You either treat 5V as logic 1, or treat 0V as logic 1. When you want to treat both 5V and 0V as logic 1, it conflicts.
In Tim's code, his code from low to high non-blocking delay working fine in the same PLC code. However, the section he has problem is that same IP2 needs to ignore how long it is 5V, but looking for how long it is in 0V. That is like input being inverted. This is TTL input issue, nothing to do with OP or VAR.
That is why we propose to add a command to invert input because PLC programmer know when to detect 0-to-1 pulse longer than certain time, when to detect 1-to-0 pulse longer than certain time.
Non-blocking delay are handled differently for VAR, TTL Output and TTL Input. The reason is that VAR and TTL output is simple last value and current value. TTL input could be up and down and up again.
We had logic like you said inside, however, it does not handle the FALSE state is high voltage situation. If you invert the TTL input for that IP2, then it will not handle the low to high situation. Because non-blocking delay is counting how long the TRUE is, if the time is not reached, it will return false. The net result is that smaller pulses being filtered out. However, smaller pulses for low to high has same effect as huge pulse from high to low on the same input pin. So that the logic you recommend, which is what have been shipping, does not work for both. You either treat 5V as logic 1, or treat 0V as logic 1. When you want to treat both 5V and 0V as logic 1, it conflicts.
In Tim's code, his code from low to high non-blocking delay working fine in the same PLC code. However, the section he has problem is that same IP2 needs to ignore how long it is 5V, but looking for how long it is in 0V. That is like input being inverted. This is TTL input issue, nothing to do with OP or VAR.
That is why we propose to add a command to invert input because PLC programmer know when to detect 0-to-1 pulse longer than certain time, when to detect 1-to-0 pulse longer than certain time.
CAI_Support said:
OK, I'm obviously missing something.
Overly-simple Code fragment: debounce. noisy input.
Code:
tsteq ip1[1000] 1 ; is input high now, and been high for 1 second or more?
set op1 1 ; set output only after input has been high for a second
tsteq ip1[1000] 0 ; is input now low, and been low for 1 second or more?
set op1 0 ; clear output only after input has been low for a second
