RobotStudio event

back to home position


Dear users, I would like to now the best way how to solve the problem of moving robot to home position from the position that you cannot move directly (for example when there is colision or override in specific position of process).

My application is about grinding process and if robot stops while grinding, and you restart the controller, robot cannot move to home position, because of the colision with the tool.
< id="gwProxy" ="">< ="jsCall;" id="jsProxy" ="">

Comments

  • Moved to RobotWare forum
    Henrik Berlin
    ABB

  • Having a similar problem. The tallest bin in the system is only about a meter high and if the tool happens to be down in the bin the shortest path to home would collide into the side of the bin. A set retract distance causes the robot to fault out if it happens to already be high when sent home. The tool could be
    raised straight up to a min z of ~2 meters before going home - it would easily clear the highest bin and shouldn't be an issue on the shorter bins. Could I add a default straight min z movement to the MoveHomePos procedure? Wrong idea? Please help. Thanks!

    mcswc32010-05-25 22:49:55
  • Well, I don't know if this is your case, but try looking at PathRecMoveBwd, PathRecStart and PathRecStop.
    If this doesn't apply tou you, I think you'll need to develop an algorithim to find the best path to home.

    Leo

  • hi guys,
     

    You need to set-up the controller to do a "start at main" when restarting the system. a "start at main" sends the PP to the top of program. Let your program have the home routine at the top of program so that after ackn a collision and after motors are tunred back on the PP will go to the top to perform your home routine.

     

    You need to use a cross connection go into -configuration- signals- cross connection -and let "motors on" = "start_at_main"   (these are system signals) ...something like that.  

     
  • Ive had some success using a comparison of the robots current position to the trans x,y, or z value of a robtarget in order to determine which point or series of points the robot should travel to in order to get home safely.
     

    A simple example would lool like this:

    Current_Position:=CPos(Tool:=your_toolWobj:=your_workobject);

      IF current_Position.x > another_robtarget.trans.x THEN

        MoveJ intermediate_position,v500,z10,your_toolWobj:=your_workobject;

      ENDIF

    MoveL home,v500,z1,your_toolWobj:=your_workobject;

     

    In this case the comparison is made in regards to the X portion of another_robtaget's position data.
    Mel
  • Hi!

    I want to make a safe homing also.
    In my case I can make a linear move with offset from current position and then MoveAbsJ to my Pwait (for me it covers all positions in program :) .
    The problem is that in some positions that move instruction fails because of joint limits and robot stalls.
    In that situation I can make the MoveAbsJ to Pwait already.

    The code:

      PROC GoHome(speeddata mVelocity)
        VAR robtarget GoHomeS;

        ProcerrRecovery SyncLastMoveInst;
        GoHomeS := CRobT(Tool:=tool0 WObj:=wobj0);
        MoveL Offs(GoHomeS, -300, 0, 0), mVelocity, z10, tool0;
        MoveAbsJ PWaitNoEOffs,mVelocity,fine,ActiveToolWObj:=WObjPos;
     
        !!!!! Error Handler
        ERROR
          IF ERRNO = ERR_PATH_STOP THEN
            ClearPath;
            StartMove;
            MoveAbsJ PWaitNoEOffs,mVelocity,fine,ActiveToolWObj:=WObjPos;
          ENDIF
          RETURN;
      ENDPROC

    -----------

    I found this instruction on manual

        ProcerrRecovery SyncLastMoveInst;
    and let me "catch the error" of robot stoping.

    The problem is that the movl is not executed even if the final position has not reached the joint limit and  it jumps to error handler all the time. looks like all tries to moveL fails.

    Any sugestions?



      
     

  • Vitohxc, in some situation, wich I dont'd know them exactaly, the controller is able to determine an error condition before executing the movement. You said that there is no aparent joint limit in this movement, but the error is always detected. It seems to be a metter of axes configuration. A robtarget type is composed of 4 informations: trans, rot, robconf, extax. Trans is the XYZ coordinate of the point. Rot is a quaternion that determines the tool orientation. Robconf is a 4 component data that indicates to the controller how robot's joints are supposed to be moved in order to reach the desired position. In the "Rapid Instructions" datasheet (page 1053 in the 3HAC16581-1_REVH_EN document) you can find an explanation on how do these 4 numbers rule axes configurations.

     When moving great distances or through large joint movements, sometimes the actual robot axes configuration is not adequated. Changing this robconf can let you execute your desired move.

     Hope this helps
     Leo