Posts by ColoradoTaco

    Okay, working offline for now because I don't have a Robot Studio license, and my CRB-1100 won't be delivered until roughly Halloween. I have the basic flow of everything down, modules organized, and most (non-IO) data declared.


    Started playing around with my homing routine this morning, and writing it from scratch just for practice, since it's been a couple years since I did this. Anyway... I came up with a different approach than I would normally use, and I want to know if this method would actually be useful in any scenario.


    So tell me... cool idea? Stupid idea? Would you use it, and if so, where?


    EDIT: Since I'm offline with no license, I may have some poor syntax and/or arguments. Please feel free to point them out haha!



    What led me to this was trying to clean up the IF-THEN portion to make it more legible. I thought if I could set up some boolean values for each condition, then I wouldn't have to have so much in each IF STATEMENT. I think it's clean and very readable, if not very efficient. And I don't think this is the right use case for it either. But I'm open to ideas or criticism for later reference!

    Yeah, I've got one robot serving two lines, each with it's own bagger, camera, and AsyCube.


    Operators are free to load parts into either hopper to start a batch, and the system will regularly check both lines to see if there are parts to be processed. But I wanted to have something more distinct happen if no parts are detected after a certain amount of time. That way, I can automatically turn off vacuum generators, bagger heat seal bars, etc.


    So typically after finishing a batch on one side, the system would check the other side for available work. If not found, then enters a WaitUntil statement looking for either side to be loaded. What I'm trying to do is EXIT that Wait condition if nothing is found after whatever arbitrary amount of time, and enter the quieter, less power hungry IDLE state.

    Awesome! This is very helpful. I'm doing sort of the opposite. Looking to send the robot to home and place it in an idle state if no parts are presented for X amount of time.


    But seeing how you utilized all of these really clarifies how to use the ITimer and ClkRead, so thanks!

    SkyeFire did you ever get this fully resolved? I am working out an idle timer function right now, and this thread shined a LOT of useful light on how I might be able to do it. Just wondering what your final solution was, if you can remember?

    which ever axis i select to jog robot in that axis direction using joy stick, motion supervision and joint collision errors comes with that axis name. which means its not related to some specific axis (mechanical or electrical), even if i try to move the flex track it stops movement after few mm move and generate motion supervision error.


    Damaged cable can still cause this, if the right conductor is shorted/broken. I would disconnect motor power and resolver cables at base of robot. Then check PIN-to-GND for everything on the Robot and Controller side. Double check anything that is grounded against the wiring diagram.


    If cables check out, my next step would be drive module swap.

    Lots of good details in this document. Unfortunately I don't have a copy available currently, and I can't find it on ABB Library. But someone on here may be able to pull it up, or ABB support should be willing to email it to you.


    Operating manual - Troubleshooting IRC5 3HAC020738-001


    On to your issue... Have you verified that all your motor connectors are securely connected (at the motors, as well as robot base, and inside the cabinet). Also check for damaged floor cables. Number one source of this issue in my experience has been a loose connector or damaged cable. Sometimes they're not very obvious either. There are a few model years where the Motors ON Indicator at the top of the robot is tied into the Brake Circuit in such a way that a damaged cable or shorted LED can affect the entire motor harness. Worth a check!


    If you can't find a wiring or connector issue, try swapping drive modules from another controller if you have one available.

    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.

    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.

    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.

    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.

    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.

    Still, it feels a bit unlogical to me to have a speedrefresh function that only enables speed reduction and no speed increase... Anyway


    Well I think the design intent with the ABB speed settings are that you write your move instructions at either an "ideal" speed, or a "fastest possible production" speed. The PERCENT adjustment is really just there to slow things down for testing purposes, or if you have a temporary equipment issue that requires running at a lower speed.


    A lot of people will program everything they possibly can at V3000 or VMax, then run at 50%, but it's not really good engineering practice, and ABB tech support would definitely scold you for it.


    If I may ask... why do you find it necessary to alter you program speed so frequently?

    Make sure you have a good backup. Then do a B-Start. If that doesn't fix it, I-Start then restore your backup.


    Often, these errors are just an internal code glitch that will resolve on their own with a forced reload of the software.


    If the same error persists, I would also presume hardware related. Drive module or motor/brake contactors perhaps.

Advertising from our partners