[attachmentid=3228]


Hi I have a problem with a counter on our robitic cell, the cell has a table that turns to unload and when the unload program is called the counter adds two each time. The problem is the prox switch that sees which side of the table is there sometimes flickers, and when it does the counter will count twice, I added a pic of the line for the counter above...

Your Count happens off the Output not the prox. You need to look at what double pulses the output. Also you don't mention cycle time. You could always start a timer when the first count occurs and not allow a second count while the timer is timing. This assumes you know the cycle time and settle times of your table.

Ok, one of the triggers for that output is that prox, and that's the only thing that is flickering. It's not an every time thing just enough to throw the counts off.
The shortest cycle time for the table to turn again is about 1 min. So a few second timer would work great. Could you show me where to put the timer in?
Thanks.

http://www.plctalk.net/qanda/showthread.ph...hlight=debounce

http://www.plctalk.net/qanda/showthread.ph...hlight=debounce

http://forums.mrplc.com/index.php?showtopi...amp;hl=debounce

[attachmentid=3230]

Ok, thanks for the replies, here is what I got so far, could you take a look at it and see what you think. The thing is, in all those examples they were using the input, is it ok for me to use the output to start the timer like I did.

It is ok to use the output instruction for your logic. But the one-shot will only allow your timer to run for one scan. I would get rid of the on-shot and replace the add instruction with a counter. Look at the second link I
posted and "Alaric's post#5 should do it for you.

Mickey, that post you're refering to was the one I looked at, and for the OSR, it was already in the program and I'm not sure if I should take it out?

If you don't take it out the timer is useless. The one-shot was there for the add instruction. The add
instruction will increament ever scan as long as the rung is true , without the one-shot.
Thats why I subjected you change the add instr to a counter. Just like the example.

Try this...

> run the debounce timer on a seprate rung
> rearrange things around the ONS so that only the debounced event can trigger the ADD. The other conditions should simply act as permissives. In your previous examples any one of the conditions going true (assuming the others were true at the time) would add 2. [Is this allowed with the OSR? I'm more accustomed to using the ONS in the PLC5 like this.]

UPDATE: After a second look...that won't work either. If your output is flickering so will the TON.TT bit. Does the output go on-off -on and finally stays on OR on-off-on-off and stays off? If it stays on, use a TON.DN. If it stays off use a TOF.DN for your debounce. You'll have to play with the timer.pre values to fully mask the bounce.

Easy solution... fix the sensor flicker problem. If you are having issues with your sensor then I would focus my attention on getting a stable reliable signal. A much better solution than programming around the main problem.

Good point, the timer should only be a temporary solution. Another thought is to use input filters. Still a temporary solution but requires no programming

Excellent point Ron if the Inertia and design of the table is such that the flicker can be eliminated. I have had applications were due to cycle demands we had to expect the table or transfer to "bounce and settle" and write our code accordingly.