Starting & Stopping Conveyors in Sequence

Manglemender said:

Conveyors are often underestimated!

Click to expand...

Agreed, there are many different types of "conveyor" technology, each of which has it's own "challenges" to the control system.

Manglemender said:

Also bear in mind when passing a product from conveyor A to Conveyor B you must know that there is space on conveyor B!

Click to expand...

Yes, it's best to have had conveyor B running for a while before starting conveyor A, especially if the stop was "unexpected" !!

Manglemender said:

It sounds like you will rely on timers but you could make it more intelligent with sensors;

Click to expand...

This is the crucial thing in material handling - using the most appropriate sensing devices for the application and material. Spending more on reliable and repeatable sensing technology will save $$$ £££ on downtime and maintenance.

I know of one installation where the maintenance crew have to clean the photoelectric senders and receivers at least twice a shift because they get coated in dust which knocks them out, shutting down the line. My (modest) quote to add a periodic air-blast to the affected devices was rejected, so the guys still have to act like chambermaids.

Also bear in mind when passing a product from conveyor A to Conveyor B you must know that there is space on conveyor B!

Click to expand...

Really it depends on what the conveyor is carrying, and how it is arranged. For a series-aligned tail-to-head scrap-metal conveyor system taking scrap metal pieces from 5 punch presses, I only had to make sure that Conveyor B was running before starting Conveyor A. The sizes and speeds were designed so that A could never overload B as long as B was moving.

On the other hand, if Conveyor A dumps packages onto the middle of Conveyor B that already has packages, then you must check for space.

Very interesting, here's one that I have been developing on a site today !

View attachment 20120928a.pdf

This one controls 5 reversible conveyors, starting & stopping in the correct sequence depending upon the directon of flow.

I've also got a remote button station that can stop conveyor 4, and when it does the conveyors feeding it must die back in the correct sequence.

In the forward direction the conveyors are controlled by a machine at the front end that can (and does) sometimes stop then restart again within a couple of seconds. The idea of the timed stopping sequence is to prevent the whole conveyor system shutting down and then restarting as the controlling machine does - worst case you might get conveyors 1 and 2 shut down but then they should start back up again.

The problem is that once the stop sequence is triggered it continues right through all the conveyors, even if the conveyors at the front end have restarted again so you end up with conveyors stopping in sequence being "chased" along by conveyors starting up in sequence again ! What I am struggling with is "stopping" the stop sequence when the front end conveyors restart ?

Does that make any sense ? probably not ?

Oh and I've got no sensors / photocells to help me.

Any thoughts ??

Mark

Oh and I've got no sensors / photocells to help me.

Click to expand...

Think about the benefits of adding some photocells compared to the cost of not having them. In many cases a conveyor could be "empty" as shown by a strategically-located photo switch, and then you could safely restart that conveyor.

The problem is that once the stop sequence is triggered it continues right through all the conveyors, even if the conveyors at the front end have restarted again so you end up with conveyors stopping in sequence being "chased" along by conveyors starting up in sequence again ! What I am struggling with is "stopping" the stop sequence when the front end conveyors restart ?

Click to expand...

Sensors are the eyes, ears, and hands of your PLC. Without knowing the complete picture, your PLC program may be fat and happy but will also be dumb and in the dark. Make it smart by adding however many sensors are needed so that it can make wise decisions. Add sensors, and add a timer that controls the stopping sequence. If the machine restarts, then the stopping sequence gets killed, and then the stopped conveyors should restart as usual based on the demands of the machine.

I can't imagine how or why a system of conveyors would need to reverse this often. Are these conveyors serving both for raw materials feed and then later for product take-away?

Hello Lancie1, I would post a program however I just used jrwb4gbm's program, so it isn't really any different. I will post my programs as I write original code. Every day I am working on coding to improve my skill. I have written jrwb4gbm's code so now I will take a closer look at yours starting today, really looks interesting.

Now I am going to play with the conveyors not all sharing the same TON. That should be interesting, maybe I will have conveyors 1 - 3 be the same yet 2 be different.

I mention all this because your code appears to have the conveyors all sharing the same start and stop timers with the same preset. I am really interested in how you wrote it, so I will let you know what I come up with by Wednesday.

Again thanks guys!

I mention all this because your code appears to have the conveyors all sharing the same start and stop timers with the same preset.

Click to expand...

I once had to work with a system of 75 package-handling conveyors at a publishing company. Using 75 start timers and 75 stop timers seemed to be a horrendous method, very long program, and hard to keep up with and make changes.

That is when I switched to the two-timer-multiple-conveyor method. I was not the first to use this method by any means. The timer Preset values are are mostly irrelevant. For the Start-Up Timer, you only have to set the Preset high enough, longer than the last (farthest upstream) conveyor start-up time, and for the Shut-Down Timer, longer than the first (farthest downstream) conveyor shut-down time. Then you should use comparison instructions to do the individual conveyor start-ups and shut-downs.

On a large malt-handling installation, I developed a "handler" subroutine for the conveyors (this was pre-AOI days).

The handler was similar to a motor handler, with the addition of control inputs/outputs that could be daisy-chained in the control code.

These were...
Inputs...
DSR : Downstream running
USR : Upstream running
Outputs...
DSE : Downstream enable
USE : Upstream enable

You simply connected...
USE of the "fed" device to the DSR of the "feeding" device
USR of the "fed" device to the DSE of the "feeding" device

Logic "1" had to be applied to the DSR of the lowest device, and a logic "0" to the USR of the highest device.

Notice that I am now referring them to "devices", not just conveyors, because the handler could also be used for gate valves, rotary valves, diverters, inline tip-weighers, stone separators, and just about anything in the "stream".

The handling routine incorporated all the start-up delays, in-flight emptying delays, etc. as parameters, so each piece of kit looked after itself.

A huge advantage of this method was that to start a conveyor run to deliver product from a specified storage silo to its destination, you just programmed to turn on all of the devices at the same time, and the in-built interlocking logic and timing meant that the flight started in proper sequence.

Turn off all the devices simultaneously, and they stopped in proper sequence, running-on for their own individual "in-flight" times to empty each section before stopping.

Route-changes were easy too. Simply instantaneously change the "start" inputs to all the devices, and it would shut-down in sequence to the common point, then the new upstream route would start-up in sequence.

A fault on any device would immediately stop all upstream devices, and the downstream devices would shut-down normally with their respective in-flight delays. The flight could be restarted at any time, without having to wait for the shut-down to complete (start-up delays would work as normal).

All of the interlocking code was therefore built into the handler, you just had to make the device-to-device connections as above to make it all work, and I have to say it worked perfectly, and is in use in several similar installations...

Obviously for commercial/copyright/legal reasons I cannot post the code, even if I had it, I have just described it from memory to give an example of a different way of sequencing conveyors etc.

This serves as a practical example of what is taught on many PLC programming courses - separate the "procedural control" from the "equipment control". In this case, the procedural control calls for a specified material handling route to start, and the equipment control makes it happen in the correct manner.

The pic may help....

Hello iadapt,

I did a similar thing at school yesterday.
I start 4 Lamps in sequence. When all 4 lamps are turn on if i press the stop buttom they will shutdown in sequence. Example;
Start 1-2-3-4 stop 4-3-2-1
http://pdfcast.org/pdf/clocks-1

Victor

I've literally spent all day trying to do an exercise of this magnitude and could not figure out the proper way to begin and sustain the shutdown process.

Thanks again.

Old thread revitalized....

I do these in my sleep, and it's a perfect application for Sequencers. A 3 step sequencer for each conveyor is all you need to start them up in sequence and shut them down in sequence. I just did one today.

Latch a Bit to 'Start'

Step 0 - Idle (nothing happens)

Step 0 to Step 1 - 'Start' * Upstream Conveyor Running

Step 1 - Run Conveyor

Step 1 to Step 2 - (NOT 'Start' * Downstream Conveyor NOT Running) + Upstream Conveyor NOT Running

Step 2 - Run Conveyor * Cleanout TMR

Step 2 to Step 0 - Cleanout TMR Done + Upstream Conveyor NOT Running


Conveyor Runs in Step 1 or Step 2

Cut/Paste for any number of conveyors in sequence....First Conveyor has no Downstream Condition, Last Conveyor has no upstream condition (perhaps)

I use a UDT that defines each Conveyor that has the above bits/timers, so I can cut/paste an entire routine, and search/replace by conveyor name, change the upstream/downstream and done...Takes 2 minutes of programming for each conveyor at most.

robertmee said:

Old thread revitalized....

I do these in my sleep

Click to expand...

Must be nice!!!

I'm new to learning plcs and am doing a exercise for 6 on, 6 off, all with different start/shutdown times. I could not figure out how to shut them down properly, once they were all running. The examples helped alot. Still learning, as quick as I can.

Thanks!

I do this using an add-on instruction that decides when to start a conveyor.

First conveyor starts with any start procedure.
Every next conveyor in line has an add-on instruction shown on a picture below (it's for conveyor 2, but it's the same for 3, 4, 5...).

Add-on instruction starts that conveyor with delay of 5000 ms when preceding conveyor starts and shuts it of with delay of 5000 ms when preceding conveyor stops.

Add-on instruction starts that conveyor with delay of 5000 ms when preceding conveyor starts and shuts it of with delay of 5000 ms when preceding conveyor stops.

Click to expand...

If you are using "precede" as its normal definition as "to come before", then your startup sequence seems to be reversed. It is the farthest downstream conveyor (does not "precede" any other conveyor) that should be started first. Your logic needs to look the other direction for startup: Each conveyor logic block should look at the "following" conveyor to see if that is running, before it is allowed to safely start without dumping product. For shutdown, each conveyor should look at the preceding conveyor to see if that is stopped, before it can also safely stop.

Yes, Lancie1, you're right.

I_Ref_Motor_Running should be renamed to I_Downstream_Motor_Running and variable I_Upstream_Motor_Running should be added as condition to stop a conveyor.

So, when starting a line you start conveyor that is most downstream and when stopping a line you stop conveyor that is most upstream. Rest of conveyors will follow an action with desired delay.

Also, it should be taken care that in case of failure of one conveyor in line, all of the upstream conveyors immediately stop.

Also, it should be taken care that in case of failure of one conveyor in line, all of the upstream conveyors immediately stop.

Click to expand...

If each conveyor has the normal interlocked logic with the next upstream conveyor, then if one fails, the next upstream conveyor immediately stops, which causes the second upsteam conveyor to stop immediately, and so on until all conveyers (from the first stopped one up to the beginning of the line) are stopped. In other words, no extra provisions need be made for the case of the failure of any one conveyor.