Lame seperator

[Cgardner]

I am the maintenance manager at a plant in Atlanta. Also the only plc guy here. I have a problem with separating product that I been banging my head against the wall for days. Can someone please help me out? I got one input for photo eye. I have two outputs. One for a pause arm to briefly hold product, while the lane seperator moves to divert traffic. I need the photo eye to count to a number. Say 5 or 10, then the pause arm to immediately give pause, latch the pause in place for a certain time, yet to be determined until install. The the output to energize for the lane seperator. And then unlatch then first input while the seperator arm stays latched until the same number passes through. The same thing when the count is done I have to have a timed pause before the arm can move back by unlatching the second output. I have wrote this program 5 different ways and can get it all almost right besides one final thing. I can’t get it right and don’t have advance skills or the time to keep being consumed by this problem. Please help!

 

[drbitboy]

0) Welcome to the forum!

1) As is common, we need more information.

1.1) Can you post some of your attempts, and what is wrong with each one?

1.1.1) Print them as PDF, or put the programs in one or more .ZIP files.

1.1.2) Attach the PDF or .ZIP file(s) to a post in this thread; use the [Go Advanced] option and look for the paper-clip icon to attach files.

1.2) What are the manufacturer, model number, software, programming language (ladder, FB, ST), etc. that you are using? That will be helpful so we can know what instructions are available.

2) I am not sure I understand the process, but here is how I interpret what you wrote:

2.1) There is one incoming lane of product to the process that you are trying to control

2.2) The product "flow" is comprises discrete events, i.e. it not continuous, i.e. it arrives one product at a time

2.2.1) There is a photo-eye discrete PLC input that is 1 when a product is detected by the photo-eye, and 0 otherwise

2.2.2) An edge of that PLC input (e.g. rising edge = transition from 0 to 1) triggers a counter to increment by 1

2.2.3) You have not said if a debounce on the photo-eye input may be necessary i.e. the photoeye may show multiple 0-to-1 and 1-to-0 transitions on a millisecond time scale at the arrival and/or departure of each product.

2.3) There are two outgoing lanes leaving the process

2.3.1) Let's call them [Lane 0] and [Lane 1]

2.4) There is a diverter that directs products coming from the single incoming lane into one or the other of the two outgoing lanes

2.4.1) There is a discrete PLC output that controls the diverter. Let's say when this output becomes 0 and the diverter has had time to move that the products will be diverted to [Lane 0], and when this output is 1 and the diverter has had time to move that the products will be diverted to [Lane 1].

2.4.2) The diverter takes time to move from directing product from one outgoing lane to the other outgoing lane

2.4.2.1) There is a "pause" arm, the intent of which is to hold the incoming product in the single incoming lane while the diverter is transitioning between output lanes.

2.4.2.1.1) There is a second discrete PLC output that controls the pause arm. Let's say this output will be 1 when the pause arm is extended and holding products back, and it will be 0 when the pause arm is retracted and products are free to move to the diverter.

2.4.2.1.2) The duration that the pause arm should be extended, while the diverter arm is transitioning, will be set by a timer.

2.4.3) The transition of the diverter arm from one lane to the other will be triggered by some number, 5-10, of product items detected by the photo-eye in the incoming lane.

Is that close to correct?

What about startup e.g. do you want the diverter to always start on one lane or the other. What about when power fails and is restored to the PLC?

P.S. I can't help but be reminded of this classic TV scene: https://www.youtube.com/watch?v=NkQ58I53mjk

 

[drbitboy]

I am not sure if I understand OP's process, but here is one of many possible approaches, implemented on an Allen-Bradley MicroLogix 1100.

Although OP mentioned Latch/Unlatch, which suggests A-B/Logix (not CCW), I don't know if they have equivalent instructions or if they are even programming in ladder. That said, the TOF triggered by a one-shot is a good fit for controlling the Pause Arm behavior, and ya gotta love that flip-flop circuit for toggling the diverter state.

The counter preset and the Pause Arm delay would have to be tuned at commissioning, of course, and the values here are at best ignorant guesses on my part.

Ignore the input map; it uses bit 13 of a 10kHz free-running clock to simulate an incoming product item detected by the photo-eye every 1.6384s; I would not be surprised if a debounce strategy was required for both rising and falling edges of the actual photo-eye input.

 

[arpus4KM]

I think you forgot the most important question Dr.

Is there going to be an operator who wants a manual mode switch that bypasses everything so he can "do it better himself"...?

 

[drbitboy]

I think you forgot the most important question Dr.

Is there going to be an operator who wants a manual mode switch that bypasses everything so he can "do it better himself"...?

Hehe, good one; yes, OP should answer that also.

 

[BachPhi]

my gosh! drbitboy

 

[Cgardner]

Yes you’re pretty close. The lane shift is quick. A second is all I need. And I am not able to get the pause timer to work both ways. Count up, pause for a timed period, latch, count, pause, unlatch.

 

[Cgardner]

I tried the file you used but it doesn’t program like that in the Rs 500 logix.

 

[Cgardner]

The one shot output under the timer is the problem

 

[drbitboy]

Update:

No, actually that should work as is with the

OTE COUNTER_DONE_ONESHOT

​

by itself under the TOF, because on the next scan after C5:0/DN has a 0-to-1 transition and COUNTER_DONE_ONESHOT becomes 1,

• T4:0/DN will be 1,
• so the [XIO T4:0/DN] will be False,
• and COUNTER_DONE_ONESHOT will go back to 0,
  • and so will indeed be a one-shot
  • i.e. 1 for one scan only (Vasily - sorry, never gets old, at least for me ).

Is it possible the TOF still timing when the counter completes a second time?

The one shot output under the timer is the problem

[Update: ignore the rest of this, my initial response]


Yup, I see it, I'm an idiot. Sorry, I thought I tested it.

That

OTE COUNTER_DONE_ONESHOT

​

branch on Rung 0002 under the timer should be

OSR COUNTER_DONE_MEMORY COUNTER_DONE_ONESHOT

​

Or swap Rungs 0001 and 0002 and put a

XIO C5:0/CU

​

in front of the

OTE COUNTER_DONE_ONESHOT

​

 

[drbitboy]

I am not able to get the pause timer to work both ways.

Is the photo eye still detecting items while the pause timer is running?


Can you please make a sketch of the process, showing relative locations of photo eye, pause arm, and diverter, as well as approximate distances between same, speed of product items, and range of distance (or time) between product items? Time can be substituted for all distances if speed is constant.


Microsoft Paint writing a PNG should do the job.

 

[drbitboy]

I tried the file you used but it doesn’t program like that in the Rs 500 logix.

I am using RSLogix Micro Starter Lite and a Micrologix 1100, so it may be slightly different, esp. if you are using a SLC or other non-MicroLogix, but it should be close.

 

[drbitboy]

Here is a slightly modified, cleaner version:

• Assign 0 to counter .PRE
  • This is cleaner and better than a reset, as it does not require waiting for counted input rung logic to return to False, because it leaves the /CU bit alone
• The simulated input can be turned on and off
• Input I:0.0/0 is assigned as the photo-eye input when simulated data are not being used
  • The current logic assume the input becomes 1 when a product item is to be counted
• The Pause Arm TOF PREset is now 100cs (1s)

AFAICT, this works, at least on a MicroLogix 1100.

 

[Phrog30]

Use a state machine, much easier to program vs code vomit. Even if there is only one or two steps, use them.

 

[drbitboy]

Use a state machine, much easier to program vs code vomit. Even if there is only one or two steps, use them.

I dunno: I couldn't get it below 16 instructions, and I had to use a bit-wise XOR (which may induce gagging in some) to do that.

The other way, with four rungs (count, time, pause arm output, diverter output) and thirteen instructions, seemed pretty clean to me.

I guess vomit is in the eye of the beholder (ouch; sorry for that imagery, and especially for the beholder! ).