Conveyor Control - Window Reservation

Hello all,

I am working on an airport baggage handling system with 10 check in counters to merge to the main conveyor. I am to use a technique called "window reservation" for the merges.

This technique uses encoders to build an in-memory representation of the conveyor partitioned into "windows".

Anyone can guide me on how this above is done conceptually?

And is there an alternative way to do it without using the 'encoders?

regards and thanks,

Nice problem

This is probably the most difficult queuing problem that anybody has posted so far. Those of you that have programmed a recirculating lumber sort have an idea of what the problem is.

ApplePLC07, visit a lumber mill for inspiration.


You need encoders. Timers will not do unless the conveyor is always moving at the same speed. There are other ways if you have release points and photocells. It is possible to have restraining devices that keep luggage from moving forward but I would think that would be risky as not all luggage is the same size a some luggage could slip by which is bad. Perhaps if the bags were put in moveable bins that wouldn't slip by.



Do you have the option of slowing down the conveyors feeding the main conveyor? This can be a good option to have and why encoders are necessary.

I will give others a chance to shine and bump this up as this will be a real learning experience for many.

ApplePLC07, how did you get assigneed this project if you don't know how to do it? Air port bagage systems are not trivial. I wouldn't give out a contract to someone who did know immediately how to do it. Do a search on the Denver Airport bagage system. It was thoroughly botched and cost a lot of money to redo.

My concept...



I did look at the Denver air port project and luckily my scope is not as big as that. We are just doing a tiny part for the airport baggage handling system. Our scope is the check-in counters and the transport of the luggage to be handed over the airport's baggage sorting system. Our scope ends there when we hand over the luggage to the sorting system. And the sorting system is the most complex of all.

Anyway, i have come out with a concept which i think may work. As shown in the dwg above, i have 10 check in counters and i have the main conveyor belt running at a fixed speed. Therefore, i may do away with the encoders. The luggage is of fixed length i.e. 1m maximum and so no worries about the different sizes of the luggage.

I plan to divide the main conveyor belt into logical windows of equal size. Let's 10 logical windows. I will then translate the logical windows into a table in my plc. This table is initialise to be free upon startup.

I have photocells on the check-in counters to detect and stop the luggage while waiting for a free/unoccupied window. Once it is free, i will inject the luggage into the respective windows and set them as occupied. After t1 as i know the speed of conveyor is constant, i will move the index table as shown.

With the help of the table, i will then know which window is occupied and when i can inject new luggage into the free window.

The constraints is that if there is a power failure or plc failure, upon startup the operators must clear the whole conveyor line as the plc index table is initialised to be zeros.....

Please feel free to comment as this is an initial concept. I may have overlook many things.....

regards,
ApplePLC07

ps. yep we may not have past experience in this kind of project but we got to start somewhere... if projects are given to experts only, then most of newbies will be out of job...

Apple,

You can take care of the power failure, by using retentive registers to save the luggage positions, thus eliminating one time that the opertors don't have to go out and do manual labor. They would thank you for this, if they only knew....

As for the PLC failure, the only thing you could do here is to use redundant PLCS, an expensive proposition.

Luggage fixed length? Don't you believe it until you have spent several hours at an airport check-in counter. I have seen bags so large that the agent could hardly lift them onto the conveyor. People will try anything, and the bags are NOT all the same size. However, you may be able to do without the encoder in this case, if you have sensors on BOTH conveyors, to detect bag length, and a space into which to put it.

Your "index" system appears to be doing the same job as "an encoder with photoswitch inputs', except that it is dumb, and blind. Apparently it has no inputs to tell it that the bag fell off, or got hung up, or was picked up and removed by an agent. You have the photoswitches, why not use them to detect the "holes"?

Nice little intro to queueing theory (and practice!). Whether baggage, tomatoes, or beer (hic), it's all the same. Other ways it's been done:

1. Freq. drive moves main conveyor at known speed, so slot position is deduced. Just as good as an encoder where precise & tight fits are not necessary.

2. Criss-cross photoeyes into receiver section such that they (nearly) guarrantee an empty slot. Most reliable way to load belt. Even better when coupled with knowing where the slots are expected to be.

3. Move main belt one complete length while counter belts are stopped, then stop main belt and receive all incoming product, lather, rinse, repeat. Works if speed of main belt is more than twice as fast as incoming product. Sensors need not apply. (I've never seen this done with luggage, and I wouldn't recommend it, but it sure is simple).

With either known-slot method, you'll need a prioritization scheme to ensure you don't starve those down the line from getting a slot.

Consider not splitting up the belt into discrete sections but simply monitoring the position of available slots as they pass by each station. This way the software can decide whether or not it needs to make a slot for something downstream, and just make a new one where ever the belt happens to be.

The killer with most faulty systems is that the designer(s) never imagined all the regularly occuring abnormalities to their ideal world. So spend good amounts of time reviewing your design and algorithm with as many "what if..." pathological scenarios you can dream up. Things like product getting momentarily stuck, falling over, sliding/rolling ahead during belt stopping, foreign stuff landing on belt (like people or luggage thrown on by hand), etc.

And make it robust such that one knocked out photoeye won't clog up the whole line, or that really short or flat or skinny luggage gets unnoticed and clobbered, or that if a theoretical slot is suddenly detected as occupied, the system doesn't sweat it.

Good on you for giving it a shot, it's the only way to really learn.

What language are you writing it in?

We're doing this but with stacks of tortillas coming out of stacking machines then being fed into baggers or wrappers. But it's not as robust as the luggage carrier would need and has no memory at shut down. This doesn't cause problems though as those get removed anyway.

Well, i am using the S7-300 PLC and the language will be in ladder or FBD. The luggage will not be in a fixed length. Just that the specs. say that maximum length of a luggage is 1m. Anything more that 1m, will be manually carried into the system instead of the automatic conveying system.

Like any other projects that we plc programmers face is budget constraints! If given a blank check, i would have put in encoders and photocells or RFID if possible. But reality is, save money on the hardware but use more manhours to do the complex programming...

With this timer to move the index table, the problem is that the timer in the PLC may have an error. The main conveyor belt is rather long.... so by the time the table is indexed down.... what i have in the table may not be the same as in the conveyor belt...

Based on the table, the plc may think it is a free slot but in reality on the conveyor belt there may be a luggage there - due to the timer prolem... so i may potentially inject a lugagge onto an occupied slot and wham! Somebody will then be really **** about his luggage!

Apple,

I must have misunderstood you diagram. You show two photoswitches, one on EACH side of the incoming luggage conveyor. I thought that one was reading the traffic on the main conveyor, and one is reading the merging conveyor. If not, then why not?

Oh, I see now that you actually have two merging lines at each point, and a photoswitch for each. Will one photoswitch not work for two merge lanes? If not, I suggest adding 5 more photoswitches to monitor traffic on the main line.

Move these new main conveyor photoswitches far enough upstream from each merge line, so that it can see 1-meter long HOLES (not bags). Then you know a gap is coming, so start the merge conveyor to dump a bag. Use the main conveyor photoswitches to "measure" the length of the next hole: Switch sees hole: start timer, switch sees bag: stop count and compute length of hole based on speed of conveyor. If hole is long enough for next bag on merge line, then perform a merge. Repeat for each merging line.

You can use the same timing method to compute length of next bag on the merge conveyors also, except you must make sure it is running at full speed, or at least know the actual speed.

This method does not rely on an encoder, or the accuracy of the PLC clock, except for short-term periods, for which it is accurate enough. It does not even ASSUME that the next bag is 1 meter or less in length! Instead, each incoming bag is measured, or rather, the space between the bags is measured.

Add logic for lines 3 through 10 to perform triage during heavy traffic, so that an equal number of bags are moved from each line. Here I would add some "smart" logic to use the merge line photoswitches to also count the number of bags/minute on each branch line. Each merge line gets assigned "holes" based on the PREVIOUS 1-minute count (Bag Counter1 divided by Timer1 accumulated value) of bags per minute on that line. As traffic thins out on a line, its hole assignment gets lowered proportionally.

appleplc07 said:

But reality is, save money on the hardware but use more manhours to do the complex programming...

Click to expand...

This never works out like the guy quoting it thinks it will. Complex programming exponentially increases the amount of debug time and usually surpasses the cost of those extra sensors they decided against.

Want to get this job done and debugged in a timely manner? As pointed out earlier, put those sensors across the main belt before the counter belt intersections to detect openings. Then the code for each counter conveyor entry will be identical and you won't have to track baggag once its released to the main belt.

(Optional) Put "health" check sensors just down stream from the counter intersections to verify the luggage was released and is now traveling down the main belt.

appleplc07 said:

We are just doing a tiny part for the airport baggage handling system. Our scope is the check-in counters and the transport of the luggage to be handed over the airport's baggage sorting system. Our scope ends there when we hand over the luggage to the sorting system. And the sorting system is the most complex of all.

Click to expand...

I suspect that really isnt the case. Getting the bags on the the main conveyer seems more complex and might take more talent/imiganiation then getting them off of it. The quality of the output entirely depends on the quality of the input.

The fist major problem is assuring the checkins at the end of the line has the same and equal op to put a bag on the conveyer as the checkin at the begining of the line.

My suggestions:

1. Make all the "windows" the same size (large enough for the largest bag allowed). The size of the window likely should be maintained throughout the entire system because somewhere down the line there are diverters that push the bags off the main conveyer to the individual gates. If you compress the windows to fit each individual bag then they will have to be re-spaced before they are diverted to the gate. (IOW give up spacing efficiency for KISS).

2. As the windows emerge at the begining of the line assign each window to pick up a bag from only one of the checkins that are currently open. For example if there are only 3 of the 10 checkins open, then assign the windows 1, 2, 3, 1, 2, 3..etc. Presumabley all baggage from a particular checkin is going to the same flight/gate. This will assure the last checkin to place a bag on the line the same opertunity as the 1st checkin, and assign that window to the destination gate.

Old solution to old problems.

appleplc07 said:

ps. yep we may not have past experience in this kind of project but we got to start somewhere... if projects are given to experts only, then most of newbies will be out of job...

Click to expand...

That is why there used to be a master and apprentices. It is a far more efficient way of passing on knowledge than just letting the apprentices learn how to re-invent the wheel on each application.

Heed jstolaruk's advice about the real cost of sensors.

2. As the windows emerge at the beginning of the line assign each window to pick up a bag from only one of the check-ins that are currently open. For example if there are only 3 of the 10 check-ins open, then assign the windows 1, 2, 3, 1, 2, 3..etc.

Click to expand...

That is easy, not efficient but easy. How fast are the ticket agents? Perhaps, efficiency is required.

From the drawing it appears that the conveyor from the check in counter to the main conveyor is small. How many bags can the check in conveyors queue? Can the check in conveyors be stopped? This is key. There hasn't been enough info.

The main trick is making sure there is only one bag at the merge points where the check in counter bags are dropped on the main conveyor. If the checking conveyor has three 'windows' and can't be stopped then there needs to be a way of detecting an occupied window three windows up stream from the merge point on the main conveyor.

If the ticket conveyor can be stopped the problem is very easy as one can just wait for an empty space and use Mike's method to allocate windows on the conveyors to check in counters.

I would use STL and SCL. This project will require indexing into arrays and possibly user define data types to define the structure within the array elements if one needs to keep track of more than the destination or flight number. Like a lumber sorter, this application will need to keep track of not only that a 'window' is occupied but also where the bag is going so it can be diverted at the right time by the sort part of the program.

LD and FBD will not be the best tool for this. You will see when you try to do array indexing.

I would use encoders with a first and last count for each 'window' that way the window sizes can be dynamic. I would also follow jstolaruk's advice and use photo eyes to verify the baggage isn't sliding on the conveyor or falling off the conveyor. Putting the luggage in bins that move on the conveyor would be more sure way of moving the luggage around.

Peter,

My previous post was based entirely on the size of the system. Given 10 check in counters, (possably for the entire airport??), it seems that the traffic isnt that demanding, so my proposal does give up efficency for simplicity.

Since 9-11 I havent been on a commercial flight, and before that I never checked a bag so I'm not sure if the check in counters are spicific to a particular flight or not??

In any event if the windows sizes are to be dynamic then the diverters (by others) must also be dynamic. This makes a huge difference. Dynamicly sized windows would dramaticly increase the complexity & cost of the system. This may be necesary or not, but should be studied and decided before anything is started.

Also I would presume that there's an accumulator at the check in counter that would hold and place the bags in an approprate manner on the main conveyer. I dont see anyway around that. If the system does require dynamic spacing, then the bags need to be measured at each check in counter as they enter the accumulator. If you dont previously assign windows of the approperate size on the main conveyer for a particular bag, then it'll be a long wait.

So if you need dynamic windows and reqire efficency, then you have to measure the bags as they are checked in, then assign a window of the approperate size spicifically for that bag as it emerges from the begining of the main conveyer. That window will then pass the previous check in counters, and the bag will be dropped on the conveyer as the it passes that check in where the bag is waiting. Much easer said then done. The question is: Is it necessaary?

Hi all,



Sorry for the incomplete information as i did not want to complicate matters by giving too much information.
Anyway, the luggage maximum size is not more than 1 m. Any luggage longer than 1 m will not be checked-in by the operators at the check-in counters. This check is done at the Weighing Conveyor. An alarm via a local indicator switch will light up if the luggage is longer than 1 m and it is up to the operator to reject the luggage.
Like any other projects, we have to balance the cost...... too many photoswitches will be the same as putting in the encoders. So, as usual software programmers got to work overtime (unpaid) to find a way around it. We may only put 1 photoswitch each just before the Induction Conveyor as shown. But i need to check the distance between the check in counters as they are less than 2 meters apart and therefore maybe only 2 photoswitches can be put in.

I will agree that STL is better suited for the array manipulation....

The photoswitch on the Induction Conveyor will be used to stop the luggage while waiting for an unoccupied window.

FYI, actually there are 36 check-in counters. I just put it as 10 check in counters in order not to complicate matters. In fact, the check-in counters are divided into two areas... 1 area has 16 counters and the other has 20 counters. Once the luggage is checked-in, they will be conveyed into complex and long conveyors whereby they will be x-rayed and scanned and moved, merge or diverted to other conveyors to be sent to the correct gate. This part is even more complex and not in my scope. This control is in fact the heart of the baggage handling system.

Thanks for the input. I will do a detail design soon and all comments are welcomed and will be considered seriously.

Apple,

My current question is can you leave EVERY window on the main convery at a 1 meter lenth, or do you need to dynamicly size the windows for each bag? If you change the window size to fit the bags, then you will move more bags faster, but it would require a much more complicated setup then if all the windows were of the same size regardless of bag size.

As I see it the whole thing is predicated on the answer to this question, and the answer is predicated on how the baggage is to be diverted by the system (by others) further down the line.

appleplc07 said:

...... too many photoswitches will be the same as putting in the encoders.

Click to expand...

No, not really. An encoder can't account for a bag getting snagged or falling off and getting put back on by an operator. Maybe in a perfect world.

IMHO, its best to go in thinking that the luggage is not necessarily synchronized with the conveyor betwen counters. Those reflected photo-eyes across the main belt will be the key to releasing luggage.