Item Offset Does Nothing [PickMaster 5]

When adjusting Item Offset, the tool is not changing the drop off position. We are palletizing bags, and due to the inconsistencies of the bags, different layers need different item offsets. I have a feeling it has to do with some MinZ and MaxZ formulas shown below.

webwiz/3040/MoveInterMid-Custom.zip

IF (FromRobTgt.trans.z<ToRobTgt.trans.z) AND (MinZ<ToRobTgt.trans.z) THEN
MinZ:=ToRobTgt.trans.z;
ELSEIF (ToRobTgt.trans.z<FromRobTgt.trans.z) AND (MinZ<FromRobTgt.trans.z) THEN
MinZ:=FromRobTgt.trans.z;
ENDIF
IF MaxZLimit<MinZ THEN
MinZ:=MaxZLimit;
ENDIF

Hi John

The code you are referring to is only handling the intermediate path.
That has nothing to do with the drop off position.

BR
/Mats

What else could be keeping the item offset from not working? It works on some products, but others, it does not change anything at all. We have even tried large numbers such as 500mm and no change.

Is there any other way to change this?

Hi John,
the Item Offset for a layer in a pallet pattern operation set does not affect the pick/place location. It just modifies the approach height when the robot shall place items (general offset). There is currently no built-in runtime function to explicitly modify the pick/place location for individual layers. However, you can achieve a similar result by tuning the item heights. You can also modify the the place height for different layers by modifications in Rapid. I have no example code though to show you.

best regards,
Anders

Do you know where in the rapid this could be done? I am thinking about making a variable number that can come from the PLC so we can modify this from the touchscreen.

If we tune the item height, that tunes the pick also.

We are continuing to have problems and need someway to modify the drop position. Should we re-write the program all in rapid to fix this?

Hi John

An idea would be to write some custom code manipulating the target when fetched out to rapid.
After the execution of PmGetTgtAction, the rapid has full control of the robtarget (Act.RobTgt). You can then add an offset to the Z value, as a product of a tune value and the layer number.
Example:

WHILE PmGetTgtAction(WorkArea, Tgt.TargetHandle,Act) DO
PmCalcArmConf Act.RobTgt,Tgt.TargetTool,Tgt.TargetWobjcf6MaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;
Act.RobTgt.trans.z:=Act.RobTgt.trans.z+TuneZ*Tgt.LayerNumber;
IF FirstTgtInOp AND (NOT MultiOperation) THEN
MoveInterMid WorkArea,Tgt,Act,PmSafetyOffsetZMaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;
FirstTgtInOp:=FALSE;
ENDIF
PmDoAction WorkArea,Tgt,Act;
SetLastPos WorkArea,Tgt,Act;
ENDWHILE

Mats-

Thanks. I want to make this a variable that the PLC can send to the robot. I can let the PLC keep track of what layer we are on so I do not need to multiply by Tgt.LayerNumber. This will allow independent control of each layer.
Will this work for X & Y offset too of the drop position?(See below)

WHILE PmGetTgtAction(WorkArea, Tgt.TargetHandle,Act) DO
PmCalcArmConf Act.RobTgt,Tgt.TargetTool,Tgt.TargetWobjcf6MaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;
Act.RobTgt.trans.x:=Act.RobTgt.trans.x+VarXFromPLC;

Act.RobTgt.trans.y:=Act.RobTgt.trans.y+VarYFromPLC;

Act.RobTgt.trans.z:=Act.RobTgt.trans.z+VarZFromPLC;
IF FirstTgtInOp AND (NOT MultiOperation) THEN
MoveInterMid WorkArea,Tgt,Act,PmSafetyOffsetZMaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;
FirstTgtInOp:=FALSE;
ENDIF
PmDoAction WorkArea,Tgt,Act;
SetLastPos WorkArea,Tgt,Act;
ENDWHILE

Sure, it’s the freedom of rapid!

With the below statement, what coordinate system does this use? Is it the base or tool we would be adjusting?

Can we transfer variables in integer format via Ethernet fieldbus adapter?

WHILE PmGetTgtAction(WorkArea, Tgt.TargetHandle,Act) DO
PmCalcArmConf Act.RobTgt,Tgt.TargetTool,Tgt.TargetWobjcf6MaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;
Act.RobTgt.trans.x:=Act.RobTgt.trans.x+VarXFromPLC;

Act.RobTgt.trans.y:=Act.RobTgt.trans.y+VarYFromPLC;

Act.RobTgt.trans.z:=Act.RobTgt.trans.z+VarZFromPLC;

It’s the Wobj, or other pending on frame offsets in PickMaster.

If you declare I/O-groups in the EIP unit, it will probably work.

/M

Mats-

This offset worked, however it affects every work area (infeeder, slipsheet, outfeeder, etc). What is the easiest way to only have this work on outfeeder? I did something along the lines of:
sWAName := PmGetWaName (WorkArea);
nOutfeeder1 := StrMatch(sWAName, 1, “Outfeeder1_Conveyor”);

IF nOutfeed1Found = 1 THEN
IF Act.Type = PM_TARGET_POS THEN
Act.RobTgt.trans.z:=Act.RobTgt.trans.z+VAR_PLC_Z;
ENDIF
This was done in

Yes, your code isolates the tune to tha certain workarea.
Another way is to set an offset on the object frame of the workobject used at the workarea in question.

/M

Mats-

See below. The black text is what exists. The red is what I am looking at adding. Can you help confirm if this will work?

!***********************************************************

!

! Procedure Operate

!

! This routine executes one operation. It pops one

! operation and execute all its targets and actions.

! Before moving towards every first target in the

! operation, the robot will go to a intermediate position.

!

! Arguments:

! IN:

! pm_wadescr WorkArea

!

!***********************************************************

PROC Operate(VAR pm_wadescr WorkArea)

VAR pm_operationdata Op;

VAR pm_targetdata Tgt;

VAR pm_actiondata Act;

VAR bool FirstTgtInOp:=TRUE;

VAR string sWAName;

VAR num nPallet1Found;

VAR num nInfeeder1Found;

VAR num nOutfeeder1Found;

VAR num nOffsetXFromPLC;

VAR num nOffsetYFromPLC;

VAR num nOffsetZFromPLC;

! check which work area

sWAName := PmGetWaName (WorkArea);

! defines pallet as current work area

nPallet1Found := StrMatch(sWAName, 1, “Pallet1”);

! defines infeeder as current work area

nInfeeder1Found := StrMatch(sWAName, 1, “Infeeder1”);

PmGetOperation WorkArea, Op;

WHILE PmGetTarget(WorkAreaOpHandle:=Op.OpHandle,Tgt) DO

! closes up tool when work area is pallet

IF nPallet1Found = 1 THEN

SetGo pmGripper1_goActivators, 103;

ENDIF

! opens tool when approaching infeeder

!IF nInfeeder1Found = 1 THEN

! SetDO doPalletHooksOpen, 0;

! SetDO doPalletHooksClose, 1;

! SetGO SDelay := 1, pmGripper1_goActivators, 31;

!ENDIF

WHILE PmGetTgtAction(WorkArea, Tgt.TargetHandle,Act) DO

!!Sets the offset from a group input

nOffsetXFromPLC:=giOffsettXPLC_IO;

nOffsetYFromPLC:=giOffsettYPLC_IO;

nOffsetZFromPLC:=giOffsettZPLC_IO;

PmCalcArmConf Act.RobTgt,Tgt.TargetTool,Tgt.TargetWobjcf6MaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;

IF nOutfeeder1Found = 1 THEN

Act.RobTgt.trans.x:=Act.RobTgt.trans.x+nOffsetXFromPLC;

Act.RobTgt.trans.y:=Act.RobTgt.trans.y+nOffsetYFromPLC;

Act.RobTgt.trans.z:=Act.RobTgt.trans.z+nOffsetZFromPLC;

ENDIF

IF FirstTgtInOp AND (NOT MultiOperation) THEN

MoveInterMid WorkArea,Tgt,Act,PmSafetyOffsetZMaxAngle:=MaxToolAngleMinAngle:=MinToolAngle;

FirstTgtInOp:=FALSE;

ENDIF

PmDoAction WorkArea,Tgt,Act;

SetLastPos WorkArea,Tgt,Act;

ENDWHILE

ENDWHILE

MultiOperation:=FALSE;

ERROR

TEST ERRNO

CASE PM_ERR_PALLET_REDUCED:

RAISE;

CASE PM_ERR_PALLET_EMPTY:

RAISE;

ENDTEST

ENDPROC

ENDMODULE

I would prefer that you put the last red section above the PmCalcArmConf call, just to take the right position in consideration when the arm configuration is calculated.

Everything is great, but we cant pass negative numbers via this method. How do you suggest doing that if we need a negative 50 in one direction?

Ahh, a traditionally unsigned/signed problem.
Add another bit for the sign.