How to do debouncing.

Hi.

I have a quick question about debouncing. I have a machine which has two optical sensors as inputs. I’ll describe it simply as a conveyor belt with 30 storage bins fixed to it, and each storage bin has an optical reflector stuck on the side. When each bin passes past the sensor, a CP1L Omron PLC counts its passing and increments a register. Simple. But, the conveyor system is Soooo flacky that it vibrates, and sways from side to side, causing the optical sensor (a real cheap sensor) to falsely trigger giving several outputs when there is only one.

I tend to live in the Microcontroller world and the solution is very simply implemented with hardware filters in the extreme, and or well designed software debounce routines.

How can I solve this using this CP1L PLC,without expensive sensors. I’m still developing the ladder code for the PLC, but I want to implement the differentiation feature available in the PLC, will this be enough or is there some other method. How do PLC’s best handle debouncing?

Thanks for any help
Cheers

Martin

Detect the rising edge when the bin comes through. Subsequently, maybe a combination of the following, depending on the mechanics of the setup:
- time delay AND
- falling edge when bin has passed through
- another time delay AND
- rising edge again

Basically debouncing as you have suggested with the addition of 'no-bin' detection period..

The time delay may have to be varied with the speed of the conveyor ( if it is variable).

_________________________________________
http://www.drivesandsystems.com

Thanks AutomationCtrl, thats the direction I was looking at.
I'm currently writing code to start a timer after a valid edge is detected, and then re assessing if the input is still in the active state when the timer expires(classic simple debounce), but as I understand it PLC's should not be blocked from executing code, and I'm not sure how this solution will work with the scan cycle a PLC runs at? is it an issue?

Martin

I had a similar situation with a circuit board processing line. The entry sensor saw the whole board go in, but after it came out of the acid wash the next sensor only saw the copper traces. 1 in, 175 out.

What I did is on the rising edge of the 2nd sensor input process it and start a time delay off timer. I add a check that the timer is not timing before the rising edge check.

The timer can not a long enough to time until the next item is at the sensor, which for this line was 12 seconds but each board was 8 seconds long. A 9 second timer works to this day.

None of the PLC operations should be blocking. It would take a deliberate loop to do something like that.

A timer won't stop processing flow it is only evaluated at that point in the program. It can't detect events that are shorter than the cyclic time of the code/input update schedule.

For something like this you would normally only use the rising edge of the signal after it has been low for the gap between bins. It depends on the manner in which the signal is dirty.
---[ i ]--[T1]----()

---[/i ]---T1

Thanks Geoff, and all.

Scan languages and programming languages

Regarding the PLC scan cycle and what gets executed on each cycle. This depends on the type of language used.

I personally prefer using a CASE structure in structured text. This locks out the possibility of multiple pieces of logic acting on a single variable or an input. Example: One case could handle the bin detected state and another the 'no-bin' state.

In ladder, this can be a little harder to troubleshoot. Many environments include all rungs in the scan cycle unless there is a jump or enable option included on the function block in each rung.

Not familiar with Omron PLC and if using a mixed set of languages is possible - i.e. ladder, structured text...

One approach would be to handle the debounce for each state in structured text - with a CASE structure. One CASE for 'bin detected' and another for 'no-bin'. Subsequently, feed that bin detected status to another program that handles any other actions for bin detected state.

There are other ways to do it,.. this is just one.

This ties into the object oriented nature of the IEC61131-3 standard. It makes for easier troubleshooting and a 'divide and conquer' approach.