(Another) Conveyor question

Hi

I have four conveyor setups here. I was wandering which you think would be the best/worst (if any). Your thoughts on PLC approach would also be appreciated.

This is the general operation:
- Scan the part
- Store the part into appropriate bin (based on the scanned part number)

PLC
- CompactLogix (ethernet)
- Ladder logic
- Structured Text (preferred)

PC Based Barcode scanner
- Communicating with plc through OPC Server (??) (ethernet)

No. 1

a) “New Part Sensor” detects the part

b) “Barcode Reader” scans and stores the part serial number

c) Based on serial number appropriate “Bin sensor” activates ejection mechanism

(this would involve counting bin sensor pulses)

No. 2

a) “New Part Sensor” detects the part

b) “Barcode Reader” scans and stores the part serial number

c) Based on combination of serial number, predefined encoder count and “Bin sensor”, ejection mechanism gets activated

(in this setup bin sensor would be somewhat redundant ... or used for verification)

No. 3

a) “New Part Sensor” detects the part

b) “Barcode Reader” scans and stores the part serial number

c) Based on combination of serial number and predefined encoder count, ejection mechanism gets activated

No. 4

a) “New Part Sensor” detects the part

b) “Barcode Reader” scans and stores the part serial number

c) Based on combination of serial number and timer, ejection mechanism gets activated

(because of the timer this one would probably be the worst solution)





Thank you

V

Redundancy is good

Vuli,

If the sorting is important, a redundant check is good. One fault won't cause a missort. If the encoder position of a part and the "bin sensor" position are not a close match the machine needs attention.

Thomas

If the parts are a maximum of ten inches in length and the bins are five feet apart, there's going to be a lot of wasted conveyor space with option #1. This may or not be acceptable. For just three lines, individual sensors may be OK. If sorting to two hundred bins, an encoder would be more attractive.

Regarding option #3, it's not absolutely necessary to have the new part sensor. Logic to detect the reception of a new barcode/destination from the PC could accomplish the same thing.

Idle curiousity question: Where does the lookup of the destination take place, in the PLC or the PC?

.02

Doug-P said:

Idle curiousity question: Where does the lookup of the destination take place, in the PLC or the PC?

Click to expand...

PC holds the database and controls the barcode
reading / destination.
Its an existing system. I have to use it.

Doug-P said:

Regarding option #3, it's not absolutely necessary to have the new part sensor. Logic to detect the reception of a new barcode/destination from the PC could accomplish the same thing.

Click to expand...

Just like PC database system, "New Part Sensor" is the part of the existing system. Another redundant sensor...and I dont mind redundancy.

V

I like option #2 best. If nothing else use the extra prox switches for jam detection/varification. I have yet to see a conveyor that did not jam at some point. The encoder will provide good placement as long as there is no jam/slippage. Its a little more work, with much better results.

I think that the 3 Station Sensors (possibly only 2), without any Encoder or Timers, is the way to go...

First, working backward...

In general, any part that makes it to Sensor #3 should only be a "Type-3"... simply activate the ejector. Actually, you could simply have the conveyor dump into Bin-3. That would eliminate the need for Station-3.

Any part that makes it to Sensor #2 might be a "Type-2" or a "Type-3". If it is a "Type-2" then activate the ejector; otherwise... "pass".

All parts will get to Sensor #1; "Type-1" and "Type-2" and "Type-3". If the current part is "Type-1" then activate the ejector. Otherwise... "pass".

Now, working forward...

Imagine that you are the Sensor/Ejector Assembly at Station-1.

You are operating from a list that identifies the parts in the order that they will be coming down the pipe. The part at the bottom of the list is the next part you will see.

Looking at the bottom of the list, you can see that the first one you will see will be a "Type-3" part. When you see the first part, since it is not a "Type-1", let it pass, and "pass" (copy) that "Type-#" from your list to your neighbor's list, then remove that item from your list.

Looking again at the list, you can see that the next one you will see is a "Type-2" part. When you see the next part, let it pass, and "pass" that item from your list to your neighbor's list, then remove that item from your list.

Looking again at the list, you can see that the next one you will see is a "Type-1" part. This time, when you see the next part, you eject it into Bin-1. You don't need to "pass" anything to your neighbor. Then remove that item from your list.

Now, imagine that you are now your "neighbor". You are now the Sensor/Ejector Assembly at Station-2. You are working off the list that was provided by Station-1. Station-1 passes "Type-2" and "Type-3" parts into this list.

The first item in this list (at the bottom) is a "Type-3". When you see the first part, it will be a "Type-3" part. Since it is not a "Type-2", you will let it pass. You don't have to "pass" any "Type-#" to anybody. You then remove that part from the list.

The second item, now on the bottom of the list, is a "Type-2" part. When you see the next part, you eject it into Bin-2. Remove the bottom item from your list.

Now, imagine that you are the further neighbor at Station-3. In this case, you have a very easy job - you don't have to think much, you simply have to keep your eye(s) open! Any part that you see you simply eject into Bin-3! (Optionally, since this is the only "Type" that should make it this far, the conveyor could be designed to simply dump into Bin-3... In that case, Station-3 is not required.)

So... does that give you any ideas?

By the way... this does require that there be a space of some kind between each of the parts!

This should have been a poll.

In my neck of the woods, I see #1 all the time. Program for asynchronous events with some limits for warnings.

#2 adds redundancy and you can back-check that the part actually gets to the sensor within the proper number of encoder counts and if doesn't, flag an error or warning. Better assurance that the part is going in the right bin.

#3 is certainly possible, as long as the part never shifts its physical relation to the conveyor belt. Definetly the low-cost method.

#4 (timer based) would not be my choice, no feedback from downstream.

Some of my customers would also want sensors between the conveyor and the bin verifying that the part actually fell but that usually feels like overkill.

One of the biggest projects I have done was something like this using something like #2 BUT to address some things mentioned and not mentioned.

My "parts" were all boxes, on one line they were all the same size but the line at shipping point the boxes were different sizes. At both lines we used the encoder to verify a constant speed along with time for jam detect purposes.

On the first line a spacing conveyor was used to provide a consistent gap, once leaving that point we knew where it needed to go, how long it would take to get there, and a sensor to detect arrival.

These conveyors were long so at some points we had sensors just to verify boxes were moving.

The thing that was mentioned and not mentioned is that some "parts" may get bad reads etc and the system does not know what to do with the parts, in this case scenario you could not dump it in BIN #3 unless that is what BIN #3 is for. We used what was called hospital lanes that sent the boxes to be checked and re-labeled....on other jobs there were reject bins.

My systems above had some large boxes that were diverted onto lanes that were just a little wider therefore our diverting had to be fairly precise. If that kind of precision is not needed and the conveyor speed is consistent then you may not need the encoder, time and sensor will work.

It depends on needs but #1 or #2 would be my choice, with #2 being the preferred choice.

The "fixing" of problems should occur where the problems occur... where the problem is small.

Building a system that tolerates, that is, "accepts", the failure of earlier portions of the process is, at least, counter-productive!

In the worst case, immediately, after "reading" the scan-code, the process should verify the "read" by reading the scan-code again. If both readings agree... pass it down the line. If not, re-route for a re-read.

And by the way, keep a count of the mis-matches!

SOLVE PROBLEMS WHERE THEY OCCUR - NOT LATER! (Later is always more expensive!)

Hey

Thank you all for your replays.

Let me clarify some of your questions and assumptions:

1. There are 2 extra bins I have omitted from the drawing to keep it as simple as possible. There is "Bin 0" (right before Bin 1) where all the parts with faulty/wrong/invalid scanned serial numbers are ejected. There is also "Bin 4" at the end of the conveyor for the other problems that may occur (i.e. clearing the conveyor of all the parts in case of some major fault without contaminating the "good" bins).

2. There is also a verification sensor at every Bin to verify that part was ejected (customer request)

4. There is ~100 bins in total.

5 . My choice was option #2 ... most of you seam to agree.

Thanks again

V

Hi



I have one additional question.

What would be the easiest/cheapest way to access PLC data(tags) from custom PC program (VC++,VB6,.NET)?


PLC: CompactLogix 5332 (L32E)
PC: Standard PC running VC++,VB6 or .NET based application.


These people seam to have a nice solution (?)
http://www.ingearopc.com


V

I have done a simlar thing in the past. I like option 3, but option 2 is okay too as long as the processor is prepared to effectively deal with false signals from the individual bin sensors. Personally, I chose to do it without relying on them. I used the photocells in my system for verification only, and the line would run properly without them, just add an alarm to the HMI.

In my application, I had to expect photoeyes to get dirty, break, etc. I also had to have a contingency for encoder failure even though it is very rare. I used several available inputs to detect this condition and switch to a conveyor position calculation based on command speed vs time instead of using the encoder position. It was accurate enough to trigger the product input to stop, sound an alarm and clear the conveyor without any mis-sorting.

Using the encoder for positiion tracking and a single input sensor will be enough to activate the correct bin diverters without any extra photoeyes. It will require accurate set up, but should be fairly bulletproof and allow little or no spacing between products. It will even tolerate speed changes, stopping and starting the conveyor (and running in reverse if the encoder hardware can deal with that)

Once that is working, adding extra checks and contingencies (bin sensors) won't hurt.

Good Luck
Paul