Fuion 360 tool change crashes tool / work

[imvu]

I have a part with 2D Pocket using tool 3, then 2D Adaptive using tool 4, then 2D Pocket using tool 4.

In the code that gets generated between the first two paths (tool 3 and tool 4,) the CAM generates a toolpath that moves the tool before height offset has been applied.

When the length of tool 4 is longer than the length of tool 3, this means that it will move the tool deeper than intended, crashing it into the work.

This is pretty clearly a bug, and a bad one, too, because it ruins both work and tools!

[Steinwerks]

Which post processor are you using? This comes through the post not the CAM directly.

[imvu]

Tormach PCNC 1100.

I looked at it to see where this movement is generated but didn't immediately find it.

[jwatte]

Looking some more, I found the tool change code, and it looks like it's easy enough to apply the length offset right after tool change:

if (tool.comment) {
  writeComment(tool.comment);
}
writeBlock(gFormat.format(43), hFormat.format(tool.lengthOffset)); // <-- NEW LINE

Still, I'm short a carbide cutter, 30 minutes part work, and some stock 😞

(Separately: I was logged in as another address that I use for 3ds Max / Maya subscriptions; now logged in with the Fusion address...)

[Steinwerks]

Are you using this post specifically? http://cam.autodesk.com/posts/?p=tormach

[jwatte]

No, I'm using the Mach3 controller, and thus the Mach3 based post processor.

(I now realize there's two different ones, based on version, because Tormach changed their bundled software a while back -- sorry to have been unclear!)

"Mach3Mill post processor configuration" by Artsoft.

The problem is here:

  var initialPosition = getFramePosition(currentSection.getInitialPosition());
  if (!retracted) {
    if (getCurrentPosition().z < initialPosition.z) {
      /* !!!!!! THIS WILL MOVE AFTER TOOL CHANGE BEFORE OFFSET APPLICATION !!!!! -- jwatte */
      writeBlock(gMotionModal.format(0), zOutput.format(initialPosition.z));
    }
  }

  if (insertToolCall || retracted) {
    var lengthOffset = tool.lengthOffset;
    if (lengthOffset > 256) {
      error(localize("Length offset out of range."));
      return;
    }

    gMotionModal.reset();
    writeBlock(gPlaneModal.format(17));
    
    if (!machineConfiguration.isHeadConfiguration()) {
      writeBlock(
        gAbsIncModal.format(90),
        gMotionModal.format(0), xOutput.format(initialPosition.x), yOutput.format(initialPosition.y)
      );
      writeBlock(gMotionModal.format(0), gFormat.format(43), zOutput.format(initialPosition.z), hFormat.format(lengthOffset));
    } else {
      writeBlock(
        gAbsIncModal.format(90),
        gMotionModal.format(0),
        gFormat.format(43), xOutput.format(initialPosition.x),
        yOutput.format(initialPosition.y),
        zOutput.format(initialPosition.z), hFormat.format(lengthOffset)
      );
    }

[Steinwerks]

Can you attach the .cps file here? The location of the tool length offset call should actually be just past what you're looking at.

[jwatte]

What I showed was the plain downloaded mach3mill.cps from the Autodesk site. (mach3mill.cps)

I'm attaching my edited copy (adding the crash-preventing tool length offset line.)

Note the Z move that happens AFTER T4 M6, but BEFORE G43 H4, in the code I pasted.

Any movement between M6 and G43 is asking for trouble IMO.

I can't think of any reason why you wouldn't want to G43 H4 right after T4 M6, so that's where I added it.

[jwatte · Accepted solution]

One additional note, that a friendly Autodesk support person pointed out: This happens when "useG28" is false in the settings.

I can't use G28, because it spends way too much time traversing to the absolute machine home (the Tormach has slow rapids and relatively large work area.)

I'm probably going to have to patch the postprocessor if I ever update to the latest version again, unless I can get this change folded in.

(Also, when not using G28, it'd be useful if it traversed to the retract Z at least -- I'm adding that too to my post)

For anyone else who wants a mach3mill post that actually works with useG28: false AND does not move the spindle without applying tool offsets, I'm attaching my version to do that.