Orientation Problem wrt to UF calculated Point

Did you check axis configuration of p variable?

Люба правильно сказала.

You have to store the reference position of robot with the proper configuration and shift it for every workpiece. Or have multiple reference positions with different robot configurations.

By the way it's a good question, how to set RCONF to a P variable explicitly with INFORM commands.

Following up on this, tracking a similar issue on a DX200 controller, MH50-II robot.

Running a palletizing operation with a pounce point above the pallet, locations are calculated based on counter integers provided by the PLC.

When working with KUKA, I used to manage this problem by just using a MOVL move instead of a MOVJ (KUKA disregards the "status" and "turn" i.e. robot orientation for MOVL moves). It doesn't appear that it works the same way with Motoman. On this edge case, the robot tries to reorient because the location at C0 has a T orientation <180 degrees. The placement point has a T orientation > 180 degrees.

Providing a snippet of code below. Am I able to accomplish this with the code I have, or so I need to use a SFTON / SFTOF command? For reference, the D[ ] variables are positions provided by the PLC, I[ ] variables are counters provided by the PLC. D[30] - D[32] are placeholder variables so I can move things into my position buffer P[30]. I know the orientations for X, Y, and Z are correct as I'm able to get 99% of my pallet stacked with this code. Just a weird edge case I'm trying to account for.

'*************ACTION*************
MOVJ C00000 VJ=10.00 PL=2
'~~~~~ APPROACH ~~~~~
'Run approach location math
GETS PX[30] $PX001
CNVRT PX030 PX030 UF#(3) TL#(1)
GETE D030 P030 (1)
GETE D031 P030 (2)
GETE D032 P030 (3)
' Set X Location
SET D[30]  EXPRESS D[52] + ( I[69] - 1 ) * D[55]
' Set Y Location
SET D[31]  EXPRESS D[53] + I[70] * D[56]
' Set Z Location with Offset
SET D[32]  EXPRESS D[54] + I[72] * 10 + I[71] * D[57] + 300000 + D[24] / 4
' Reassign to position variable
SETE P030 (1) D[30]
SETE P030 (2) D[31]
SETE P030 (3) D[32]
SETE P030 (4) -1800000
SETE P030 (5) 0
SETE P030 (6) 900000
'Move to approach location
MOVJ P[30] VJ=25.00
'~~~~~ PLACE Mag ~~~~~~
'Run Place location math
SET D[32]  EXPRESS D[54] + I[72] * 10 + I[71] * D[57] + D[24] / 4
SETE P030 (3) D[32]
'Move to place location
MOVL P030 V=250.0

After doing some more manual reading, turns out modifying S2C430 solves my problem.

Quote

S2C430: RELATIVE JOB OPERATION METHOD

This parameter specifies how to operate a relative job. A method to

convert a relative job into a standard job (pulse), and a conversion method

to calculate the aimed position (pulse position) when a relative job is

operated can be specified.

0 : Previous step with priority (B-axis moving distance minimized.)

1 : Form with priority

2 : Previous step with priority (R-axis moving distance minimized.)

Display More

Setting the parameter to 2 makes it work in my case. Woo.

I’ve seen this axis flip phenomenon happen a lot when you take a job that has been written as a standard and then converted to a relative job later on. Generally when you start from the beginning with a relative job, you don’t see this as much.

In addition to setting S2C430 to a 1, I would interlock test start through your job and modify enter on any trouble spots in the correct orientation as you encounter them. Try to avoid movements where the controller could make the decision to spin an axis one way vs the direction you anticipated. I would counter this with an intermediate point as needed to help the controller sort out the orientation throughout the job.

Good luck.