Fusion 360 post processor file for Plamac

Phil, can you please explain more about "then you don't lose the ability to toggle the digital or analog pins for other features". I am not sure how this is linked?

Also, I just tried it with "Compensation Type" set to "In Control" rather than "In Computer" from Fusion 360 and now it generates a G41.1 as below.

(1001)
N10 G21
N15 G90 G40
N20 G17 G91.1
N25 G64 P0.254 Q0.254
N30 M52 P1.
N35 M65 P2.
N40 M65 P3.
N45 M68 E3 Q0.

(2D PROFILE OUTSIDE)
(

---

)
(- NORMAL OPERATION. -)
(

---

)
(PLASMA CUTTING)
(THROUGH CUTTING)

N50 M190 P1.
N55 M66 P3. L3 Q1.
N60 F#<_hal[plasmac.cut-feed-rate]>
N65 G0 X-1.64513 Y61.
N70 M3 $0 S1
N75 G41.1 D#<_hal[plasmac_run.kerf-width-f]>
N80 G1 Y60.
N85 X3.35487
N90 X60.
N95 Y0.
N100 X0.
N105 Y60.
N110 X3.35487
N115 X8.35487
N120 G40
N125 Y61.
N130 M5

N135 G0 X0. Y0.
N140 G90
N145 G40
N150 M65 P2.
N155 M65 P3.
N160 M68 E3 Q0.
N165 M5
N170 M30

There are a few functions that use either a digital or analog Hal pin, like velocity change for holes, disable THC etc.
These pins cannot be used while G4x cutter compensation is active. This is a limitation in LinuxCNC.

That's not good. I want to retain THC disable. So my tool table would have to reside in F360 so kerf width gets built into the gcode and PlasmaC would ignore its kerf setting. Conversely the speeds get pulled from PlasmaC due to the F#<_hal[plasmac.cut-feed-rate]> which is required to guarantee that any velocity related THC disabled are applied correctly (as you mentioned in another post).
Is my analysis correct?
Do the same limitations apply if I buy SheetCAM or does it somehow handle things differently?

turbodude wrote: That's not good. I want to retain THC disable. So my tool table would have to reside in F360 so kerf width gets built into the gcode and PlasmaC would ignore its kerf setting. Conversely the speeds get pulled from PlasmaC due to the F#<_hal[plasmac.cut-feed-rate]> which is required to guarantee that any velocity related THC disabled are applied correctly (as you mentioned in another post).
Is my analysis correct?

Almost, with cutter compensation active you should still use the F#<_hal[plasmac.cut-feed-rate]> as velocity based THC will still work.
Cutter compensation only affects the Hal pin stuff like these:

Do the same limitations apply if I buy SheetCAM or does it somehow handle things differently?

It affects everything, it is an internal LinuxCNC limitation so it affect mills, lathes etc

The difference is that Sheetcam always produces kerf compensated code and does not use tool offsets due to issues like this and other limitations of other CNC platforms.

Thanks heaps for all the answers Phil & Rod. It is very much appreciated as well as all the work you have put into PlasmaC.

So based on the discussions in this thread is my understanding correct:

1) Don't use cutter compensation (G41.1/G42.1)

2) PlasmaC will have a material file for all material types & thicknesses which contains speeds, kerf etc. Each material has an associated number. I should be able to import the SheetCAM Powermax 65 Toolset (from forum.linuxcnc.org/plasmac/39635-hypertherm-powermax65-toolset ) using materialverter which will populate the PlasmaC material file.

3) The PlasmaC material file will have a kerf entry for each material but this is not used at all (except for conversational & straight line cuts generated by PlasmaC).

4) I should have a tool table in F360 that contains a numbered entry to match each numbered material in the PlasmaC material file. The only important parameter used from the F360 tool table is kerf as this will be embedded in the Gcode paths. The F360 PlasmaC post processor includes "P190 Pn" in the Gcode where "n" is the tool number that was selected in F360. When the Gcode runs it will automatically choose material "n" from the PlasmaC material file where it will get cut speeds, pierce height etc BUT NOT USE KERF from the material file as it is already built into the Gcode paths.

5) If for some reason I need to add a new entry to the PlasmaC material file (eg from the PlasmaC GUI) I would need to create a matching numbered entry in the F360 tool table.

6) If I were to use SheetCAM instead of F360 all of the above would still hold true.