Here is a neat code snippit to play with

[LWgreys]

It's a flip/flop-signal-debounce-timer.
X7 is the input signal and Y15 is the output.
I used V1 and V2 as the time amount values.

OK not a flipflop

[LWgreys]

Reason I put this here is a "Coil Debounce Function" like the P3000 has would be nice. I use this snippet to prevent signal bounce from the product movement pass the sensors. There are gaps between the product that causes the sensor to change state.

[BobO]

Ok, now you're just playin' dirty, tellin' me P3K has a useful instruction that Do-more lacks. Probably need to add this one to the to-do list...

[LWgreys]

With the faster scan time the Do-more has over the DL, it amplified the signal bouncing. About 10 time more. Had to work out something simple to handle the problem. Then I remembered reviewing the P3K that it had a Coil Debounce function. I thought it would be great if the Do-more had it also.

[Controls Guy]

My feeling about this is like the idea of having device-specific com boxes.  Rather than that, I'd rather have the generic boxes like Modbus just work really well.  If you were going to so something beyond what's there now, I'd rather have individual definable filters on the inputs, so more of a config thing than a new ladder box.

This is what I typically do, which does (I think) the same thing and is a little simpler.

[Controls Guy]

You could also create a periodic task and run it every 50ms or whatever, and in it copy the inputs you want to debounce to some proxy bits.  It's not as good as a true debounce, where the new state must be maintained for some set amount of time before it's accepted, but it would simulate the effect of DL Classic scan times with almost no effort.

[ATU]

Wouldn't this be better addressed in some type of programmable input filtering? I never really understood the specs on the input modules, there are such wide ranges. Some are 1-8ms, others are 3-9ms. 

[LWgreys]

does (I think) the same thing and is a little simpler.

Yes it does the same thing.
Look what I did. Shrunk it down to 2 rungs with two output Y14 & Y15, no Cs.

Really would like it on one rung.

[plcnut]

If Host decides to add an instruction/config...
I would prefer the instruction based debouncer to the config based. This would allow me to use the input for multiple purposes ie: Count transitions for 1 purpose, and the filtered input for another.

[BobO]

We'll support both. For brick I/O I am adding configuration based filtering in lieu of physical caps and resistors, but we are planning to add an instruction as well.

[ATU]