tracking a tote on a conveyor

Hi Guys,

I'm struggling to get my head round how to do this ?

I have an inclined belt conveyor with a PEC at the top and a PEC at the bottom.

The thinking is to track the totes up the belt conveyor and compare their expected position with their actual position.

If

a) a tote is expected but not at the PEC

or

b) a tote is at the PEC but not expected then I stop the conveyor and signal an alarm as it is probable it has slippped back down the conveyor or jammed somewhere.

Now I can create a DB, use the bottom PEC to insert the tote into the DB, and move this data through the DB with simple clock pulses. It's not a massively long conveyor and doesn't stop / start very often so this should be fine.

What I am struggling with is the logic at the top to compare what I think should be there with what is actually there - can anyone point me in the right direction please ?

For this example lets say that the PEC is effectively at tracking.pos[100].

I think I need to create a "window" with the PEC in the centre, so lets say tracking.pos[95] to tracking.pos[105] the tote is only approx 4 pulses long. Each pulse is therefore approx. 150mm travel.

I think there are two scenarios that I have to deal with :-

1. On the rising edge of the top PEC, look in the window to see if anything is there
but also
2. Look in the window and if something is there I should see the rising edge of the PEC

This is the bit that I am struggling to get my head around.........

Many thanks,

Mark

"Pulses"? You have an encoder then that is tracking the belt? You failed to specify that. If so, that sounds good to me on condition a). If not, then you will have to know and average belt speed, then time the trailing edge of the lower photo eye and create a window in time to look for the leading edge of the upper one.

By the way, this part bothers me a little.

b) a tote is at the PEC but not expected then I stop the conveyor and signal an alarm as it is probable it has slippped back down the conveyor or jammed somewhere.

Click to expand...

If you only have the two photo eyes, the tote would have to be all the way at the bottom, right? So ostensibly, that means the PEC you are referring to here is the LOWER one, not the upper one mentioned in the previous statement (you didn't say) and there is never more than one tote on the conveyor at a time. So ANY re-triggering of the lower one, or it not seeing a release of the trailing edge within another time / position window, would be cause for stopping the conveyor. But that will not detect a jam condition between the two, that would be picked up in condition a).

You'd create a window, many different ways in code to achieve this.

An example, the count from point A to Point B is expected to be 100, so you'd create an acceptable limit plus and minus depending of movement to pulse. Say for example we say 5 pulses is acceptable.

So you create an array 110 long, when your tracking bit reached 95, you start to look for an object at the PEC. If you detect it, great, job done "known object".

If the bit reaches 106 and no object has been detected, "lost object" and do whatever you need.

If an object is detected when no bit is between 95 and 105, then "unknown object", do whatever you need to do.

I would normally track on the leading edge only, so the bit enters the array on tn the object first being detected at PEC A.

You wold only need scenario 1. Set "bit in window" flag when it reaches 95, reset it when it reaches 105, therefore on PEC B detecting you'd just check the "bit in window" flag.


EDIT: you might have noticed I started answering before reading to the end

Instead of moving a bunch of data around, just set up an array for enough spots to cover a little more than the full length in your coarse pulses.

Suppose this is 100 elements, the length of the belt is 100 elements long.

Ideally, you would move a pointer through this array based on encoder feedback which covers everything. The pulses you describe should work okay though. Just increment your conveyor map pointer on each pulse and when it exceeds your software max, subtract the software max from it so that it wraps around.

This pointer will be the basis for the entry point. New items enter the belt at this array point. It runs up to the max number you want and then rolls over. The end of the belt calculated to match reality is going to be an offset from this moving pointer. It will need to be checked and corrected for wraparound based on the total data array length.

On the rising edge of the Exit Photocell, look for data at this offset position plus or minus probably one place. If no data is there, sound an alarm, stop the line, whatever you need to do. If data is there, move it where it needs to go elsewhere in your system and clear it from your map, since it has traveled past the end of it.

This is different way to skin the cat, but works great for tracking a variety of product on a really long belt without having to go shuffling a bunch of data around, just a pointer and all the input and output from the map is done with offsets and windows.

I don't think that there is an encoder. He is planning to use time and depend on the average travel speed of the totes.

...move this data through the DataBase with simple clock pulses.

Click to expand...

If the totes tend to slip on the belt, then the average-speed method will have problems.

Thanks for the replies !

PeterW - I think I will try the way you suggest.

jraef - no encoder just clock pulses, this has worked ok on previous jobs plus I am not looking for fine accurate positioning just an approximate position.

Lancie1 - probably shouldn't have said "slipped back down the belt" in reality there is very little movement, what i am trying to spot is the jam scenario really i guess, ie if a tote enters the conveyor at one end but doesn't come out of the other.

Thanks again,

Mark

You could calculate what you need from an encoder using known rate of travel and corrected with the pulses to simulate the position value in lieu of encoder. Interpolate between pulses more or less...

Basically, that is what you will be doing if you used a simple timer set up by which the exit must be blocked within a certain conveyor runtime after the entry eye is blocked, combined with a count up/dn timer. If you try to count them in and count them out, be sure to clear out the counters after a certain run time with the eyes clear, or provide the operator some means to zero it.

If you want simple jam detection, just do that...If you want product tracking/sorting then go for the more elaborate position tracking logic.