The solution for jerky movement for Fusion users?

[Roby]

Hi,

I've been living with jerky movement for years when using Parallel 3D tool paths such as carving guitar necks (ie. radiusing fretboards and the curved back of guitar necks).

In trying to improve the situation today, I discovered that the UCCNC post processor for Fusion only allows G2/G3 arcs on the XY plane (the curves I cut are XZ or YZ)! So instead of smooth arcs it was generating hundreds if not thousands of short linear moves!

To remove this limitation I made the following change to the post processor:

//allowedCircularPlanes = 1 << PLANE_XY; // allow only XY circular motion
allowedCircularPlanes = (1 << PLANE_XY) | (1 << PLANE_ZX) | (1 << PLANE_YZ);

The GCode being produced for a fretboard radiusing operation is now just beautiful. Many many linear moves replaced by a handful of G2 or G3 moves.

I am so pleased with this discovery that I am sharing it with the community immediately. I'll run the code on my machine in a few hours to ensure everything works fine, but I can't see why this wouldn't fix the issues with jerky movement that I've been experiencing (again, for years!).

I hope this helps the community!

Regards,
Roby

[crjohnson]

Sounds like an interesting discovery!

I do currently do your type of machining but would it be possible to put up a video of the before and after movements? Would be very interesting to see!
Cheers

[Roby]

After testing, I now realise that UCCNC doesn't support G2/G3 moves in the X/Z or Y/Z plane, only X/Y, hence the limitation of the UCCNC Post is a real software limitation.

Running the gcode produced by the modified Post results in nonsensical movements.

It would be greatto hear from the developers if I understand this limitation correctly and if there are any plans on supporting this feature. I believe it would allow me to run faster and cleaner code.

Apologies for the red herring everyone.

[dezsoe]

After testing, I now realise that UCCNC doesn't support G2/G3 moves in the X/Z or Y/Z plane, only X/Y

Of course, UCCNC supports G2/G3 on all three planes. Did you switch to G18 or G19?
Here is a test code:

Code: Select all

F400

G0 X0 Y0 Z10
G0 Z0

(XY)
G17
G02 Z-1 I5 J0

(XZ)
G18
G02 Y1 I0 K5

(YZ)
G19
G02 X1 J0 K5

G17

G00 Z10

M30


[Roby]

Sorry for my hasty email and thank you for the quick response.

It seems that the GCode generated by the modified Post doesn't contain any G18 (or G17 or G19) commands.

I'll keep working on this and report back. Feels like this could potentially be a big win.

[dezsoe]

You need to select the plane, because 2 of the axes makes the arc, the third moves while the arc is done, as you can see on the sample. The program needs to know somehow which 2 axes describe the arc.

[Roby]

Thank you for the explanation. Here is a snippet of the generated GCode.

Towards the bottom is probably the relevant part: G1 then G3 then G1 then G2 and so on (but no G17 G18 or G19). It is cutting a series of arcs in the XZ plane moving down the Y axis.

I'm reviewing the Post javascript code now to try and work out why there is no G17, G18 or G19 as that seems to be the intention of the code that I've identified.

Any thoughts would be appreciated.

Code: Select all

(C4 Radius Fretboard)
(T85 D=8. CR=4. - ZMIN=24.032 - ball end mill)
G90
(When using Fusion for Personal Use, the feedrate of rapid)
(moves is reduced to match the feedrate of cutting moves,)
(which can increase machining time. Unrestricted rapid moves)
(are available with a Fusion Subscription.)

(Parallel -  Radius Fretboard 0.7 stepover, 0.2 STL)
M2
(MANUAL TOOL CHANGE TO T85)
S18000 M3
G64
G90 G94
G54
G43 H1
G0 X-21.617 Y515.227
Z40.4
G1 Z26.651 F2880
Z25.518 F960
G2 X-21.36 Z24.93 I0.8 K0. F2880
X-20.754 Z24.72 I0.543 K0.587
G3 X-10.732 Z25.365 I20.992 K-248.137
G2 X-10.351 Z25.783 I-0.018 K0.4
X-10.377 Z25.909 I-0.4 K-0.018
G3 X-10.149 Z26.427 I0.373 K0.145
X-9.983 Z26.453 I0.145 K-0.373
G1 X10.726 Z25.365
X15.004 Z25.14
X18.121 Z24.928
X20.755 Z24.72
X20.765 Y514.527 Z24.719
G2 X-20.768 I-20.766 K-244.863
G1 X-20.779 Y513.827 Z24.718
G3 X20.777 I20.777 K-244.733
G1 X20.787 Y513.127 Z24.717
G2 X-20.788 I-20.788 K-244.858
G1 X-20.801 Y512.427 Z24.716
G3 X20.8 I20.799 K-244.738


[Roby]

I've played around with a number of the Fusion Posts (notably Masso, HAAS and LinuxCNC) and they all produce GCode like the one I pasted above - there are no G17, G18 or G19 commands in any of the outputs.

I'm at a bit of a loss - it seems that Fusion doesn't add a G18 for a XZ arc per the sample above. Perhaps this is because the plane can be inferred from the parameters given to the G2 command which are I and K which are required for an XZ plane move per the UCCNC manual.

To reiterate, it seems that UCCNC is interpreting the G2 and G3 moves above as being in the XY plane as opposed to the intended XZ plane.

[dezsoe]

I don't use Fusion, but the g-code standard leaves no question:

The axis of the circle or helix must be parallel to the X, Y, or Z-axis of the machine coordinate system. The axis (or, equivalently, the plane perpendicular to the axis) is selected with G17 (Zaxis, XY-plane), G18 (Y-axis, XZ-plane), or G19 (X-axis, YZ-plane).

So the plane must be specified. It is, because by default G17 is selected as you can see in the modals display. I did a quick peek into the LinuxCNC documentation: it is exactly quoted from the RS274 standard. (The same as what I quoted.)

[Roby]

Thank you for checking.

I now have a working (but untested) variation of the UCCNC Post Library that uses G2/G3 moves for all planes (not just XY per the Autodesk default) including the relevant G17/18/19 operations.

This required reading of select parts of the the Autodesk Post Processor Training Guide and incorporating code from another Post Library (I used the Masso Post Library).

The main limitation I've experienve with UCCNC is that the speed of 3D toolpaths are somewhat jerky and speed constrained on my machine because the paths are linearised. For example, fretboard radiusing is capped at 100IPM and I expect G2/G3 curves will allow me to run this operation 3-4x faster.

I'll test the output later on and will report back.