[gvhf39]

To Whom It May Concern,

I am currently researching the applicability of RoboDK to our Motoman MH180 robot for simulation purposes. After reading the RoboDK documentation provided and consulting tutorial videos, I have a few questions:

When importing a G-code program, the following G-code import error is shown: “Tool height compensation has no effect.” Could you provide an explanation and/or supplementary documentation for how RoboDK interpretsallG-code commands and reasons for this error?

What impact do thePath to Tool OffsetandSelect Algorithm, specifically最低工具取向变化andTool Orientation Follows Path, parameters have on importing and exporting G-code files? Does this affect the accuracy of the simulation?

从RoboDK的文档”,因为一个六轴机器人is used to follow a 3-axis or 5-axis CNC manufacturing program we have an additional degree of freedom to define. This degree of freedom is usually the rotation around the Z axis of the TCP." Are there ways in RoboDK to fully constrain this motion about the 6th axis so RoboDK does not manipulate the G-code commands and orientation(s)?

Could you provide any supplementary documentation for the Motoman post processors?

Thank you

[Jeremy]

Hi Gvhf

When importing a G-code program, the following G-code import error is shown: “Tool height compensation has no effect.” Could you provide an explanation and/or supplementary documentation for how RoboDK interprets all G-code commands and reasons for this error?

This error shouldn't affect the imported G-code.
All useful G-code commands are interpreted by RoboDK.

What impact do the Path to Tool Offset and Select Algorithm , specifically 最低工具取向变化 and Tool Orientation Follows Path , parameters have on importing and exporting G-code files? Does this affect the accuracy of the simulation?

Path to Tool offset will create an Offset between the path and the active tool following the orientation of the selected reference frame.
Minimum tool Orientation Change and Tool Orientation Follows Path has no effect on the imported points and their precision. It only affects the orientation of the tool with respect to the path.

从RoboDK的文档”,因为一个六轴机器人is used to follow a 3-axis or 5-axis CNC manufacturing program we have an additional degree of freedom to define. This degree of freedom is usually the rotation around the Z axis of the TCP." Are there ways in RoboDK to fully constrain this motion about the 6th axis so RoboDK does not manipulate the G-code commands and orientation(s)?

Simply bring the "Optimization parameters" to zero. You will, therefore, lock the rotation around the Z-axis.

Have a great day.
Jeremy

[gvhf39]

Thank you Jeremy! I have few more questions regarding thePreferred Orientationsection in theRobot Machining Projectwindow.

What affect does thePreferred Tool X Axishave on the simulation? What axes do these rotations occur about/with respect to? What order are these rotations done in? I noticed that the Motoman post processed job (.JBI) file is the same for 90,180 as 0,0 but intermediate values affect the simulation and post processed job file.

How are theFrame OffsetandTool Offsetvalues different from thePath to Tool Offsetvalues, if there is any difference?

How does RoboDK match the path and tool orientation by default? When thePath to Tool Offsetvalues are all set to zero, the TCP and reference frame, in which I import my NC program with respect to, do not match.

In theCAMtab in theOptionsmenu, what affect does theDefault Tool X Axis Orientationhave on the simulation? Does this specify how the X axis of the TCP is matched to the reference frame? When I changed the default from -X to +X, theRobot Machining Project Preferred Tool X Axischanged from 90,180 to 90,0.

[Jeremy]

Hi,

What affect does the Preferred Tool X Axis have on the simulation? What axes do these rotations occur about/with respect to?

We are talking about the rotation around Z of the tool and are with respect to the base reference frame of the robot.

How are the Frame Offset and Tool Offset values different from the Path to Tool Offset values, if there is any difference?

Frame offset is with respect to the reference frame of the path.
Tool offset is the same as Path to tool offset now, you don't really have to deal with the tool offset.

How does RoboDK match the path and tool orientation by default? When the Path to Tool Offset values are all set to zero, the TCP and reference frame, in which I import my NC program with respect to, do not match.

Yes, it should match. Can you join some print screens and/or your RoboDK station?

In the CAM tab in the Options menu, what affect does the Default Tool X Axis Orientation have on the simulation?

The default value will only define what are the default parameters of the Robot Machining Project. You can reach the same options in the "Preferred Orientation" section.

Jeremy

[gvhf39]

To whom it may concern,

I am having issues with RoboDK not properly importing my NC path (G-code). I have attached pictures of the tool path generated with NX and imported into RoboDK using aRobot Machining Project. I noticed that RoboDK adds in a path from the reference frame origin to the start point (which isNOTin the G-code) and that the tool orientation isn't consistent with NX (normal to the face). I'm aware of the offsets within aRobot Machining Project, but we would likeminimalmodifications to a project/station for consistency purposes. Is there a way I can suppress that path addition (I had removed the default approach and retract movements) and determine precisely how RoboDK interprets coordinate system rotations, offsets, and orientations?




Thank you!

[Jeremy]

Can you link the g-code you used?
What extension is the file?

The path in RoboDK should match the path in NX.
If it's not the case, something must be wrong. It can be the format of the NC file. If you used a Post-processor specifically created for a specific CNC, the NC file may have some specificity.
Do you have a post-processor that creates .APT files?

Jeremy

[gvhf39]

The file extension is a CNC/Tool Path (.cnc) (attached), which was generated using a modified 5-axis post-processor within NX. Commenting off "N16 G68.2 X0. Y0. Z0. I90. J33.69 K-90." seems to 'fix' the issue (only for a 3 axis path); however, the tool path was created within the YZ plane and was imported within the XY plane. Changing the plane selection (i.e. G17, etc.) does not affect this import.

Thank you!

[Jeremy]

Hi gvhf39,

.cnc is not a supported format.

As far as I know, .apt .tap .nc .nci .gcode are accepted.
有一些不能her formats that are acceptable but I can remember which one.

Jeremy

[gvhf39]

Hi Jeremy,

I have the option to save the tool path as a .cnc or .apt. I switched to .apt an still encountered the exact same problem. I commented off the same line, which contains the G68.2 rotate coordinate system command. This 'fixed' the tool orientation relative to the path, but did not fix the tool path relative to the reference frame. It seems like RoboDK is interpreting this rotate coordinate system command as a tool orientation command. Is there a reason behind why RoboDK is not properly interpreting this command? I have attached a picture of the initially imported path and the 'fixed' path.

Thank you.