Search:     Advanced search


Discuss your PLC and automation problems for Allen Bradley, GE, Omron, Mitsubishi, Modicon, Panel Views, RS View, ABB, Adept Robots, Cognex etc. You can also submit and download sample PLC code.

If our forums and knowledge base still hasn't got your PLC operational, we recommend contacting PDF Supply and Electric for PLC repair and replacement parts.

Programming Application - Photoeye Make and Break Logic (Debounce)

Article ID: 15
Last updated: 13 Oct, 2010

How many times have you seen your photoeye lens get dirty and think there was a part to sense but really it was just a false input? Hopefully in this example I can explain to you how to implement make / break into your control logic.

Let's say that you have a photoeye that makes sure your part is present before it fires a pusher cylinder that moves your part down stream 90 degrees. See the example logic below.

Most everyday, the photoeye will function properly by seeing your part on the conveyor, sending a signal to the PLC, and then the PLC will tell the pusher to push the part to the other side. However, let's say one day the photoeye lens gets dirty. Now no matter if you have a part in front of the sensor or not, the input to the PLC is still going to be true. So when it comes time to evaluate this rung again, your pusher would function just like normal even with no part present and the maintenance guys are going to give you a goofy look because your pusher has just cycled with not part on the conveyor.

Designing make / break logic for devices such as a pusher to verify the part has indeed left the automated area is a common practice easy to implement. The concept is to use an internal latch bit in conjunction with a single shot bit. Once your pusher has retracted it will unlatch the "make" bit. See example logic below.

So now the next time the rung is evaluated, the one shot will fail to set the "make" bit again, because your photoeye never turned off. Your photoeye must turn off, then turn back on again to set the "make" bit and allow your pusher to cycle once again.

Some other situations that arise when make / break logic would come in handy:

  1. Cable cut and photoeye shorted to a high signal for PNP or shorted to a low signal for NPN.
  2. Using photoeye in a gravity application and the part does not drop, but hangs in the automation and does not drop down.
  3. Photoeye lens gets dirty or sees dirt from common industrial exposure.
  4. Person standing by the photoeye anf "flags" the eye with their white shirt.

Download the Photoeye Make and Break RS LOGIX example, PDF included. Winzip Required.

Article ID: 15
Last updated: 13 Oct, 2010
Revision: 1
Views: 18033
Comments: 3
This article was:   Helpful | Not helpful
Prev   Next
Programming Application - Controlled Start and Stop     Programming Application - 3 Phase Motor Startup

wwyatt | 25 Nov, 2005 12:00 AM
It seems a little redundant to use the Make and Break Latch and the photo eye input on every rung that needs to know that a part is present at the pusher. Why not just use the Make and Break latch bit and save youself some coding?
Posted: 12 years 3 months ago   | Permalink
William McLaughlin | 28 Oct, 2006 12:00 AM
This is just pitiful. First off, that logic will never work. You can't use PUSHER_EXTOK to unlatch PE_PP_PRESS_MB until after PUSHER_EXT_OK has been evaluated (because PUSHER_EXT_OK depends on the latch state). Second, you can't use PUSHER_IC as part of your PUSHER_EXTOK because presumably PUSHER_EXTOK is a necessary condition for PUSHER_IC to set. Third, you don't need the ONS (a ONS into a latch is pointless). Fourth, Latching logic (your rung 3) is a substitute for a latch bit (PE_PP_PUSHMB)- there's little point in mixing the two.

Most importantly, however, is that this logic is ill suited for the problem you describe. In the case of false signals from real world inputs, you need two things...debouncing and latching. Why debouncing? Because it's when the signal is flickering that you have problems - like when the lens is partly dirty, or the edge of your object isn't crisp, or you have vibration to worry about... So, the correct way to solve your problem is to debounce the photoeye input (with a timer, not a ONS) and then use either a latch bit or latching logic to set PUSHER_EXTOK. Sometimes, you'll want to debounce both the block and unblock conditions of a sensor, but for a photoeye it's usually only necessary to debounce the block condition.

Here's how I'd do it:
1: PE_PP_PUSHER => enable Timer(20ms).EN
2: Timer(20ms).DN and not PUSHER_IC => latch PE_PP_PRESSMB
3: not PE_PP_PUSHER and PUSHER_IC => unlatch PE_PP_PRESSMB

PUSHER_IC set means the pusher is not fully retracted, and requires a prox switch and/or timer to implement. PE_PP_PRESS_MB is set when the pusher is extending or fully extended (which appears to be what PUSHER_EXTOK is supposed to be). PE_PP_PRESS_MB is clear when the pusher is retracting or fully rectracted (which appears to be what PUSHER_RETOK is supposed to be).
Posted: 11 years 4 months ago   | Permalink
Chris | 13 Nov, 2006 12:00 AM
William - Maybe I didn't clearly explain this example to most. The problem might be I did allot of assuming that bits that are used in this example are "assumed" they will happen, meaning I didn't write the entire application out. I'll take that into consideration next time I try to explain an example, I'll be sure to include all bits that I have used. The make break logic I speak of does in fact work. I use debounce logic DAILY, and I disagree that debounce alone with solve your photoeye stuck "ON" condition. If a part gets stuck in position or jammed and causes a photoeye to remain on, debouncing your input won't let you know that your sensor did not transition from an on to an off state. If I get some time, maybe I'll revisit this article.
Posted: 11 years 3 months ago   | Permalink

Prev   Next
Programming Application - Controlled Start and Stop     Programming Application - 3 Phase Motor Startup