Production Queue / Machine Priority

    I am trying to determine the most efficient way to handle a system with one robot picking & placing to distinctly separate production lines.

    1. Plan is to use an ABB CRB 1100, but that isn't critical to the discussion.
    2. Both lines are using vision to pick randomly placed parts in a tray.
    3. Might run both lines at once, or just one at a time. Need to accommodate all scenarios.
    4. Production sequence for each side is: IMAGE > Get QTY and POS for all pickable parts > Pick & Place into autobagger > Repeat for all parts > Feed more parts > Back to start

    EASY OPTION -- Operator loads and starts batch on SIDE A. Robot runs side A to batch completion, then checks if SIDE B ready.

    PROS - Stupid simple programming & physical wiring

    CONS - Probably the least efficient option. Lots of idle machine time.

    MID TIER OPTION - If part available on SIDE A, pick & place SIDE A. Then if part available on SIDE B, pick & place SIDE B.

    PROS - Also incredibly simple program. Ensures consistent throughput on both sides without leaving one side idle.

    CONS - ROBOT DANCE PARTY!!! Way too much constant motion and processing.

    FANCY OPTION - Image SIDE A & SIDE B. Pick & Place available SIDE A parts, then move to B. Feed and IMAGE side A while doing part handling on SIDE B

    PROS - Probably the most efficient use of all machines. Takes advantage of feeding and processing time.

    CONS - Definitely trickier code, though probably not terrible. Might be a challenge to handle multiple vision position arrays/registers and set up necessary background tasks.

    I'm fairly set on using the third option, but where I'm struggling is the coordination and timing of things. Operators may load and start a batch on either side at any time. Batch size may be input as a specific quantity of parts, or as a "run until empty" batch. Must minimize risk of mixing batches (probably set up world zones and use I/O to activate/deactivate them.

    • If batches are ready in SIDE A and SIDE B when I start the main program, does it matter where I start?
    • If I'm processing on SIDE A and load a batch in SIDE B, should the system immediately start imaging/feeding/picking SIDE B at the next opportunity?

    I know that I CAN make this system work just fine. But I'm happy for any input on making things clean and efficient!


    General idea of cell layout I'm planning.

    Ideally you would know what the demand is from the downstream production lines. If line A is running twice as fast as B then you may need to pick to meet the demand.

    If you have the capability to have the downstream demand as inputs then you can use that as part of your calculation along with if parts available.

    If not then you might need to set a pick qty for each line., such as always do 5 in a row for A then 3 for B. If nothing is available then just check back and forth both A and B until one is ready.

    It would depend on how you determine one line has been fed too much vs the other not enough. For example, you might default to running a full batch on A, but with a check every pick/drop cycle to see if B is starved, and switch over.

    Are you using fixed cameras, or a robot-carried camera? Fixed cameras would let you do a background check of B while running A (or vice versa).

    In a very general sense, the longer you go without running one line, you want to give that line higher priority. But you don't want to re-check the "starved" line too often (if you're using a robot-mounted camera). It'll be a bit of a balancing act.

    Maybe counters that keeps track of how many cycles you run on one line without running any on the other. The further the counters are apart, the more often you check the starved line. And maybe you stick to the starved line until the counters are close to even.

    HawkME unfortunately we run a high volume/high mix, and batches from any of hundreds of product lines (last I checked, around 16,000 different SKUs) might end up at these machines. Batch quantity can be anywhere from 20 to 240. Demand is pretty stable in the long run but day to day production can change drastically, hence the need for some flexibility in prioritizing.

    I think the end goal will be to minimize the amount of idle time on a feeder/bagger with parts waiting.

    We currently have operators manually picking one part at a time and dropping it into the bagger. Times 8 baggers. Hoping to set up 4 robots serving two baggers each, and require just one operator for the whole line.

    I like the idea of a fixed qty per side before switching. But there may not always be that number of parts available since we run strictly segregated batches, not a constant inflow of parts.

    Quote from Lemster68

    Is this going to be programmed in the robot only or is there to be a PLC for these cells?

    Could go either way. Early in the project right now. First robot is ordered and we're about 8 weeks from delivery.

    I think I would prefer to have the robot handle it, because our bean counters really like to hoard those beans. Save a little money on a PLC if it's not a MUST HAVE.

    Quote from HawkME

    Set a max consecutive picks variable.

    It will try to pick that many in a row from 1 feed. If it reaches that count or none available it switches to the other feed.

    That's where I'm running into the "efficiency" issue.

    We have some parts that are absolutely tiny (3mm x 3mm) and some that are 8mm x 120mm. The tiny parts, we can easily get 50+ pickable parts on the tray at one time. Larger parts we typically try to have less than 10 on the tray at any given time.

    So if I set a fixed "max picks" value, I could be leaving dozens of pickable parts sitting on one tray while I go pick a small number of parts on the other side.

    I'm leaning towards "IMAGE > PICK ALL FOUND > SWITCH SIDES" as my strategy. But still fumbling with clean logic for checking conditions of when to get a new image, when to stop checking for parts, etc.

    Well, does the robot get any information that tells it what parts it's currently running (tiny, medium, big, etc)? I would seem that the vision system would need to know, at least. You could use that to adjust the "max consecutive picks" limit.

    Regarding PLC or not... was the robot ordered with the Multitasking option? This would allow you to create a "background" program in the robot that could act as an ersatz PLC

    Yes to multitasking.

    For the vision... we are actually working towards a single recipe that can identify and locate large swaths of our part families, so we only have two or three recipes in total, that cover all the thousands of SKUs. Plan is to just run each cell as (like you said) Small, Medium, or Large. We could easily load the other jobs if we need to switch it up. But day to day operation is planned to be all under a single recipe. So yeah, having different pick limits could work for that.

Advertising from our partners