I was tasked by a conveyor company out of Tampa, Fla., to investigate whether a parts-delivery system's throughput could be improved beyond the specified four totes per minute. Information about the system was sketchy at best, but with some home-brewed adapters to the I/O, I was able to determine what the position indicators, laser scanners, pickers (a small elevator), and RS232 command station were doing.
I created my own I/O using some devices provided by a US manufacturer and adapted them to an Everex step 32 computer system. I used QBasic's compiler basic to generate the bulk of the structure with some assembly to handle the laser scanners interrupts.
The delivery system consisted of a 432 tote (two foot x two foot plastic bucket) divided into six layers of 72 totes each and two small elevators, one on each end of a long loop of approximately 60 feet. The picker's job was to receive a tote extracted by a pneumatic piston or insert a tote via a set of belts aided by a paw that helped push the tote on to the chain-linked tray. Each pair of 72-tote layers was controlled by a separate embedded computer. Another computer handled the pickers, and another computer handled the RS232 communications between the delivery system and the host... five computers in all.
The problem was the brute force approach used to drive the now-disconnected I/O system. Each command from the host had to be parsed, and the pickers had to be directed to either go to a certain level and pick up a tote and deliver it to a conveyor level or vice versa. The first cut was to divide and conquer, so all of the extraction commands were divided from the insertion commands. That provided a reasonable outlook as to what the true nature of the requirements of movement were.
From there, I was able to create one single movement and used it twice regardless of the type of command received -- it was "move the picker, move the tote." Now, simply by providing a target for the picker, the routine knew where to move the picker. From that point, if the target was a conveyor, the software would move the picker to the conveyor level and generate the signals needed to drop the "K" stop to pick up the tote and center it on the picker. The second pass parsed from the host command was the delivery of the tote. In this particular example, the software would direct the picker to a storage layer and insert the tote.
This is, of course, very simplified, as there was a layer movement (using a shortest-route algorithm) to get the proper tote number to the correct end for the picker, locking the layer and either executing an extraction or insertion.
All in all, the system was now capable of delivering nine-plus totes per minute, instead of the manufacturer's four. The story doesn't end there, however! Because of the increased delivery speed, the host system had to pace the requests, because the totes would jam the exit conveyors, causing them to buckle and leap off the conveyor!
This entry was submitted by Rick MacLean and edited by Rob Spiegel.
Rick MacLean is a design consultant now working with a motion product company located in Longwood, Fla.
Tell us your experience in solving a knotty engineering problem. Send stories to Rob Spiegel for Sherlock Ohms.
Related posts:
Tweet This
4 
