Container ID Tracking on Conveyors

Dear specialists....

I have an application to track about 50 containers in a conveyor belt systems. Each container has a unique container ID and i am suppose to know the location of the container on the conveyors throughout the whole plant.

Basically, the containers will be scanned once by a Barcode scanner manually and the ID kept in the S7 PLC. After this the containers will be moved in a series of conveyors.... the conveyors will zig zag around in the whole airport and can run for a few kilometers.

As shown here, which is a small area of the conveyor belt system, each conveyor has its own inverter to drive the conveyor. And each conveyor has 2 induction proximity sensor to sense the presence of the container and also used to move/stop the containers.



I need some concept/idea on how to keep track of the containers after they are scanned into the S7 system. Thanks.

regards,
Louis

A very basic idea is to use a block of registers, one for each conveyor. As a container is put on the first conveyor it is scanned and the ID number is copied to the first register. The conveyor is started, the container moves to the next conveyor. Use the sensors to detect this movement from one conveyor to the next. When the sensors show a container has moved, shift the ID in the register to the next register.

Obviously a real solution would be far more involved, but this might start you thinking. Do a little investigation into the use of queues and stacks in programming (these acronyms are a good place to start: FIFO, LIFO).

The biggest problem with the system you described is this; What happens when someone lifts a container off the conveyor?

Thanks for the quick reply.

Well, i have thought of that. In the likely scenarios such as :
1) power failure
2) inverter fault, operator will switch to manual, and manually jog the conveyor over.
3) conveyor failure, operator will push the container the next good conveyor

there will be a WinCC HMI to open up a faceplate to manually enter the container IDs into the system.

And if somebody were to lift the container out, then it is a operator problem which mess up the whole logic and they have to probably manually enter the correct ID via the WinCC.

I use to work for a company whos' product was manufactured on pallets, these pallets where moved around the production line on a bosch conveyor system that was fitted with RFID readers.

Each product had a unique barcode on them, the operator would scan the barcode, and then manually place the product on to a pallet which was at the "load station".

The plc already new which pallet number was at the load station, because the RF reader had already read the RF tag number and stored the number in the plc. When the operator scanned the barcode, the barcode information was stored in an integer file that related to the RF tag on the pallet. The pallet would then go around the line stopping at each station, being read by an RF reader, and being worked upon by automated machinery, each machine would then add information to the pallet number at it's station and build up a traceability file.

The concept we used for pallet tracking was "RFID", each pallet had an RF tag fixed to them, and where identified as between 1 and 99, each station had an RFID tag reader, that would read the pallet number from the RF tag, and would be able to access the corresponding file in the plc, by tracking the product this way we always new were the parts where and if a pallet had been through a station or not.

Hope this helps
Sparky

Thanks Sparky for the input.
Unfortunately, this project does not have the budget to have the RFID system.

We are doing all this manually ie. the container will be scanned only once by the operator and put onto the conveyors.... after that there won't be anymore scanning..... RFID will definitely be easier to implement i guess..

HI Apple

yes, RFID is a near foolproof system, it worked very well in my last factory, and was operator proof.

Management always want the best, but don't want to pay for it.

Good luck with the project.

Sparky

If your concerned about power failure, manual operations, & or somebody manually removing a container from the system, then you really have no other choice but to track the containers with mutiable RFIDs or Bar code readers. Otherwise if you just scan it once on the input, and any of these events occur, ALL your containers will be missidentified thereafter. RFID is really not that expensive considering the clamity of the possable results. Under the circumstances you stated, you will need to read the container ID as it enters and exits each conveyer or subsystem, or at each diverter.

There are big advantages to RFID over bar codes. The package will not need to be orintated in a certain manner to read the package ID. The RFID tags will be more durable and reliable then the bar code lables.

Yes RFID will cost more, but it will be less troublesome in the long run. In a system as large and complex as you discribe, it may be the lest expensive in the long run, due to lower operating costs and less need for operator intervention.

Louis,

For a package-tracking conveyor system with ONE bar-code reader, the old traditional way was to:

1. Make all the conveyor belts travel at the same speed. You should be able to do this easily using the Variable Speed Drives.

2. Install a "spacing" conveyor immediately before the scanner to make sure there is a known distance between packages.

3. Install an encoder (or other device- maybe only a prox switch and target) at the scanner site, to measure the travel distance of the conveyor and to insert a bit into a Bit-Shift Register. You must know what the ratio is of input pulses to physical distance traveled by the conveyor belt.

3. Set up Bit-Shift Rregisters in your PLC program to track the packages, similar to below. You must set up the BSL so that it "maps" the conveyor system. In other words, for every physical x coordinate point on the conveyors, you have a bit in the BSL, that is equal to 1 if a container occupies that space, and equal to 0 if it does not. In most cases, this takes a series of BSL's cascaded together to get enough bits to map the entire system. I normally use 1 bit = 1" horizontal distance, but it depends on the accuracy needed and the distance between containers.


4. Use the photoswitches to pinpoint the position of each package on each conveyor. According to the BSL, when a package is "expected", or due to arrive at a photoswitch, then start a "search" routine that checks all the bits within a range, of say, if your distance between containers is 18 inches, then +/- 17 inches, in the Bit Shift Register. If the package is found (bit = 1), then it's bit position in the BSL is corrected. This way, any variations in speed between belts, or belt stretching, or someone picking up the package and slightly re-positioning it, are all taken into account. If the package is not found where expected on each belt within +/- 17 inches, then an Alarm routine can be started, and appropriate steps done, such as having the operator manually reenter the package, or mark it as lost.

5. If the containers must stop at stations, then they have to somehow be re-indentified. The usual way is to have branch diversion belts where the container is kicked off, some function performed (person adds or remove contents), then the package is put back on the "return" belt that carries it back past the scanner, where it is reintroduced and remapped into the system.

Thanks Lancie1 for your detail info. Now i have a clearer idea on how my project will work.... will report back again on my progress, hopefully with good news...

Did something similar tracking tires on a conveyor belt through a series of diverters, and so on. I used the belt encoder feedback to drive a variable that represented the conveyor in feet and rolled over at 210' (a little more than the length of the conveyor) Each time an item entered the conveyor (16 drop points), I just dropped data into a "map" (210 integers). I indexed the new item's destination in the data table at an index equal to the encoder driven pointer (representing the end of the belt) plus the offset distance from the end of the belt to the entry point (with wrap around; i.e. an index of > 210 would have 210 subtracted from it.). If your entry points are fixed, this offset can be a constant. Anyway, instead of bit-shifting and fifo stacks, this method is nearly bulletproof. The conveyor can stop, back up, run intermittently, and the data will still "line up" with the real objects. It's very efficient and reliable. I used the photoeye at the end of this drop-zone conveyor to trigger a sort routine that looked at the data located at the end of the belt. The jump was conditioned to only occur when the whole feet register changed. The sorting routine looped through the first 3 locations in the data table to find a destination to associate with the photocell signal. The data then moved (as in MOV and CLR) to a FIFO for that next section of roller bed conveyors with diverters.

Conceptually it's hard to explain, but it may give you ideas. Working with whole feet and integers may not seem precise, but for tires, it's plenty of resolution, and the logic I used to scale the value retained the maximum precision possible for the encoder. If the conveyor moves in both directions routinely, the scaling would need to match the actual distance bewteen the photocells very accurately. In my case, reverse was only used in an emergency to feed into another line, and my distance was really about 208'-6", but with the sorting loop looking at up to 3 feet of conveyor, it worked fine in both directions, and when frequently stopped and restarted. The only time it ever needs resetting is following maintenance or ballups during which the tires are manually moved around on the belt.