Posts by ColoradoTaco

    Not sure if this counts as an easter egg, but another time was where the robot had a large metal spike as part of its tooling. I nick named the robot "Stab-a-tron".

    Was this robot working in sand-casting by chance? Most prominent use of robo-spikes I've ever seen was stabbing vent holes in sand casting molds.

    You have a working solution with round about 10 lines of code, now you want to have a solution where you can spare 3 or 4 lines :fine:. Have a drink and be happy with your solution.

    I see your point. I just felt like I was maybe missing something because it seems like it should be cleaner and easier to move in an error handler. I will go sip my coffee now.

    I had a customer at a foundry in Pennsylvania many years ago who employed just one person with the knowledge to program ABB robots, and he was bitter and strange. Went out there for a service call and found robtargets named all manner of inappropriate things. Milder examples I can remember were "titty" "buttcrack" and "cleavage". It got way worse than that. About a year later I had another service call out there and the guy was gone and all his programs had been completely wiped.

    Not really an "easter egg" per se. But I'm sure he thought it was hilarious.

    Works from a normal routine as well, but i still have to have that litany of instructions to prevent this error...

    41739: StorePath required


    Task: T_ROB1.

    Instruction MoveJ is executing in an error handler or a trap routine. Use StorePath before using a movement instruction on other level than base.

    Program ref: /SERVICE/IdleDance/MoveJ/188.


    A movement instruction executed without having the path stored.


    Execute StorePath before using movement instruction MoveJ. Read Programming type examples in the RAPID manual to see how to use movement instructions in TRAP routines and error handlers.


    Do I really need all this, just to move the robot in an error handler??

    Because it came up in a discussion yesterday while polishing up an in-house HMI for a new system... Have you ever added, found, or been haunted by an easter egg or other "undocumented feature" in an industrial robot? Would love to hear your funny stories here (if you are at liberty to share).

    Code: Interrupt Declarations
    CONNECT int_IDLE WITH tr_IdleCheck;
    ITimer IdleCheckTime,int_IDLE;

    Follow-up... Adding the same instructions (in red) as above, and replacing the RETRY with RETURN, my interrupt works the same way with no issues. Still just seems like it's more cluttered than it should be with all the SKIP/RESTO/STOP/CLEAR/STORE all just so I can make some other motions then come back to the WAIT instruction.

    I have a minor function in my robot where if it is idle for a set amount of time, it will do a little dance, log an error message with the total idle time, then continue waiting at the HOME position. Sounds silly, but we have reasons for it.

    I originally wrote it as a timed interrupt, but kept getting errors because I wasn't using StorePath first. (Robot is sitting at the home position with no planned motion, so I thought that wouldn't be necessary.) It works as intended in RobotStudio, but I am getting a separate error message for each of the move instructions in the "idle dance".

    I shifted over to an error handler in my MAIN routine, and played around until it ran with no errors. What I have is copied below, but based on examples in the Instructions, Functions, and Data Types manual, this seems excessive. Is there a cleaner way to do this??

    If I don't have all of the commands in RED, I get several errors, including Path Limitation (40649), Execution Error (40223), and Missing Error Handler (40357).

    The end result is working exactly how I want, it just seems very clunky. And I would like to get it back to an Interrupt to keep my MAIN module a little cleaner.

    If the values are different, then the markers line up differently at zero. Fine calibration is usually only used when a motor is replaced. Maybe one has been replaced. It seems to me that there are no programs yet which would be ruined by changing things now. You will need to make sure that gravity Beta parameter is set correctly for floor mount, rather than inverted.

    Yes!! Cannot stress this one enough!

    is it possible from flexpendant or just by robot studio using Rapid code?

    Yes. ABB RAPID code is the same in RobotStudio and on the Teach Pendant (unlike Fanuc where TP code and KAREL are completely different languages that don't intersect).

    I believe all standard instructions are available and have syntax help on the pendant. And at any rate, you can always select a line of code and select the "ABC" edit button to type in anything you want. You can create and edit data of all types (speeddata, bool, num, etc...) from the Program Data screen.

    Other things that come to mind are:

    1. Payload Activation -- When you activate the new payload on the robot during the gantry handoff could have a significant impact on system performance and component lifespan.

    (i.e., Gantry place>Gantry release>Set payload.... VERSUS.... gantry place>set payload>gantry release)

    2. Robot Standstill -- When the handshake occurs between robot and gantry, is the robot being held in place by the servos or the brakes?

    3. Do you have any force control or soft move options loaded? These could be used to mitigate forces felt by allowing the robot to cushion the transition from gantry to EOAT.

    Hey Sam!

    Just saw this, as I am looking into some error handling stuff too. I've been programming ABB robots for 10 years, and I still struggle with Traps, Interrupts, and Error Handlers.

    Did you ever get this working, and if so what was the solution?

    My initial thought is that you might need to book your error number so that the system will recognize it. If it's not a built in error for the base ware or a factory option, then you need to do the following...

    What I am currently doing is running a Power-On event routine that books all of my custom error numbers. I might be able to just run that routine at the top of MAIN, but event routine seemed like a more error-proof option.

    Okay, I have a ton of experience doing RAPID and configuration stuff in RobotStudio, but the modeling and simulation is still really new to me.

    I am trying to model up a tool for a new project. I have a pneumatic gripper and a pneumatic rotary actuator. I need to be able to index the rotary and have the tool/TCP follow, but I can't seem to get it right. Do should all the components be set up under a single tool? Or should I create a mechanism for the actuator, and a tool for the gripper, then attach them in my station?

    I am able to get the physical model of the gripper to move with the actuator, but when I try to get the TCP to move as well, I'm just not getting it.

    Enio do you have a bullseye you can run it through? Typically see that as standard practice after a torch or cup change. If you don't have a bullseye, I would definitely look into it!

    SkyeFire & Skooter are right on with their comments, as well.

    As in the title, looking for CAD model of a CRX-5ia. STEP file would be preferable, but I'll take what I can get. Anyone have one they're willing to share, or know where I can download one for free? My mediocre Google skills have not turned up anything (although I did find a 10iAL on GrabCAD).