Product Tracking with a ML1500

plcengineer

Member
Join Date
Jan 2004
Location
USA
Posts
176
Gents: I have an application coming up that I would like to get some opinions on. I have a conveyor that will be running 100FPM that I will need to divert product. Basically, a scanner will be above the three divert chutes to read the barcode to send me a signal. From that signal, I will determine what chute to open to send the product. We will have an encoder on the conveyor that is running so we can track the product. I have installed a HSC in the ML1500 to take in the signal.

I am thinking about different ways to track the product. I am thinking about using Fifo's but then I am wandering how to track the product with the kickoff position. I was thinking that I could setup how many pulses equaled an inch, then calculate how many inches it was from the scanner to the chute. Does anyone have any ideas of how to track the position along with the product?

Thanks,
 
I've done similiar (read bar code, check vs. what should be running, if not proper, remove from line). I used logic to break down what needed to happen, and a simple shift register. Worked well because the data was pass/fail (1/0) and I used the encoder input to track position and step the shift register. You could step a shift register with a sensor as well if you wanted.
 
Do you have any sample code with FFL and FFU? Or, should I be looking at BSL etc? How did you do the tracking with the encoder? I guess I am wandering how you stepped the shift register.

Thanks,
 
I have a copy of the code somewhere at home. I'll try and dig it out. I did it in Directsoft, but the conversion to RSLogix isn't too difficult.

The flow of logic was pretty basic, I figured out how many pulses it took to go from sensing to reject, and used that as a preset counter value. Use the pulse count as the accumulated value in the counter, and when the counter finishes counting, shift, and reset counter.

I'll see if I can find it.
 
I agree with CroCop...we have done something similar to it...we used a Shift Register and 1- good, 0- bad ( we used automation direct)...
note: read the manual before you use 1s and 0s..sometimes shift register by default has 1s in it....you finally end up accepting all the product.

Automation direct has all 0s by default.
 
Here's a screen shot. I aplogize for the lack it not being a full working program, but I couldn't find the original so I just gave the guidelines.

The jixt is to have 2 seperate shift registers, and tie the diverter output together using sensors, or using an encoder input if you like. I like then sensors, it's a little simpler, but if you already have the encoder, you can use that just as well.
 
Thanks for the screen shots. I do have a question. I am thinking about doing the following, so please comment. I may take my HSC input A+ signal from the encoder and hook it to I:1/0 on the HSC input card. Then, if I rotate the shaft, I'll know the approx number of pulses from the scanner to the reject. After doing this, I was thinking that if I saw a reject, I could set a 1 in a BSL and rotate that bit with I:1/0. If I saw the bit 1 rotate in a set window, I could then say now look for the PE and divert. Once I divert, I clear out the 1. Does this sound feasible??

Thanks,
 
Why don't you set the pulse count to zero, set a product in front of position upstream, turn on the line, and stop the line in the downstream position? You would know exactly how many pulses it took to move from a to b then.

Use this number of pulses to rotate the BSL, and then do the compare and divert.
 
That is a good idea for getting the number of pulses from A to B. Maybe I am missing somthing here. Are you saying if the number of pulse = 1000 from A to B, then if the number of pulses = 1000, then run the BSL? I was thinking that I would need the HSC input to rotate the BSL to track the 1 down the line. How would I handle multiple 1's like back to back rejects? maybe I am missing something..

Thanks,
 
Does this sound feasible??
No it does not. That's not how it's done.
First of all you shouldn't use FIFO (asynchronous ) shift register and secondly you can't count pulses.
You need to use synchronous type of shift register.
You will need to construct this shift register by using COP instruction. You need to shift integers not just 0's and 1's.
You need to have an "Induction photoeye" at the point of new
box entry. Each conveyor encoder pulse represents so many inches of travel. Say for example one pulse is one inch.
If you have a box that is 10 inches long you will feed 10 integers into the shift register. These 10 integers represent the box length in the shift register memory. Since most boxes will experience some kind of slippage you will need to incorporate a
"re-allignment photoeye" somewhere down the line.
When box breaks this photoeye you examine the shift register
contents and if you see that the shift register data is ahead
of the physical box position you know that you had some slippage and you will re-allign the shift register data to reflect the
physical world.
After all the re-allignment photoeye is at a known distance
(represented in pulses) from the induction photoeye.

The "Point of divert photoeye" is positioned at the point of divert. When box breaks this PE you will examine the appropriate
stage of the shift register and if there is a number bigger than 0 present you will decode the meaning of this number.
Divert or not divert. Each divert will have it's own photoeye.
If you have 10 diverts you will track numbers 1 to 10.

After the divert is completed you should verify the arrival of the box by breaking a "divert complete photoeye".
In other words the count of boxes sent to a specific divert should be equal to the count of boxes arriving at this divert.
 
I wrote a SLC program that tracked tires on a 210' conveyor. The tires are dropped onto the conveyor at fixed points along it's path, I needed to know which tires were in which locations for later sorting. My program scales an encoder input into whole feet (since no tire is smaller than 1 foot). A data table of 210 elements stores the contents of each foot of the conveyor. I use an integer derived from the encoder to represent the end (output) of the conveyor. So, as the conveyor moves, the integer increments from 0 to 209 and then rolls over. When a tire is dropped onto the line, I simply dropped data in the data table at the location of the pointer plus an offset for the distance from the drop location to the end of the line (with wrap-around). When a photoeye detects a tire exiting the conveyor, I search the first six entries in the data table starting with the pointer, (1st 6 feet of conveyor) find the next entry for the tire and moved it to a fifo for the next section.

The next section consisted of more conveyors with diverters to still more conveyors. For these, I would FFU tires from the stack into a single register when they entered a diverter zone. If the tire was diverted, the data was sent to the FIFO stack for that diverter. If the tire exited the zone without diverting, it's data was copied to the FIFO for the next section. I relied on photoeyes to guarantee whether or not a tire was diverted. That way, if the diverter failed to operate, my tire tracking data would not get messed up.

This method doesn't require moving a bunch of data. The pointer that refers to the end of the conveyor has to be constantly updated, and that's about it. Using the encoder allows the line to be stopped, reversed, and started without fouling up the tire tracking logic. It will run for several months at a time without error. The only time it screws up, is when someone physically disturbs the product (clear jam-ups, etc.) If they move a tire more than a few feet from it's original location, then it will misplace that tire and send it to the default location.
 
The only time it screws up, is when someone physically disturbs the product (clear jam-ups, etc.) If they move a tire more than a few feet from it's original location, then it will misplace that tire and send it to the default location.

This is the reason why most tracking systems will not use FIFO's.
If you lose a box you will screw up the whole FIFO memory, everything that's in the FIFO stack!
I am not saying that FIFO's don't have a place in conveyor tracking and your application seems to be OK but for most part that is not
a preferred method of tracking. I have used FIFO's for tracking
myself in different applications but I would never use it in
a large tracking system with many diverts. The potential for
screw up is too great and potential screw up is too big!
 
I'm of the same opinion. I like the sensors sensing the product, but that can fail if someone puts their hand in front of a sensor.

Back to the original question, what are you reading from the bar code, how many lines can you divert to, and what drives the decision on where to divert?
 
I worked on a system a couple years ago that had the divert lane included as the last two digits in the barcode. I used some masked move and compare equal instructions to strip the rest of the barcode off and determine the correct divert assignment.
 
This is the reason why most tracking systems will not use FIFO's.
If you lose a box you will screw up the whole FIFO memory, everything that's in the FIFO stack!
I am not saying that FIFO's don't have a place in conveyor tracking and your application seems to be OK but for most part that is not
a preferred method of tracking. I have used FIFO's for tracking
myself in different applications but I would never use it in
a large tracking system with many diverts. The potential for
screw up is too great and potential screw up is too big!

In my defense, the flat belt conveyors I was talking about have manual sorting downstream, so it wasn't critical if an error occurred. We have five lines feeding into four sorting stations. The fifth line feeds into the four conveyors via diverters. Before my program change, all the tires on the fifth line were sent to the others pretty much randomly. That meant that the person sorting tires at the end of the each of the four lines had to handle all the different products from the fifth. My program change allows them to control which tires from the fifth line go to which conveyors (1 through 4). If I had bar code scanners, there would be no errors. I used what we already had...an encoder and a photoeye. Zero downtime...all done with online programming changes. I don't use FIFO to track what's on the flat belt conveyor. I use a data table with an encoder based index scaled in feet. The FIFO stacks are used for roller bed conveyors that connect the 5th line to the diverters. My FIFOs are subdivided with error checking so if a tire is removed, sorting will be disrupted for a maximum of about ten tires, and then it self corrects.
The only time it screws up, is when someone physically disturbs the product (clear jam-ups, etc.) If they move a tire more than a few feet from it's original location, then it will misplace that tire and send it to the default location.

This only happens when there is a mechanical failure or ballup..I haven't yet learned how to program around those situations yet.

The intent of my original post was to point out a method of mapping the contents of a conveyor without moving all the data as the conveyor moves, but, instead, move the pointer that refers to the end of the conveyor. It's much more efficient and that's important when you're using a lower end PLC.
 

Similar Topics

Hey Folks. Using RSL5K on V21 I'm working on a little project here. Proving to be a bit of a challenge. I have a production line that is an...
Replies
17
Views
3,851
Scenario: Two different cutting machines drills material and put that on two different stock piles. The stock piles can have more than one cut...
Replies
2
Views
1,428
Product tracking based on time and position. I'll be using a 1769-L16ER-BB1B processor. There will also be an HMI involved, but it will be for...
Replies
24
Views
18,207
I'm a newbie to tracking concept. I have assigned a project to handle product tracking. Product should be delivered to destination without any...
Replies
10
Views
9,763
Guys I have a monoblock that tracks a bottle through the machine using shift registers and an encoder. We typically have a reject system on the...
Replies
14
Views
3,390
Back
Top Bottom