TICKms Based Debounce Logic

[Bolt]

I'd like to use some logic like:

Code: [Select]

IF(((Input0.SET_TICKms != 0) & (TICKms() >= Input0.SET_TICKms)) | ((Input0.RESET_TICKms != 0) & (TICKms() <= Input0.RESET_TICKms)), 1, 0) to roll my own debounce on/off, but this won't work too well when TICKms() rolls over from 2,147,483,647 to -2,147,483,648, making TICKms < RESET_TICKms, causing the statement to be true. Is there another way that would work? I'd like to have more resolution than a $UTC based solution would create.

[rlp122]

Mask off bit 32 to keep the sign bit from toggling?

[Controls Guy]

No, cause it will still roll over and create a false inequality.  Not sure what size math is done  in your scenario (assuming 32-bit), but when I use a recycling event drum, I often have to do some modulo arithmetic to account for a possible rollover.  But, I'm setting pins in a really big drum, not doing an edge test around a target value, so a little different.

Maybe turn off only if you're greater than the target, but less than the target plus two or three scan times.   That might get you over the hump.  Or, in addition to a compare with the target, add a double check that the relationship of the current to initial value is the same as the target to initial, both greater or both less.

[franji1]

Not really sure what you are trying to do, but 2's complement math works fine as long as you aren't waiting 29 days (or whatever) between "comparisons" (but that's a problem regardless of how you do it - double roll over)

Now >= a
-a from both sides
Now - a >= 0

Hence, in 2's integer complement math, you can always take the delta between Now - timestamp and get a relatively small positive or negative value, even when one crosses either threshold (+2B crosses to -2B or -2B crosses to 0) and the other does not.  On paper the numbers don't work out, but in 2's complement integer math it does (so no extra logic dealing with the various thresholds).