Cartesian vs Configuration -- limiting RZ

Being a Fanuc newb, I need a bit of help here.

I'm using a 6-axis Fanuc in a depalletizing fashion, to pick boxes from a pallet. I have a 3D vision system to get the coordinates of what I'm picking, which provides me a PR containg X,Y,Z, and Rz of the center of the top surface of the box (Rx and Ry are always 0). That all works fine.

The one fly in the ointment is that, because I'm picking up rectangularly-symmetrical boxes, there's no disambiguation for Rz -- if the box is rotated 45deg, the Rz value I receive could be 45, or -135 -- it's literally 50/50. Now, to protect the cables and hoses, I want to limit the Rz angles the robot uses to (for example) -90 to +90. Since my end effector is also rectangular and symmetrical, all I need to do is line up the long axis of my end effector with the long axis of the box -- I don't care if I pick it up 180deg "wrong".

From my previous experience with other robot brands, this seemed simple enough: use some IF statements to add 180 to Rz if Rz was less than -90, or subtract 180deg if RZ was greater than +90. Well, the math works, but the effect on the robot's motion is not what I expected. Despite limiting the Rz value of the PR this way, sometimes the robot simply decides to go "the long way around", even though the shortest route (in joint space) from its starting position would be the other alternative.

What I expected was that, given my unambiguous JPos starting point, the path planner would choose the shortest joint-space path to the Vision location in the PR, but that's not happening.
I'm guessing that I'm running into some sort of conflict between the Cartesian coordinates and the Configuration settings. But I don't know enough about how Fanuc path planning works to say for certain.

So, my questions:

is there some other cause for this behavior that I need to look into?

If I'm right about the Cartesian/Configuration conflict, what's the best way to handle it? Can I "remove" the Configuration values from a motion command, such that the path planner simply chooses the "least motion" path?

Can I do any of this in TP, or would it require KAREL?

Quote from Affaltar

Doesn't 3d vision have an option to limit that angle automatically? So you don't do calculations yourself? 2d vision from fanuc does.

I'm not using Fanuc vision, it's a 3rd-party system that can intelligently identify boxes in a stack.

Quote from HawkME

Are you using a linear or joint move?

Joint to reach the "Above Pick" position -- basicially, the PR from the vision system, plus a World Z offset. From the "Above Pick" to the "Pick" is a Linear.

Quote from linuxsand

Finally, if you confirmed the problem is related to configuration, you may need to write programs to manually/automatically set configuration filed of P[n] or PR[n].

Thanks, I'll look into that too.

Quote from Affaltar

There's an option MROT which should do what you want, it should be free, but needs to be activated, at least that's what Fanuc told me, in the mean time I solved the problem otherwise

Hm! I'll look into that, thanks.

So, it's been a couple busy weeks, but I'm finally back to this. I have something that appears to work for my purposes, as crude as it is.

First, Fanuc informed me I can't activate MROT on this robot without several other paid packages, so I tried one of Hawk's other suggestions: using a Joint-defined point to get my wrist set up the way I want it (with J6 in the middle of the range I want to allow), then using Linear motions to the Offset PR and the PR. I built a TP routine to keep the Rz value inside the limits I determined by jogging with the POSN window open, then built a brute-force test program that faked Rz values from -180 to +180 (my vision system won't send data outside those limits) and ran the motions.

So, the test run looked good, and I'm reasonably confident that, even if the math fails, I'll get stuck looping in the limit-check program rather than have the robot go wild and rip the dressing apart. But if anyone spots anything obviously wrong in my code, please let me know. (please don't laugh at my crude TP, I'm not good at it yet)

First, the limit-check program. Rs 570-575 are where I normally receive my XYZWPR data from the vision system. R574 and R573 (Rx and Ry) are always 0 for this system configuration. My production program will always subject the vision system data to this limit-check program before building PR200 for my "pick position". Everything before Line 33 is just XYZ checking.

   1:  ! Init return value ;
   2:  F[1:FuncReturn]=(OFF) ;
   3:   ;
   4:  !All 0s if no box found ;
   5:  R[48:3D Sum]=R[570:LR X Value      ]+R[571:LR Y Value      ]+R[572:LR Z Value      ]    ;
   6:  IF (R[48:3D Sum]=0 OR R[576:Boxes in Pick   ]=(-1)) THEN ;
   7:  MESSAGE[All 0s No Box Found] ;
   8:  JMP LBL[8000] ;
   9:  ENDIF ;
  10:   ;
  11:  !Avoid hitting pallet ;
  12:  IF (R[572:LR Z Value      ]<=R[104:Z- Pick Limit]) THEN ;
  13:  MESSAGE[Z Under Limit] ;
  14:  JMP LBL[8000] ;
  15:  ENDIF ;
  16:   ;
  17:  !Upper height limit ;
  18:  IF (R[572:LR Z Value      ]>R[105:Z+ Pick Limit]) THEN ;
  19:  MESSAGE[Z Over Limit] ;
  20:  JMP LBL[8000] ;
  21:  ENDIF ;
  22:   ;
  23:  !XY Limit Check ;
  24:  IF ((R[570:LR X Value      ]<R[100:X- Pick Limit]) OR (R[571:LR Y Value      ]<R[102:Y- Pick Limit]) OR (R[570:LR X Value      ]>R[101:X+ Pick Limit]) OR (R[571:LR Y Value      ]>R[103:Y+ Pick Limit])) THEN ;
  25:  MESSAGE[XY Limit Check] ;
  26:  JMP LBL[8000] ;
  27:  ENDIF ;
  28:  !RZ limit to protect EOAT ;
  29:  LBL[11:RZ Check] ;
  30:  IF ((R[575:LR R Value      ]>=R[110:RZ- Pick Limit]) AND (R[575:LR R Value      ]<=R[111:RZ+ Pick Limit])) THEN ;
  31:  JMP LBL[10] ;
  32:  ENDIF ;
  33:  IF (R[575:LR R Value      ]>R[111:RZ+ Pick Limit]) THEN ;
  34:  MESSAGE[RZ Too High] ;
  35:  R[575:LR R Value      ]=R[575:LR R Value      ]-180    ;
  36:  JMP LBL[11] ;
  37:  ENDIF ;
  38:  IF (R[575:LR R Value      ]<R[110:RZ- Pick Limit]) THEN ;
  39:  MESSAGE[RZ Too Low] ;
  40:  R[575:LR R Value      ]=R[575:LR R Value      ]+180    ;
  41:  JMP LBL[11] ;
  42:  ENDIF ;
  43:  LBL[10:RZ Okay] ;
  44:  !  Success ;
  45:  F[1:FuncReturn]=(ON) ;
  46:  JMP LBL[5000] ;
  47:  LBL[8000:Check Failed] ;
  48:  F[1:FuncReturn]=(OFF) ;
  49:  LBL[5000: Program End] ;

Next, my crude test program. PR 200 is my "pick position", processed from the values in Rs 570-575. Position P1 is my "wrist reset" point, which I always went back to for the start of each test, just as my production program will always move to a joint-defined point before performing the Linear moves to PR200.

   1:  UFRAME_NUM=9 ;
   2:  UTOOL_NUM=2 ;
   3:   ;
   4:  R[999]=(-180)    ;
   5:   ;
   6:  LBL[1] ;
   7:   ;
   8:J P[1] 100% FINE    ;
   9:  WAIT    .10(sec) ;
  10:   ;
  11:   ;
  12:  LBL[5] ;
  13:  F[1:FuncReturn]=(0) ;
  14:  R[575:LR R Value      ]=R[999]    ;
  15:  CALL PGLRCHECK    ;
  16:   ;
  17:  IF (F[1:FuncReturn]<>ON) THEN ;
  18:  JMP LBL[5] ;
  19:  ENDIF ;
  20:   ;
  21:  !Set Pickup Position PR ;
  22:  PR[200,1:LR Pick Point   ]=R[570:LR X Value      ]    ;
  23:  PR[200,2:LR Pick Point   ]=R[571:LR Y Value      ]    ;
  24:  PR[200,3:LR Pick Point   ]=R[572:LR Z Value      ]    ;
  25:  PR[200,6:LR Pick Point   ]=R[575:LR R Value      ]    ;
  26:   ;
  27:  ! Pick Position ;
  28:L PR[200:LR Pick Point   ] 100mm/sec FINE    ;
  29:   ;
  30:  R[999]=R[999]+10    ;
  31:   ;
  32:  JMP LBL[1] ;
  33:   ;