Conveyor Control - Window Reservation

[brucechase]

Actually, I activate a timer every time the bag would clear the photoeye and make the preset to be the length of 1 window (just over 1 m). That way each counter would have a timer done bit that says there is a hole available. Yes, I use 1 photoeye approx 1 meter before the counter. Even though my method seems to be the least popular and simplest, please consider what everyone else is saying, there is a lot of experience here. I do know that this method works in my application (which is similar - not identical - to yours). The mockup is not only a good idea, I also think it is required for this application. Remember to use actual components for the induction gate and main conveyor belt.

As for belt speed, for 45 bags per min with a 1 m per bag size, that means the main conveyor must be at a minimum of 45 m/sec speed, but more likely 60 meters/sec speed. For this application, that is moving pretty fast. Again, look at starting and stopping, I would think a min of softstart but more likely a VFD. Use the run contact to give a delay to allow the system to come up to speed before you try to induct. Also, I use the photoeye at the counter for induction to look for jams. If I release the bag and it doesn't clear the induction photoeye before the window closes, stop and alarm - or tell someone to go pick up the big mess on the floor. Again, I really don't think you need a fifo or array, I think it can be done with simple logic (with or without an encoder).

 

[elevmike]

45 m/sec speed (I didnt notice the proposed speed before this).

For you Americans, that works out to 100 mph !!!

Way way way too fast. Your bags are going to be all over the place. That speed would result in almost nothing but collisions. Dont forget the bags will vary greatly in weight & size.

An approperate speed might be more like 2-3 m/sec.

 

[Peter Nachtwey]

Slow down there..

45 m/sec speed (I didnt notice the proposed speed before this).

45 bags per minute at 1 meter per bag is only 45 meters per minute.

 

[elevmike]

Ha! I knew there was something wrong. Should have stop and thought about that for a minute....

 

[brucechase]

minutes seconds meters feet OOOPS

Actually, I activate a timer every time the bag would clear the photoeye and make the preset to be the length of 1 window (just over 1 m). That way each counter would have a timer done bit that says there is a hole available. Yes, I use 1 photoeye approx 1 meter before the counter. Even though my method seems to be the least popular and simplest, please consider what everyone else is saying, there is a lot of experience here. I do know that this method works in my application (which is similar - not identical - to yours). The mockup is not only a good idea, I also think it is required for this application. Remember to use actual components for the induction gate and main conveyor belt.

As for belt speed, for 45 bags per min with a 1 m per bag size, that means the main conveyor must be at a minimum of 45 m/sec speed, but more likely 60 meters/sec speed. For this application, that is moving pretty fast. Again, look at starting and stopping, I would think a min of softstart but more likely a VFD. Use the run contact to give a delay to allow the system to come up to speed before you try to induct. Also, I use the photoeye at the counter for induction to look for jams. If I release the bag and it doesn't clear the induction photoeye before the window closes, stop and alarm - or tell someone to go pick up the big mess on the floor. Again, I really don't think you need a fifo or array, I think it can be done with simple logic (with or without an encoder).

OK, I'm not too good with the typing . It should be 45 meters per minute. Still, to allow for gaps, the conveyor speed will likely be closer to 60 meters/min (or 200 ft/min or 1 meter/sec). However you look at it (except as 100MPH ), it is still a pretty fast moving conveyor for merging on bags. Our system runs at 100ft/min and we use a special belt for the merge points (www.intralox.com). You need to look at this part as I bet it will give some additional challenges.

 

[plchacker]

OK after looking at your drawing the 20 counter conveyor should be at least 30 meters long. If you were able to fill all windows, that would mean that you would have to run the conveyor length 1.5 times to cover 45 bags/min. In that case, given another 15% for peace of mind, and foulups, you are looking at about 52M/min to ensure the desired rate. That is rather quick for baggage. It can be done.


I think it was O'Hare, in Chicago, that I was amused by bags piling up at the curtain before they went to neverland. I was amused because it was as if the bags were fighting the up-coming torture.

I know it was Rome International where my garment bag was ripped to shreads, lost a great siut. Pensicola, had the best, no traffic. I won't even mention JFK, ATL or DFW.

Yep, this one is a good one.

 

[Peter Nachtwey]

Not making much progress.

Yep, this one is a good one.

Yes. You guys should see a lumber sort move. Lumber sorter use encoders to keep track of position. Hint, hint.
So how does one keep track of the data and what data must be kept?

 

[appleplc07]

Just some clarification on the speed and throughput....
The throughput of the whole complete 16 counters is 45 bags/min. It is different from the main conveyor belt speed which is 30 m/min.

There is indeed progress.... we now know it is possible to use photoeye for this application with simple and clear cut. No complicated tables etc...

But as an alternative, i am exploring the idea of using Absolute Encoders to create the windows. This is more challenging as for the 16 counters, the main conveyor belt is actually divided into three smaller belts. As it was correctly stated, the length of the 16 counters is more than 30 m, and physically we got to divide the conveyor into 3 smaller conveyor section. Each conveyor is controlled by a VFD. The challenge is moving and keeping track of the windows from one conveyor section to another......

 

[plchacker]

Yes. You guys should see a lumber sort move. Lumber sorter use encoders to keep track of position. Hint, hint.
So how does one keep track of the data and what data must be kept?

I have. Sorters have two big advantages. 1) they have effective descramblers. 2) they have dogs on chain to position each board, once it is positioned it will stay put for the most part.

The concern here is the inconsistancy of baggage. I highly doubt it will behave as we would like. There will be bags with wheels, bags that bite well and don't slip, and bags that get hung up at some point. The counter agent will correct the jam on a good day, but on an average day the agent will simply watch the pile grow.

My first thought was a Gray code encoder, and a bit array. This was wonderful for timing sheet position and spraying glue in a very tight pattern. It also worked for tracking dry veneer sheets to a sorter of a different type. I also used an encoder to measure the width of veneer to within an 1/8 inch while the veneer was running at 600 fpm and sprayed short sheets. I like encoders.

Then I remembered the trouble we had with veneer running at 1000 ft/min. and the slippage that came with accel/decel. This slippage changed as the belts wore. The veneer was simply five to six feet away from where the system thought it should be. The fix was a limit switch that said, Hey I have veneer at the end of the line now. Not eliminating the usefulness of the encoder, but still not an ideal situation. I am afraid that the baggage would fall into this catagory.

Breaking the system into shorter conveyors with VFD's is a very good call. Powerflex has great tracking, even without feedback. With feedback, the speed is nailed down.

If money is key, you can use a prox switch and a wheel with two or four points that the prox will read to make a poor man's encoder. I used these as speed detectors on conveyor systems to detect broken chains and the like. I played with them some, and was able to track speed. Its lower resolution, but it works.

 

[elevmike]

Apple,

What you will need is a low resolution incremental encoder on the main conveyer. The convery is only going in one direction, so the encoder will require just ONE input on the PLC. The encoder will provide two peices of information: 1) it will create the windwos, and 2) it will track the position of the windows in relation to the merge points.

Prediction: If you attemt this without an encoder, you will spend way more in attempting to debug the system then the cost of the encoder. Eventually in the end you will then come to the conclusion (after a lot of heartach, $$$, and sweat) you will place an encoder on the main conveyer. So you might as well do it now.

 

[burnerman]

Any chance of the belts slipping?

Reflective stickers every, say, 10cms on the belt, a retro-reflective photocell (looking underneath the belt to avoid luggage getting in the way!) then simply use counters in the PLC to generate your windows.

 

[elevmike]

Any chance of the belts slipping?

Reflective stickers every, say, 10cms on the belt, a retro-reflective photocell (looking underneath the belt to avoid luggage getting in the way!) then simply use counters in the PLC to generate your windows.

If they use the proper conveyer there will be little or no chance of belt slip.

The stickers your proposing will eventually wear, peel away, or become contaminated, and will cost no less to install & maintain then an encoder.

 

[brucechase]

One more thing to consider about using just photoeyes. If you fix each and every window at 1 meter (plus a little space) via an encoder, then you have a fixed number of windows on a given length of belt. If you use what I suggest, then you "look" for a 1 meter window to put a bag in. This could actually give you more throughput. Take for example a bag that is only .3 meters long on the belt. If you use the photoeye method, then when there is a 1 meter long window after the bag, the next counter will induct. As the bags get further down the line, this will tend to fill the belts better. Using the encoder method, the window will have to be 1.6 meters long to induct (since each bag takes the entire 1 meter). Now multiply that by how many bags that will NOT be 1 meter long and you have significantly reduced your thoughput.

Prediction: you can do this without encoders or using fixed 1 meter long window lengths.

 

[appleplc07]

Real window Reservation

Hi all...

Thanks for all the inputs. I am designing the system using the photocells on the main conveyor. Will submit for approval and see how it goes....
In any case, i will share with you how this is normally done in the airport for our reference and discussion.....

For 1m bag length, the logical/virtual windows size is 1.5m length. This windowing is done purely with absolute encoders only. Only 1 bag will occupy 1 window.
As shown in Figure 1.0, once a baggage is on the induction conveyor, it will search for the free window and reserve it for itself. Once the window reaches it, it will induct the baggage onto the window.

As you realise, upstream counters have better chance of getting a window than the downstream counters. So a priority induction control is employed to avoid starving the downstream counters of windows. This is shown in Figures 2.0, counter 5 reserve a window. Then counter 8 came along and overrides counter 5's window.

How the above is done in the PLC, perhaps we can go into more details if anybody is interested. I think there are several ways to achieve it.

First question is.. which is better... absolute or incremental encoders?

Looks like the method with the photocells only can also do the job with less complicated programming compared with the above. Do you agree?

regards,
ApplePLC

 

[appleplc07]

Any chance of the belts slipping?

Nope. No chance for the belts slipping. Very robust design.