A little puzzle - need help solving compactlogix

[cwal61]

If your using a VFD on Sorter Belt then you could use Analog from VFD to Calculate Conveyor Speed and generate pulse instead of encoder. Assuming you have Analog Input. I use Lenght of FLL to maintain Divert and no need for timers. If Diverter Equals Lane # then Divert for Length of Lane # in File to Determine how long Divert Cycle last. You just have to make Lenght of Lane # shorter than your gap. You don't need the 12 PE's using this Method only Induct eye on Sorter Belt to Measure Distance to Diverts and then there is always the crude method of Prox detecting Shaft rotation provided speed is not to great for making Pulse. Not the Best but will work.
With some simple math and knowing your Pieces Per Minute requirment you can set VFD speed and figure out minimum gaps.
Good Luck with your Project and I will admit that the Man from Georgia's Idea is interesting. I also agree that his talent will not be on the sideline for to long.

 

[Johnster]

My old employer did this with a PC. I only messed with the hardware. A few thoughts from that side:

1) already covered =)

2) as above, even if you get good lookup results now, dont depend on that happening in the future (ethernet coms ? what happens when someone virtualizes the server that is running your SQL and now your response time goes to "tomorrow"

3) good Jam detection is important- you can 'popcorn' boxes real fast if something gets stuck (saw it many times...) We had "lane full" photoeyes on each discharge chute (as descrbied above) and that almost wasnt enough. A jam timer on every eye that you have (other than the lane full eye) is good.

4) Other people have said it - I'd recommend the encoder for sorter belt tracking - dont leave this to chance. Best to at least start out knowing "exactly" where everything is (it might help your improve your throughput later on, which customers like =)

5) Our HMI had a screen that was about 20 or 40 rows deep, and showed each box, its scan result, and SQL lookup result (it scrolled pretty quick at 600+ fpm) - makes it easy to point to the customer's SQL and say "see, the boxes are wonky because your database isnt giving me the result I need.

6) has the customer considered how easy it is to make changes to the sorting database ? This often affects how they put people on the floor (ie- their labor costs).

Sorry if you've seen all of this before, just some observations from things I know a little about.

-John

5)

 

[TurpoUrpo]

My old employer did this with a PC. I only messed with the hardware. A few thoughts from that side:

1) already covered =)

2) as above, even if you get good lookup results now, dont depend on that happening in the future (ethernet coms ? what happens when someone virtualizes the server that is running your SQL and now your response time goes to "tomorrow"

Thats virtualization done terribly wrong..

3) good Jam detection is important- you can 'popcorn' boxes real fast if something gets stuck (saw it many times...) We had "lane full" photoeyes on each discharge chute (as descrbied above) and that almost wasnt enough. A jam timer on every eye that you have (other than the lane full eye) is good.

Yeah and time that part needs to be detected to be more than just flicker..

4) Other people have said it - I'd recommend the encoder for sorter belt tracking - dont leave this to chance. Best to at least start out knowing "exactly" where everything is (it might help your improve your throughput later on, which customers like =)

What is the real benefit of tracking parts location like this? I see none vs coarse tracking like: "part is between scanner and first station", "part at first station", "part between first and second station" etc.

5) Our HMI had a screen that was about 20 or 40 rows deep, and showed each box, its scan result, and SQL lookup result (it scrolled pretty quick at 600+ fpm) - makes it easy to point to the customer's SQL and say "see, the boxes are wonky because your database isnt giving me the result I need.

6) has the customer considered how easy it is to make changes to the sorting database ? This often affects how they put people on the floor (ie- their labor costs).

Agree, but I think the cost is already pretty fixed, he said system is sold allready (or is OP not SI).

Sorry if you've seen all of this before, just some observations from things I know a little about.

-John

 

[Lancie1]

What is the real benefit of tracking parts location like this? I see none vs coarse tracking like: "part is between scanner and first station", "part at first station", "part between first and second station" etc.

One advantage is that the PLC can "know" where a part is on the conveyor based on belt travel speed (encoder) and known distances between points. If a part is expected (based on speed and distance) at a diverter pusher, but it doesn't show up at that time, then an alarm can be triggered. Without this tracking ability, PLC only knows that a part or package is "somewhere" between Point A and B, and that it should arrive at Point B "sometime". Thus alarms cannot tell as much information. The method used to predict precisely when a part will arrive at a point is the old well-known and much-used Bit Shift Register.

A Bit Shift Register (at its best implementation) simply sets up a phantom movement of bits in memory that exactly mimic the physical travel of a stream of parts or packages, based on encoder belt travel speed input. Once you have that, you can track almost any parameter that is associated with a particular part or package, such as size, color, type, routing destination. and so on. Typically, one shift register is used for each binary bit of data, so that there might be 4 or 5 shift registers tracking each part. If the part is being worked on, characteristics can be changed in a Shift Register as the part moves through work stations.

 

[OkiePC]

I have a three lane sorter that uses logic similar to what Peter Describes. I have a rolling Queue that represents the contents of the conveyor. The barcode, destination lane assigned, and product weight are all in their own files. I only have at the most 6 or seven boxes in transit between the barcode reader and the last diverter. My conveyor runs about 150 fpm and sorts about 28 boxes per minute. I did not bother with an encoder for such a slow sorter, I have more than two whole seconds to pop the pneumatic stop plates down in front of the box, and operate a kicker cylinder to send them down a lane.

I simply measured the belt speed with a hand tach, and did some math since my sort belt is on a contactor. I eyeballed the accel and decel times, and wrote logic to account for the rare occasion when the belt stops due to a jam up. I put the sorting (position tracking) logic in an STI routine to update those 6 or 7 ( I have room for up to twenty) boxes in transit. I did not shift any data, I just had a handful of pointers and flags. One for the highest indice value of a box in transit, and another for the lowest. I would loop through those in order to compare their position value (floating point) with the windows for kikcers, barcode readers, etc.

When a box was successfully diverted, it was no longer updated by simply setting it's position value to a range outside of all of the working windows. The stop cylinder and kicker are driven by position offsets from the barcode reader. Once adjusted, you never really have to mess with these tunable offsets for each station. This method only relies on accuratly estimated deltas of the position of six or seven values. There is a lot of indirect addressing, and there are two loops in my logic, but it cannot get out of sequence, never has to be "cleared" like the classic and more fallible cascading FIFOs driven by photoeyes. As long as I get a good barcode read (even the trigger for the barcode reader is based on a position offset window), and the very first photo eye works, the system is bulletproof.

Absolutely use an encoder if you can, that will save a bit of math for estimation and can handle stops, jogs, and reverse while retaining tracking position information accurately at much higher speeds than what I have going on.

I despise FIFO based shift register systems that can get out of sequence. This is probably because I use to stack green tires for a living and deal with all the problems that approach can cause for the labor force dealing with the product by hand when there is a sequence error.