How do you Track boxes on a conveyor?

Re: Conveyor

JohnW said:
Darren, another way is to use an indexed file to load the coloured boxes, so your colour eye loads the conveyor with integers for each colour. and counts as it does so

1=Red
2=Blue
4 =yellow

etc, as peviously stated.

Each push off station will count from the top of the indexed file so when it sees a box it compares the integer using indexed addressing and if it corresponds to the right colour it pushes the box off .

i.e index file is N7:100, length 16
The indexed address is N7:[100+C5:1.ACC]
each push off point starts counting when it sees the first box and the counter .ACC value is used as the index for a compare instruction if the colours match it pushes that one off and continues counting. Reset the counter at 16 (or whatever length the indexed file is). the File has to be long enough to count all the boxes before the last push off point without repeating.

The yellow push off will look at N7:[100+C5:2.ACC]
etc.

It doesn't matter how many boxes are between each station as long as they stay in order.

This is just off the top of my head as I eat my lunch so it may not work.

Thanks John, I thimk I'm seing the picture, Iam practicing with this program, have a test plc at home, I shall inter some logic, and force inputs and follow the data monitors to see how they load in. Such a simple operation but yet so difficult to program.
Darren
I'll let you know.
 
Last edited:
bernie_carlton said:
Darren - from all these replies you may be getting an idea that there are multiple ways to solve a problem (probably one for each control programmer). We each tend to get familiar with a subset of the PLC's commands and rely on them when envisioning the solution to a problem. This is EXPERIMENT time with a lot of imagination. Every situation will have its own little quirks. I heard of a local conveyor/pusher line located out of doors which, during bad weather, would miss push items or even push when nothing was there. It turned out that the photoeyes were VERY sensitive and were triggering off snowflakes. It's a grand adventure and you won't learn anything if you just blindly copy something given by someone else. Read through your PLC's instruction set, look at these examples then go for it.
This operation I am designing, is on a conveyor system, that hangs 20 feet in the air off the ceiling, so as far as a box being ininvertenly missplased, through the sequence, will unlikely happen. The only thing with instruction help, is there is never enough examples, need a book or something!
Darren
 
Re: Re: Conveyor

darrentpi said:
Such a simple operation but yet so difficult to program.
Uhhh, it only looks simple. From the outside. After it's done and working.
 
Ok! guys will this work!

This is my plan so bear with me;
The color eye will load a FIFL like this for example:
EG.
333445533 red being 3, blue being 4, and yellow being 5, using a channeled color eye located after the boxes exit the box maker.
when the boxes hit the first drop off eye I will use a EQL instruction that will compare and uload the value in the FIFL, if the value is the same, it will push the box off. If the value is different, then load that value into another FIFL instruction. Now those unwanted boxes will travel to the next location, and again use a EQL instruction, and repeat the same sequence. If the values are different then load them into another FIFL instruction, and continue the sequence tell there are no boxes left.
Does this make any sence.
Feed back would be great!
Darren
 
Darren, it sounds like you got the right idea. I usually don't post any logic until the original poster gives it a good faith effort. The way you propose sounds exactly like we do it. I just got done rewriting my original 2-yr old program because we sped up the line diverting the boxes. We use a .2 sec FIFO trigger and can divert any box off the main line in .4 secs. Now that you've got the right idea let me know how you make out.

You actually have an easier routine to write since you are dealing with inputs. I'm reading ASCII and I have to change Alpha values to numeric values before making anything else happen.

Good luck.
 
FIFL

Terry Woods said:
darrentpi...

What exactly is an FIFL and how does it work?

It stands for First In - First Lout.
It's a phenomenon known to bartenders everywhere - the guy who waits for you to open the bar is going to be obnoxious.

(Actually, his fingers are merely getting confused, switching between the AB FFL (FiFo Load) instruction, and the word FIFO.)

It could be one of his problems, though. He may have a FFL, but no FFU. ("The data checks in, but they can't check out")
 
Last edited:
Darrentpi...

You sorta kinda have the right idea... but only sorta.

Bit-Shift Registers work really well with a rigidly synchronized system. If the system is not rigidly synchronized, then you WILL have problems.

I can only work with the descriptions that you gave so... I have to assume that...

Box sizes might be different.
Spacing between boxes entering the identification area might, or might not, be consistent.
Box spacing down the conveyor might, or might not, be consistent.
There is nothing to indicate that there is absolute synchronization in your process.

I will also assume, however, that a reasonable space between boxes is guaranteed.

So...
You do NOT need to use 3 FIFO's. In fact, you don't even want to use any FIFO's.
You need to use 2 sets of "drop-through-registers" (envision a vertical "pipe" with colored ping-pong balls).

The following assumes that the pusher-order is Red, Yellow and Blue.

The first "pipe" covers the distance between the color detector and the first pusher.
The second "pipe" covers the distance between the first and second pushers.

The size of the first pipe ("drop through register") must be at least equal to the maximum number of boxes that might ever possibly exist between the color-detector and the first pusher. Adding a half-dozen extra slots won't hurt.

The size of the second pipe ("drop through register") must be at least equal to the maximum number of boxes that might ever possibly exist between the first pusher and the second pusher. Again, adding a half-dozen extra slots won't hurt.

As far as the third pusher... assuming the pusher-order is Red, Yellow and Blue... if a box makes it to the third pusher, it must be Blue!

COLOR DETECTOR
When the color-detector sees a box and then evaluates the color, the "Color-Detector Routine" drops a colored ping-pong ball into the first "pipe" ("drop-through-register #1"). The first pusher "reads" the "color-marker" and says... ah-ha! I know that the next box I see is going to be color such-n-such. At this point, the first pusher does nothing.

Your response-method at the first pusher is correct.

FIRST PUSHER (RED)
When the first pusher (Red) sees a box, it also looks to see the current "color-marker" in pipe #1.

If the current "color-marker" is Red, then the "Red-Pusher Routine" discards that "color-marker" and pushes the Red-Box.

If the current "color-marker" is NOT Red, then the "Red-Pusher Routine" grabs the "color-marker" and "drops it" into pipe #2 ("drop-through-register #2"). The "color-marker" drops to the first open position at, or near, the bottom of the second pipe.

In either case, all of the "color-markers" in pipe #1 fall down one position.

When the first "color-marker" falls into pipe #2, the second pusher "reads" the "color-marker" and says... ah-ha! I know that the next box I see is going to be color such-n-such. At this point, the second pusher does nothing.


SECOND PUSHER (YELLOW)
When the second pusher (Yellow) sees a box, it also looks to see the current "color-marker" in Pipe #2.

If the current "color-marker" is Yellow, then the "Yellow-Pusher Routine" discards the "color-marker" and pushes the Yellow-Box.
If the current "marker" is NOT Yellow, then the "Yellow-Pusher Routine" simply discards the "color-marker".

In either case, all of the "color-markers" in pipe #2 fall down one position.

THIRD PUSHER (BLUE)
Any box that shows up here is Blue... push it!

As long as the color-detector is working properly and there is a guaranteed space between boxes, AND no one is fooling around with the pusher eyes, this method is fool-proof!

Now... How in the hell does one create a "drop-through-register"???

Here's a clue... Indirect Addressing and Word Shift Registers

Chew on it for a while... I'll be back later (?) to describe it.

(550)
 
Terry Woods said:
Darrentpi...

You sorta kinda have the right idea... but only sorta.

Bit-Shift Registers work really well with a rigidly synchronized system. If the system is not rigidly synchronized, then you WILL have problems.

I can only work with the descriptions that you gave so... I have to assume that...

Box sizes might be different.
Spacing between boxes entering the identification area might, or might not, be consistent.
Box spacing down the conveyor might, or might not, be consistent.
There is nothing to indicate that there is absolute synchronization in your process.

I will also assume, however, that a reasonable space between boxes is guaranteed.

So...
You do NOT need to use 3 FIFO's. In fact, you don't even want to use any FIFO's.
You need to use 2 sets of "drop-through-registers" (envision a vertical "pipe" with colored ping-pong balls).

The following assumes that the pusher-order is Red, Yellow and Blue.

The first "pipe" covers the distance between the color detector and the first pusher.
The second "pipe" covers the distance between the first and second pushers.

The size of the first pipe ("drop through register") must be at least equal to the maximum number of boxes that might ever possibly exist between the color-detector and the first pusher. Adding a half-dozen extra slots won't hurt.

The size of the second pipe ("drop through register") must be at least equal to the maximum number of boxes that might ever possibly exist between the first pusher and the second pusher. Again, adding a half-dozen extra slots won't hurt.

As far as the third pusher... assuming the pusher-order is Red, Yellow and Blue... if a box makes it to the third pusher, it must be Blue!

COLOR DETECTOR
When the color-detector sees a box and then evaluates the color, the "Color-Detector Routine" drops a colored ping-pong ball into the first "pipe" ("drop-through-register #1"). The first pusher "reads" the "color-marker" and says... ah-ha! I know that the next box I see is going to be color such-n-such. At this point, the first pusher does nothing.

Your response-method at the first pusher is correct.

FIRST PUSHER (RED)
When the first pusher (Red) sees a box, it also looks to see the current "color-marker" in pipe #1.

If the current "color-marker" is Red, then the "Red-Pusher Routine" discards that "color-marker" and pushes the Red-Box.

If the current "color-marker" is NOT Red, then the "Red-Pusher Routine" grabs the "color-marker" and "drops it" into pipe #2 ("drop-through-register #2"). The "color-marker" drops to the first open position at, or near, the bottom of the second pipe.

In either case, all of the "color-markers" in pipe #1 fall down one position.

When the first "color-marker" falls into pipe #2, the second pusher "reads" the "color-marker" and says... ah-ha! I know that the next box I see is going to be color such-n-such. At this point, the second pusher does nothing.


SECOND PUSHER (YELLOW)
When the second pusher (Yellow) sees a box, it also looks to see the current "color-marker" in Pipe #2.

If the current "color-marker" is Yellow, then the "Yellow-Pusher Routine" discards the "color-marker" and pushes the Yellow-Box.
If the current "marker" is NOT Yellow, then the "Yellow-Pusher Routine" simply discards the "color-marker".

In either case, all of the "color-markers" in pipe #2 fall down one position.

THIRD PUSHER (BLUE)
Any box that shows up here is Blue... push it!

As long as the color-detector is working properly and there is a guaranteed space between boxes, AND no one is fooling around with the pusher eyes, this method is fool-proof!

Now... How in the hell does one create a "drop-through-register"???

Here's a clue... Indirect Addressing and Word Shift Registers

Chew on it for a while... I'll be back later (?) to describe it.
That is an interesting method, I think I need to re think this logic, some one eles mention ed your bit shift logic, but as far as sequencing, the boxes are all the same size, but they come and go when they please, just like a deck of cards what ever the operator loads into the box maker, that will be the colors exiting, and spacing will vary. I will let you know what I come up with!
Darren

(550)
 
Rube said:
I give up.
I am still chewing on what you are discribing, let me read your logic over the weekened, and take in what you are explaining, I will understand this eventually, remember I am a rookie!
I will only learn from you guys
Darren
 
darrentpi said:

Ok now I understand this logic, which is exactually how I explained it NO! If not let me know. I thought FIFL was the instruction to use, only because I am somewhat familliar with them. but If this logic your talking about is fool proof, then lets go with that. I am not sure how to apply this instruction set of drop through registers.
I will check back with you later will I research this.
Darren
 
darren,

Do us a favor... if you mean FIFO and not FIFL then please say FIFO.

Before posting... press that little button at the bottom-right, under the message window, that says... "Preview Reply". That will let you see what we are gonna see.

In a "true" indexing system with regulated bit-shifting (or word-shifting) there is no need for sensors at the down-line stations. The bit-location (or word-location) in the register serves as the sensor. Certainly sensors can be used to "verify" (as in "trust, but verify") the existence of the item, but, if this is a "true" indexer, then the down-line sensors would be redundant.

As long as there is a guaranteed space between individual sensed items (edges), the method I am presenting will accomodate any kind of conveying.

For example, it can accomodate bottles that are side-by-side if the EYE is positioned to read the neck of the bottle.

It can accomodate boxes that are to be sorted by height. This would require a set of eyes at the particular station.

In this case, if all boxes are the same size, then there must be a guaranteed gap between boxes... or maybe not...

...if the speed of the items down the conveyor is rigidly controlled then there is a chance that "Eye ON Time" can be measured and then an item-boundary can be calculated.

For example, if the speed of the items is such that an eye would be ON for 5.000 seconds while a box passes then, if the current time is greater than or equal to 5.001 AND less than 10.000... then this must be the next box. Likewise, if the current time is greater than or equal to 10.001 AND less than 15.000... then this must be the following box. Whether or not this is acceptable depends on scan time and the required reaction time.

And for Pete's sake, if you use that method, DO NOT reset the timer after 5.000 seconds. Let the timer run as long as possible and hope for a break in the Eye-ON-Time. Only then should the timer be reset.

If you were to reset the timer after every calculated item-boudary you will end up with a huge "creeping error" effect.

Anyway... back to the problem at hand...

As far as I know, there is no such thing as a "drop-through" function in any PLC. I've always built my own using a word-shift register and Indirect Addressing.

For those that might be choking on my verbal description of the concept, here is a visual description.


Drop_reg_1
410bc1712b196f28.gif


This method doesn't require any kind of "timing" or "synchronization" in the mechanical system. It does, however, require that the loading and unloading of the "pipe" take into account that the pusher routine might be trying to discard or pass-thru a color-marker at the same time that the color detector is trying to add a color marker. Since this is a worst-case possibility, the method should assume that to be the default condition.

If this condition occurs, then it is simply a matter of "holding" the color-marker from the detector until the pusher routine removes the current color-marker at the bottom of the particular pipe (either by discard or pass-thru), then allowing all of the color-markers in the pipe to drop one position, and then dropping the color-marker from the color detector into the lowest open position in the pipe.

All of that action occurs in one scan.

If you look at the green arrow from the color detector and the green arrow from the Red Pusher Eye, and their positions relative to the leading edge of their respective boxes, you will see that, in this case, the color detector saw the Blue box before the Red Pusher Eye saw its' box. The color detector "dropped" a Blue marker before the Red Eye saw the box. In this case, the Blue marker was already loaded into the Lowest Open Position before the Red Eye saw the box. So, the White circle should actually be Blue.


Drop_reg_2
410bc1cd09eed7fb.gif


In this figure, Drop_reg_2, color markers are dropped into pipe #2 in the same manner as in pipe #1. In this case, pipe #2 receives color-markers from the Red-Pusher Routine. Notice that there are only Yellow and Blue markers in pipe #2.

This pipe is also subject to the same worst-case situation that exists in pipe #1. So, it too assumes that to be the default condition.

When the EYE at the Yellow pusher sees a box (Eye OFF to ON), it will check the current color-marker and then discard it. If the current color-marker WAS Yellow then the pusher will push the Yellow Box. If the current color marker WAS NOT Yellow, then the pusher does nothing.

The Yellow-Pusher Routine will discard ALL markers

When the EYE at the Blue pusher sees ANY box, it will push. Only Blue boxes should make it this far.

I'll describe the "management method" in my next post.
 
Last edited:
Hi Terry thanks for the logic display attachment, I appreciate the effort you are going through to help me. I am understanding your logic, but because you are using a different instruction technique, then FIFO, not FIFL, You may have to familliarize me with what funcution blocks I will need to put together this sequence.
Before we get to carried away I will give you all the variables and conditions associated with this box line I'm building.

The box machine will produce a box every second roughly.
There could be an insident where a box could become hung up on the conveyor and all following boxes will pile up. In that case an operator will release the hung up box and now all boxes will travel back to back.
I will be installing a brake before every intersection for definite seperation, and to hold while pushing.
That is preety much it!
From what I learned in the plc courses, I will need some sort of de bouncing logic for the color eye as this eye is very sensitive. It may see the box twice, and possibly at to different colors, but lets not worry about that now.
This box line must be free of bugs in its logic, as the line is being installed 15 feet overhead, way to high to reach by ladder if there was a jam up! I am designing and installing this profect myself, so this little baby is all mine!
Darren
Darren
 
though i am new to the plc world,,i do believe that you dont have to use whole words to identify which color is each box,,you can just use 3 bits to identify up to 8 colors and save overhead ,,,(two bits for your 3 colors),,,


example

Code:
ABCX XXXX

where as ABC are the bits that identify the color,,the rest can be used for other uses,,like a counter? or a tracker?,,with a bit of coding,,would be useful on the pusher end to determine which box is which,,i dont know if plc's work the same as eeproms,,but a bit of bit checking,,XORing ANDing,,etc,,might help for the masking,,


Fred Raud
 

Similar Topics

Hi, I have some numeric input fields and I would like to track whenever a change is made to them. For example if an user changes temperature...
Replies
1
Views
862
Any help appreciated, Proposed question: I need to track parts to count the rejects in a rotating machine but having no luck tracking proper...
Replies
7
Views
2,342
Right now my system is using RFID tags on the load bars. Im trying to figure out how to implement error correction in this system. In the past...
Replies
2
Views
1,106
So at my plant our shift schedule is 12 hour shifts 7 days a week. There is 4 shifts A,B,C,D. A and C are the day shifts. 6am to 6pm B and D are...
Replies
10
Views
3,969
Hi all, i am having trouble finding out how i could track an event like start command or stop command. is there anyway to do it in FTView ME 6.1...
Replies
2
Views
1,545
Back
Top Bottom