Using a Shift Register function in a SLC 500 processor

Hi, I am using a color sensor to detect 4 different color labels on different boxes to direct routing to a specific location; Lane #1 - Lane #4. I am currently letting one box route at a time. This works, but the problem is that the line starts backing up. What could I do to keep the flow of cartons going and still route cartons to the specified lane? I have a photoeye at each lane and a photoeye down each lane. Any suggestions? Thanks, Shawn

I'm currently doing a similar application using barcodes and part #'s. My approach is to treat the area between the label scanner and the 1st lane as 1 FIFO, the area between lane 1 and lane 2 as a different FIFO, etc.

My sequece goes something like
1) Scan the code
2) Load value into FIFO (1-4)
3) Box reaches Lane 1 sensor
4) Unload FIFO to a destination (Part present at transfer)
5) Compare, if equal to lane 1 then send down, if not equal, load value into FIFO 2
6) Rinse and repeat for all lanes.


This is my first shot at this particular scenario, so probably not perfect, but it works in my head.



The only other thing to consider is a purge sequence incase you lose position of a box in the system. Mine is just run conveyor for X secons and reset all FIFO values/positgions to 0.

Our conveyors operate this way (similarly to Christoff84's):

1. A (numeric) barcode is read
2. When the box BLOCKS the first PE the barcode value is placed in an integer register, let's call it R1.
3. When the box CLEARS the PE, the content of R1 is moved to R2 and R1 is cleared to zero.
4. When the box BLOCKS the next PE, R2 moves to R3 and R2 is cleared.
5. When the box CLEARS the next PE, R3 moves to R4 and R3 is cleared.
6. This process is repeated for as many lines as needed.
7. At certain lanes, Rn is tested against a reference value to determine if the divert mechanism is to be activated.

One very important point is to not let the boxes onto the divert conveyor at a rate such that the register numbers get overwritten by those coming behind. I believe the technical term for this is an 'asynchronous' shift register, so named because the registers shift independently rather than all at once from a single input.

This method doesn't require a separate purge mechanism since any box coming down automatically overwrites any previous data. Also, since both edges of the package are sensed, either could be used to trigger a divert, depending on the lane PE location.

The drawback to FIFO based sorting is that things can get into the wrong lanes simply because one of several photocells has been pulsed one too many/few times, getting the FIFO length out of sync with reality. Once the system is out of sync, and if no one's looking, you can have a real mess real quick.

I have rewritten several sorting systems to use position based tracking, so that the PLC knows the position of each object in transit.

Done this way, you only really depend on one photocell to keep the sorting straight. (It is easy to detect one flaky eye and automatically stop the line when it acts up.)

In the logic, there are several different ways to abstract the concept. Here I have one in which, there are four short conveyors involved and no more than six or eight boxes between the barcode reader and the last diverter. So, I keep track of each box position as a floating point value representing "inches past PExxx". Each scan, I update my array of boxes in progress, and when one of them is within the "window" to activate a diverter and it's ID code matches, I trigger the diverter.

If the conveyor is really long and there are many more pieces in transit, then I will "map" the conveyor with a data table, so that the ID code for the product gets dropped into the data table at an index representing the position of the whole conveyor. Then the lane entry and exit points are calculated as offsets from the rolling position pointer. The data does not move around, only the pointer representing the end of the belt. In software, this is very efficient and still reliable.

The concept can be daunting at first, but it is really not any harder to set up the logic than it is with FIFOs but the results are nearly bulletproof.

When I started on my last one, I was told that it is imperative that we never send the wrong box down any of the lanes, and my new logic accomplishes that where as the FIFO stuff I replaced would have to be cleared and reset at least once every couple of days. That clearing and resetting required operators to manually move boxes around and stop the flow of product too, so they really like the fact that it never misses a beat any more.

My 2 cents,
Paul

OkiePC said:

<snip>
a floating point value representing "inches past PExxx". Each scan, I update my array of boxes in progress, and when one of them is within the "window" to activate a diverter and it's ID code matches, I trigger the diverter.
<snip>

Click to expand...

Paul,

I can see how your system would prove effective, as I have hit problems with using FIFO's reliably. How do you accurately track the distance travelled? My assumption would be an encoder, as a timer is sometimes not that accurate, especially if the conveyor is starting/stopping along the process.

In my own situation, the conveyor is on an AC Drive with accel/decel times, and we use 90 degree pop-up transfers where positioning is extremely important.

This is an interesting way of looking at it, although not too sure how I would implement this on a SLC 5/04 in ladder. I don't think I would trust anything less then an encoder to accurately track distance travelled.

Chris