Another Fusion 360 post processor cockup

Sounds frustrating?

Yes, I've lost most of today buggering about with the Fusion 360 / LinuxCNC post processor and the resulting g-code, trying fruitlessly to get the Bantam to cut my blessed left hand thread.

Here's the output from Fusion:

%

(1002)

N10 G7

N11 G18

N12 G90

N13 G21

N14 G28 Z0.

(THREAD2)

N15 T6 M6

(LH THREADING MF18X1.5)

N17 G54

N18 G97 S250 M3

N19 G95

N20 G90 G0 X15.093 Z6.125

N21 G0 Z-31.092

N22 X16.96

N23 G33 Z2.474 K-1.5

N24 X16.093 Z2.908 K-2.121

N25 G0 X15.593

N26 Z-30.993

N27 X17.319

N28 G33 Z2.394 K-1.5

....

and so on, until the full depth has been cut. It all looks fine and simulates fine. I can load the file and run the program until it gets to the G33 on line N23, at which point it freezes. No helpful error message, no means of forcing it to proceed.

This is similar to the issue you will encounter if you don't have a valid index pulse coming from the spindle encoder. The index pulse is used (required) for synchronising the spindle position with the tool, so that multiple passes occur at the same position each pass. However, I can see the index using Halscope and furthermore, the external / right hand thread g-code I ran back in November still works today. Clearly something else is happening.

The LinuxCNC g-code help file manual thing doesn't provide any clear pointers.

21. G33 Spindle Synchronized Motion

G33 X- Y- Z- K- $-

• K - distance per revolution

For spindle-synchronized motion in one direction, code G33 X- Y- Z- K- where K gives the distance moved in XYZ for each revolution of the spindle. For instance, if starting at Z=0, G33 Z-1 K.0625 produces a 1 inch motion in Z over 16 revolutions of the spindle. This command might be part of a program to produce a 16TPI thread. Another example in metric, G33 Z-15 K1.5 produces a movement of 15mm while the spindle rotates 10 times for a thread of 1.5mm.

The (optional) $ argument sets which spindle the motion is synchronised to (default is zero). For example G33 Z10 K1 $1 will move the spindle in synchrony with the spindle.N.revs HAL pin value.

Spindle-synchronized motion waits for the spindle index and spindle at speed pins, so multiple passes line up. G33 moves end at the programmed endpoint. G33 could be used to cut tapered threads or a fusee.

All the axis words are optional, except that at least one must be used.

Note	K follows the drive line described by X- Y- Z-. K is not parallel to the Z axis if X or Y endpoints are used for example when cutting tapered threads.

Technical Info

At the beginning of each G33 pass, LinuxCNC uses the spindle speed and the machine acceleration limits to calculate how long it will take Z to accelerate after the index pulse, and determines how many degrees the spindle will rotate during that time. It then adds that angle to the index position and computes the Z position using the corrected spindle angle. That means that Z will reach the correct position just as it finishes accelerating to the proper speed, and can immediately begin cutting a good thread.

HAL Connections

The pin spindle.N.at-speed must be set or driven true for the motion to start. Additionally spindle.N.revs must increase by 1 for each revolution of the spindle and the spindle.N.index-enable pin must be connected to an encoder (or resolver) counter which resets index-enable once per rev.

See the Integrators Manual for more information on spindle synchronized motion.

G33 Example

G90 (absolute distance mode)
G0 X1 Z0.1 (rapid to position)
S100 M3 (start spindle turning)
G33 Z-2 K0.125 (move Z axis to -2 at a rate to equal 0.125 per revolution)
G0 X1.25 (rapid move tool away from work)
Z0.1 (rapid move to starting Z position)
M2 (end program)

• See G90 & G0 & M2 sections for more information.

It is an error if:

• All axis words are omitted.

• The spindle is not turning when this command is executed

• The requested linear motion exceeds machine velocity limits due to the spindle speed

Aha!!

About the only difference I can see between my 2 files is the polarity of the "K" variable, which is negative for a LH thread if you are using a "forward" spindle direction. Sure enough, if I remove the negative sign in front of the K, the program will proceed past the line:

N23 G33 Z2.474 K-1.5

becomes

N23 G33 Z2.474 K1.5

and all is well. Until you get to the return move, which uses another (negative) K:

N24 X16.093 Z2.908 K-2.121

FFS. A global find and replace of "K" in place of "K-" results in a functioning toolpath finally.

I guess I could mess with the post processor but I'd need to be very careful. What would happen if I ran the machine in reverse with the tool behind the workpiece - that's a perfectly reasonable scenario. The change in spindle direction would require the tool to move in the opposite direction. For now, I'll simply edit the file manually and think about modifying the post processor at a later date. I don't expect to be cutting LH threads very often after all.

What about the Centroid post?

Good point, as I'll be using a Centroid Acorn for the Tree when it's working. As it's using a different post processor and some of the g-codes are different, it may not be a problem. Sure enough, the canned cycle used is G32 and the variable used ("F") is positive. I guess they thought it through a little more thoroughly.

;1001

N10 G98 G90

N11 G21

N12 G50 S6000

N13 G28 U0.

N14 G28 W0.

;THREAD2

N15 T0600

;LH THREADING MF18X1.5

N16 G54

N17 G99

N18 G97 S250 M3

N19 G4 P1.

N20 G0 X15.093 Z6.125 T0606

N21 G0 Z-31.092

N22 X16.96

N23 G32 Z2.474 F1.5

N24 X16.093 Z2.908 F1.5

N25 G0 X15.593

N26 Z-30.993

N27 X17.319

...

It's a different g-code but it's still a spindle synchronised, so the same considerations would surely apply.

Well finally I can look forward to cutting this damned LH thread of mine......