Haas NGC post fails on indexed 4th axis tapping (DWO disabled) — why isn't this supported out of the box?

[nate.schnase]

I'm running Fusion 360 CAM on a Haas TM2-P with an HRT 4th axis rotary table. Machine definition is configured correctly. DWO/TCPC is not used — this machine does not support it (common on Haas 3 axis machines with upfit 4th axis). All 4th axis operations are indexed positioning only — the A axis moves to a position, clamps, and sits there while the spindle does the work.

When I post a tapping operation at any indexed rotary position (e.g., A-90 or A180), I get this error:

Error: Canned cycle 'tapping' is expanded, but following
command is not supported by post.
Unsupported speed-feed synchronization activation command.
Error in operation: '10-24 Tap'
Failed while processing onCycle() for record 2021.

After opening a support case (Case #25893545), Autodesk confirmed the root cause: when the post detects that the spindle axis and the forward direction of the section don't match — which happens at any indexed rotary position — it forces the tapping canned cycle to expand instead of outputting a native G84. The expanded cycle then fails because it cannot write the sync command.

---

What is the current "safe" workaround?

The only reliable workaround short of editing post source code that will then require testing, is:

1. Create a duplicate setup with no machine definition (3-axis mode)
2. Post the tapping operations from that setup to get valid G84 output
3. Hand-edit the resulting NC file to insert the correct A-axis index moves before each set of holes

Let that sink in. The recommended path for a standard shop operation on a standard machine is to hand-edit G-code — bypassing all simulation, verification, and back plot in the process. Any downstream change to feeds, depths, or positions requires repeating the entire manual process. This is not a workflow. This is a liability.

---

Why is this not fixed in the shipping post?

This is not an exotic configuration:

• Haas TM2-P — one of the most common brands in North American job shops
• Haas HRT rotary table — standard hardware
• Haas NGC post — Autodesk's own actively maintained post for this exact control
• Indexed rigid tapping at a rotary position — one of the most routine 4th axis operations in existence

Autodesk support provided a fix: a ~10-line edit to the .cps file that adds a conditional exception allowing tapping canned cycles to pass through when DWO is disabled and the section is not a true multi-axis move. That fix is known, but they won't say it works, and it is not in the shipping post.

The result is that every Fusion 360 user running a standard Haas NGC machine with a rotary and no DWO hits a hard post failure on tapping and is told post customization is outside standard support scope. Most machinists are not developers. The alternative — hand-editing NC files outside of simulation — introduces real risk of crashes, broken tools, and scrapped parts.

---

I am requesting:

1. This fix be incorporated into the official Haas NGC post in the Fusion cloud library
2. This case be escalated as a confirmed software defect, not closed as a support request

Has anyone else hit this? Is there an existing bug report or ideas post I can add my vote to?

---

Environment: Fusion 360 (latest) · Haas NGC post (latest cloud library) · Haas TM2-P + HRT · DWO: disabled · Indexed rigid tapping · A-90 · A180

[nate.schnase · Accepted solution]

✓ Resolved — Root Cause Found

TL;DR
FIX: Open your machine configuration → find the TCP setting → disable it. 
G84 will post correctly immediately.
Why: Machine config overrides the post processor selections for TCPC and DWO

The problem was not the post processor itself — it was a TCP (Tool Center Point) flag enabled in the machine configuration inside Fusion. With TCP enabled in the machine config, the post treats every operation as a full simultaneous multi-axis move — including tapping canned cycles — which triggers the cycle expansion and the resulting sync command error.

Critical details: This machine config has worked for this in the past and only after the April update did this become a problem.  I had already disabled both DWO and TCP in the post processor properties with no effect. The error persisted until I disabled TCP directly in the machine configuration. (which I didn't turn on or off at any point prior to the issue) The post-level toggles are overridden by the machine config — which is not documented or intuitive. You will not find this fix by adjusting post settings alone.

This configuration had been working fine for previous programs. A recent Fusion update either added the TCP flag to the machine definition and defaulted it on, or began actively honoring a flag that previous post versions ignored. Either way, a working setup broke silently after an update with no warning.