Posts by ClaudiuA

    Right, that's a better way!

    But it should look as follows:

    L P[1] 300 mm/s FINE SKIP, LBL[1]

    Was writing from memory and almost 100% sure I messed up the syntax somewhere. Thanks for the correction.

    I normally use this type of programming for "crash sensors" on a palletising gripper, to abort a motion if something unexpected comes up, without mulching the payload.

    Hello,


    Maybe I'm blind, but I can't seem to find this feature for the e-series.


    I remember on the CB 3.1 series of robots you could define as plane feature as varible and then recalculate it. I want to create a variable in which to pour one feature or another so I can use the same MOVE instruction relative to two different pallets.


    How can this be done? I'm thinking for something really backward like selecting BASE for the move instruction and actually calculate with PoseTrans my waypoint, but that seems like reverse engineering a solution rather than using a correct one.

    More robust utility of the USB port on the door {UD1:} would be nice. The port seems very sensitive to the capacity of the USB drive and even its brand name. Sandisk is good, but so are many other brands, and drives with a capacity of only 2 GB are getting hard to find.

    But... you don't need 2GB USB sticks anymore. That is a limitation only on early R30iA robots. I use my Kingston 8 Gb easily for those as well, it just takes a while for it to be read. Everything after R30iB works with whatever USB stick you want to use.

    Hello,


    Yes, the weld stay small until the ArcL\Off instruction. They are not using any weaving for their welds. Seam Data changes for some welds, but even those have a chance at the same error. It's never more than ONE weld per part that comes out like that - this is probably a coincidence.

    ABB Romania had previously separated all the cables to avoid exactly the issue of interference between power and signal. Doesn't seem to have helped any.

    Yes, there is a positioner and turntable involved.


    I have no idea the board. My dumbass self looked in the wrong cabinet for the boards...

    Hello all,


    Maybe someone can help me with an issue one of my clients has run into.


    They are using an old ABB robot, S4 controller for arc welding with an old Fronius Power Source.


    What's happening is that, randomly, one of the welds comes out much smaller than it should be, as if the amps drop suddenly, or the speed increases drastically.


    We've had ABB check the robot, and it got a green bill of health.

    We've had FRONIUS replace the welding equipment off a different robot. The error persisted.


    The only think I can think of is that the AO controlling the weld parameters may be malfunctioning. The issue is that whatever happens, doesn't happen regularly. It's random in the extreme and any weld can be bad.


    But, considering the age of the equipment, I have no idea where to even check for that.


    Does anyone have any suggestions or ideas as to what this may be? I've already contacted all my contacts that may have had, at one point, a robot as old as that, but I couldn't manage to find any relevant help.

    Hello all,


    We are trying to send a very large encoder value from the robot to the PLC via 2 16 Bit Group Outputs. I had originally suggested just cutting up the INT into two bite sized chunks with a division, but the automation guy doesn't like it.
    So... I'm a bit stumped by the math. I've mapped the original value to the first GO.

    And for the second GO I've divided the original value by 65.536....aaaand, I'm not entirely sure that's ok.


    Any suggestions from you gents?


    Edit:

    Nevermind. This WAS actually correct. Go figure. It's now his problem to figure out the sign.

    Hello all. Long time. Hope everyone's keeping safe and healthy.


    I'm having a bit of a brain twister with a UR 16e robot right now. To say that I'm THIS close to smashing the console is an understatement.


    So, I want to deliver some parts to an inclined conveyor. No big deal. But, since I have a lot of variety and I want to use space as efficiently as possible, I've created 2 poses that I use as bases for the gripper's orientation - there is a collision danger.
    I've created a unique plane feature for the conveyor.

    I did the calculations and the math and everything needed.


    Now, I want to use those WPs I've taught earlier to have their orientation based on a condition.


    VAR_WAYPOINT =: pose_trans(ORIGINAL_WAYPOINT, FEATURE_PLANE);

    VAR_WAYPOINT[1] = VAR_CALCULATED_Y;

    VAR_WAYPOINT[2] = VAR_CALCULATED_Z;


    MOVEL with respect to the feature.

    For any other robot I know this would deliver the gripper to the calculated position with the original orientation.


    For UR, however, NOOOOOOOOOO! The robot goes to the correct position...with a completely different orientation. Not only is it different, it's the complete opposite of the position I taught.


    Anyone struggled with soemthing similar? It's driving me up the wall.

    You cannot directly apply an offset to the positions, but you can send the position to a variable and add to that variable's coordinates the offset values.

    Change your tools to match. Makes life a lot easier and it's easier later to modify, remember, train others with/for. Otherwise, in a couple of years if you come back to this program you may be tempted to retroactively kick yourself.

    That's a corner weld, more or less, so you can go with a 45 degree angle of the wire between the surfaces. You need to push rather than pull the wire forward, so take a sharp angle, a few degrees, in the direction of the weld.
    Granted, I've never programmed a robot for Al welding, so take my general, not-actually-a-welder, advice with a grain of salt.

    I've never found this info in any manual, but luckily I have a much older mentor who passed this info on to me. I can't understand how Fanuc simply passes over this mandatory knowledge in their documentation.

    This is actually mentioned in the M410iB maintenance manual, in a very short paragraph pertaining to the replacement of the J1 reducer. That is basically why I asked about tips as that seemed to be a bit too little to go on. My paranoid self even had the robot end propped up as we unmounted the balancer from one of the client's spare units.

    At this moment, after changing a balancer and a J3 bearing, all that's left for me is to replace a J1 reducer for one of these robots and I can honestly say I know how to take one apart piece by piece.

    Hello all,


    Has any of you had the chance to swap out an M410iB/450 Balancer in the past? If so, would you happen to have some tips for this?


    I'm taking a 410 apart next week and, while the manual is very helpful, I could use some hands on information.


    Thank you.

    Stop ahead of the part, get the force, calculate a max, create a loop that works while force < max, continuous check, send ther obot forward in that loop.


    VAR_FORCE = Force()

    VAR_MAX_FORCE = VAR_FORCE * 1.5

    LOOP (FORCE () <= VAR_MAX_FORCE)

    MoveL

    WP_END_OF_MOVE
    WP_EDGE_POS = Get_Actual_TCP_Pose ()


    Something of the kind, I think,