loaddata and Motion Supervision

DallasE

We are using IRB660 palletisers to stack aluminium ingots. A gripper picks up 5 ingots and adds them to a stack. Due to the shape of the ingots, there is clearance for the gripper plates to open without contacting the previous layer.

Ideally, we need to gently place the layer of ingots down, not drop them.

We had IRB640's with an IRC5 controller and have no issues with this. 

When we updated it to an IRB660 we started getting motion supervision faults. 

It looks like the fault is happening when some of the ingot weight is lifted off the gripper due to the layer being placed on the stack. 

Whenever the gripper is closed, we tell it that it has a load in it (roughly 130kg's).

When the gripper is opened, we tell it the load is zero.

The problem is that some/all of the load can be taken off the gripper before it opens. Is there a way to define a transition period in the program execution where the load can be between 0 and the defined load?

Or should we just set motion supervision to the maximum tolerance when we move to place the layer and then back to a lower tolerance after the gripper has been opened? I have increased the "Manipulator Supervision Level" to 400 in the config file (Configuration>Motion>Motion Supervision) but the issue is still occurring and I don't want to cause gearbox/bearing wear in the long term.

Something else I find contradictory, on page 250 of document "3HAC050917-001 Revision: F",  it says it resets the load to zero when the program pointer is moved to main and the program is started – but in practice, we can start the robot from main with a load of ingots in it and it will move and dump the ingots without faulting on motion supervision, even though the load is about 130kg more than it is expecting... if the motion supervision level set to 400 is allowing this to happen, why is it still faulting when some load is removed off the gripper? 

Does motion supervision only monitor excessive force? If there is less force than predicted will it trip motion supervision?

lemster68

Motion supervision should not be triggered by a lesser load.  How are some parts removed?  Is hanging up or getting bumped by something?  Such an occurrence could be triggering motion supervision.  So you are "telling" the robot the load by using the Gripload instruction?  Are there fine points when you change the load values?  Reducing the acceleration can be helpful.

DallasE

Thanks for your reply Lee, and apologies for taking so long to respond!

The parts are all removed by quickly opening the gripper. It may be getting hung up if it travels down too far as some of the ingots will contact a plate inside the gripper.
We use the gripload instruction when the gripper is closed to "load" the ingots and when opened to "unload".
A cylinder measures the height with a SearchL instruction, but it can measure a low point which then could cause it to get stuck.

Trying to think of ways address this - not sure which would be the best solution. As an interim solution I have just set it to drop the layer of ingots a bit higher but would prefer not to.

1. If there is a motion supervision error when travelling to a target of a certain height, it goes to an error handler which will check how close it is to the programmed target, and if within a tolerance of 5-10mm, it will reverse until the excess force is removed, then  "jump" the move instruction causing the motion supervision fault and continue execution. The next instruction will be to open the gripper and move to a safe height above the stack and continue stacking.
Would this cause damage to the robot over time? I could set the motion supervision level fairly low (I cant change during program execution as we don't have the motion supervision package)

2. We only have problems when the ingots are slightly larger than usual - we would have this happen probably 4-6 times in a 24hour period. We measure them when they are cast - I could create an array in the PLC and when larger ingots reach the robot I could add an offset to the "place" height for a couple of layers.

3. I believe there is some setting of how rigid the robot is when it contacts something? I can't find much information on this though.

lemster68

Answer to number 3:  Yes there is, it is called Softservo.  It may solve your issues.  It allows the selected axes to become compliant, or springy.  Read up on it in the manual, Instructions, Functions and datatypes.

innebandy

Softservo is a good option in this case. However, the effect will be limited for 4-axis robots.

DallasE

Thanks, unfortunately the SoftMove manual says it is not available for 4 axis robots.

lemster68

Not Softmove, softservo.  Look up the instruction SoftAct.

DallasE

Ahhh, thanks! I'll have a play with that. 

DallasE

Is there a way to compare the current position using CPos or CRobT, to the target position?
I would like to have something in an error handler to say that if the current position is within say +/-2mm of its x,y target coordinates and +5mm of its z target coordinates that it can reset the collision error and use TRYNEXT to continue, which will allow it to drop its load.

I can't find an instruction to do this, would I need to separate each coordinate, and possibly the Quaternions and then compare them individually?

eg:

PosTarget:= (100,90,95);
PosCurrent:=CPos(\Tool:=tGripper \WObj:=wStack);
xCurrent:= PosCurrent.trans.x;
yCurrent:= PosCurrent.trans.y;
zCurrent:= PosCurrent.trans.z;

IF   (-2 <(PosCurrent.trans.x - PosTarget.trans.x) < 2) AND (-2 <(PosCurrent.trans.y - PosTarget.trans.y) AND ((PosCurrent.trans.y - PosTarget.trans.y) < 5)
     THEN 
             MoveL(Offs(PosCurrent,0,0,5)   !Raise 5mm
             StopMoveReset;
             TRYNEXT;
             MotorOn;
             StartMove;
     ELSE
            Stop;

DallasE

Found lots of problems with the above code, I'm sure there's more

  ERROR

    IF ERRNO=ERR_COLL_STOP THEN

        PosCurrent:=CPos(\Tool:=tGripper \WObj:=wStack);

        xCurrent:= PosCurrent.trans.x;

        yCurrent:= PosCurrent.trans.y;

        zCurrent:= PosCurrent.trans.z;

        IF ((-2 <(PosCurrent.trans.x - pPlace.trans.x) < 2) AND (-2 <(PosCurrent.trans.y - pPlace.trans.y) AND (PosCurrent.trans.y - pPlace.trans.y) < 5)) THEN 

             StopMoveReset;

             StartMove;

             MoveL Offs(PosCurrent,0,0,5),vIngots,fine,tGripper\WObj:=wStack;   !Raise 5mm

             TRYNEXT;

             RETURN;

            ELSE

            Set roRobotError;

            TPWrite "Gripper has collided with something";

            Stop;

            ExitCycle;

            RETURN;

    ENDIF 

graemepaulin

Sorry saw you already know how to get the variables out after I posted....
I would say that your approach is correct - once you debug it....

lemster68

Just use the Distance function.