+- RoboDK Forum (//www.sinclairbody.com/forum)
+-- Forum: RoboDK (EN) (//www.sinclairbody.com/forum/Forum-RoboDK-EN)
+ - - -论坛:RoboDK错误(//www.sinclairbody.com/forum/Forum-RoboDK-bugs)
+--- Thread: Problem with *transl() when generating G-Code (/Thread-Problem-with-transl-when-generating-G-Code)
Problem with *transl() when generating G-Code-balazs.szabo58-02-16-2022
A weird problem occured in my program when using *transl() command.
(My station contains a Hanwha HCR-5)
Running the code below the TCP should move to an approach position then down along Z axis and lastly back to the approach position again.
Code:
dip_pose=target_dipapp.Pose()*transl(0,0,80)
robot.MoveL(target_dipapp)
robot.MoveL(dip_pose)
robot.MoveL(target_dipapp)
target_dipapp = RDK.Item('Targetname', ITEM_TYPE_TARGET),dip_poseis calculated with respect totarget_dipappin the first line of the code above.
This way the program works perfectly in RDK simulation but generating the G-Code gives a wrong result.
In the G-Code it moves to the approach position(target_dipapp) then to thedip_posethat has been calculated but the last move, which is moving back to the approach position is either completely missing or just results in random joint values.
Tried using other Posts like Fanuc or ABB but it did not help.
Tried using Joint movements instead of LIN but the result was the same.
Finally I tried creating thedip_posetarget in RDK as well and importing it just like the other one and it worked well.
This is how the G-Code looksWITH*transl(), usingJOINTmove on the last one:
#APPROACH
moveLinear('tcp', {"x": 395.683, "y": 582.618, "z": 93.757, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 30, 1000, {"precisely":false,"radius":2}, function() {});
#CALCULATED DIP_POSE
moveLinear('tcp', {"x": 395.683, "y": 582.618, "z": 13.757, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 30, 1000, {"precisely":false,"radius":2}, function() {});
#RANDOM JOINT VALUES
moveJoint([-32.901000, -133.135000, -98.837800, -38.027300, 90.000000, 147.099000], 20, 20, {"precisely":false,"radius":2}, function() {});
This is how the G-Code looksWITH*transl(), usingLINmove on the last one:
#APPROACH
moveLinear('tcp', {"x": 395.683, "y": 582.618, "z": 93.757, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 30, 1000, {"precisely":false,"radius":2}, function() {});
#CALCULATED DIP_POSE
moveLinear('tcp', {"x": 395.683, "y": 582.618, "z": 13.757, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 30, 1000, {"precisely":false,"radius":2}, function() {});
#MISSING THE LAST MOVE COMPLETELY
This is how the G-Code looksWITHOUT*transl(), importing the target from RoboDK (this is how it should look like in the other cases):
#APPROACH
moveLinear('tcp', {"x": 336.574, "y": 729.887, "z": 70.000, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 500.0, 1000, {"precisely":false,"radius":2}, function() {});
#IMPORTED DIP_POSE
moveLinear('tcp', {"x": 336.574, "y": 729.887, "z": -70.000, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 500.0, 1000, {"precisely":false,"radius":2}, function() {});
#APPROACH
moveLinear('tcp', {"x": 336.574, "y": 729.887, "z": 70.000, "rx": -180.000, "ry": -0.000, "rz": 90.000}, 500.0, 1000, {"precisely":false,"radius":2}, function() {});
RE: Problem with *transl() when generating G-Code-Jeremy-02-16-2022
Can you try something real quick?
"Tools"->"Options"->"Program"
"Output for linear movements" -> "Minimum step size (mm)" -> Set it to "-1"
Let me know if it works.
Jeremy
RE: Problem with *transl() when generating G-Code-balazs.szabo58-02-16-2022
(02-16-2022, 09:07 PM)Jeremy Wrote:Can you try something real quick?
"Tools"->"Options"->"Program"
"Output for linear movements" -> "Minimum step size (mm)" -> Set it to "-1"
Let me know if it works.
Jeremy
That worked! Thank you so much!
Sadly I still can't really understand what happened here.. Was the problem that it had to move to the same position? Or how could the minimum step size solve this issue?
RE: Problem with *transl() when generating G-Code-Jeremy-02-17-2022
It seems to be "kind" of a bug on our end where RDK thinks that you are moving at the same spot for some reason and it triggers the filter minimum step size protection.
I'll bring that up to our dev in the future.
Jeremy