Box tracking with print an apply Help!

Hello Everyone,
I currently have a project (using AB ControlLogix CPU and Ignition for HMI) as follow:

1. An operator fills a box with xx product generates a barcode send the box down a conveyor.
2. A scanner scans the barcode and searches an SQL database to get the box information (e.i. weight,type,destination)
3. The box is weighted and determine if its withing specs if not mark as reject.
4. Three print an apply printer, two will print one will be on standby.
5. Two scanners to verify the box and the printed label.
6. One divert conveyor for the reject lane or lane B.

>===PE/Scanner===PE===WeightStation===PE===Printer1==Printer2==
>PE==Scanner===PE==Divert Conveyor===Either Reject/Lane A/ Lane B.


I'm thinking of using FIFO to keep track of the box through the process. Does anyone have a sample codes that might help with what I have described above?

See Post #7 in this previous thread for a complete box-tracking RSLogix500 program. It uses a bar code scanner, a conveyor with position encoder, and multiple bit-shift registers (instead of FIFOs).

http://www.plctalk.net/qanda/showthread.php?t=74614&highlight=conveyor+tracking

Thanks,
I'll take a look, my system does not have an encoder but never the less I will check it out..
Thanks.

Without an encoder, you are limited to only being able to divert the box immediately after a scanner has read the label. You cannot divert it farther down the line, because you have no way to track the physical position of each box in the PLC memory.

My preference for sorting routines is heavy on indirect addressing and pretty elaborate, can work well without encoders and is all in all bullet proof in action until belts snap or cylinders start leaking. there is no reset tracking button there is no sorting stuff to the wrong lane ever no mater what sensor fails as long as it isn't the first one in which case the line shuts down.

I just build a data table to hole the contents of each section and drive pointers that move through these "maps" using measured command speeds. The end result is that every container in transit can be located at any given time, actuators driven by ranges of positions (in engineering units) and a handful of other benefits.

I am also a proponent of the Hardy Instruments 1769-WS scale module for compactlogix if you need to build an in motion check weigher, it is probably fast enough to do the job. They make a controllogix version too.

Lancie1 said:

Without an encoder, you are limited to only being able to divert the box immediately after a scanner has read the label. You cannot divert it farther down the line, because you have no way to track the physical position of each box in the PLC memory.

Click to expand...

I would say the encoder is not completely necessary; Maybe a nicety to simplify code but otherwise completely possible - try something along the lines of a shift register / FIFO controlled from both PECs available to him.

Both could be made to track the boxes through and position them at the correct point for the reject conveyor

Whether an encoder is necessary or not depends on the length you are tracking and the number of conveyors.

Short length on 1 conveyor, can be done.

Long length and/or more than one conveyor, then would need something to create a pulse.

I've tracked with encoders and also a simple proximity with a star wheel. The sensor must be on the non-driven roller. Multiple conveyors would require one on each conveyor.

The things a pulse will give you is:

* The ability to maintain a fairly accurate tracking of the object
* Account for speed changes (either control or wear).
* Account for Belt slippage.
* Starting and Stopping (speed changes)
* Speed changes between conveyors.

The encoder would normally be accompanied with sensors at the head of the conveyors for die-back control and synchronising your objects.

Agreed PeterW, but I suppose that being a checkweigh / reject system, the rejector has to be very close if not directly after the checkweigher itself and anything on a checkweigh system is usually fixed speed. The encoder still can't account for any belt slippage or package slippage as they are usually connected to the drive shaft for positive drive, and having it on the non driven roller does not account for the belt slipping on the roller itself. However all those things are something to take into account and while it is possible without the encoder, having 1 would definitely improve the system.

Since no indication is given to how the "reject" mark is made or where, perhaps the printed label can include this and the scanner can be located at the reject station. If both the scanner and a photoeye at the leading edge are detect the box at the same time with respect to the reject station, no encoder or box tracking is needed.

Just a though.