Im having orientation problem, tried to change S2C430 parameter to 1 where the orientation of T axis should be constant but still it is changing. Please look at the pictures, the orientation from roby what I will (Ori_Good) and the orientation what my Calculated Point(Ori_Bad) do’s photos
Orientation Problem wrt to UF calculated Point
-
ravitejagali -
June 25, 2021 at 9:26 AM -
Thread is Unresolved
-
-
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.
Code
Display More'*************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.
QuoteS2C430: 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.)
Setting the parameter to 2 makes it work in my case. Woo.
-
After doing some more manual reading, turns out modifying S2C430 solves my problem.
Setting the parameter to 2 makes it work in my case. Woo.
Hallo paranoidandroid,
I tried with S2C430 parameter it didnt worked out, Instead of Single refrence point now Im using multiple refrence points.
Ty,
G:)
-
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.