G-Code Error Breaking Tools

[Anonymous]

When posting code some tools will be posted as such...

1 T# M6

2 S# M#

3 G54

4 M8

5 G0 Z.6 <-- This code breaks tools. It rapids the tool down into the part and then rapids it to a position in the part.

6 G0 X_ Y_

7 G43 H_

8 T#

9 G0 Z0.2

This is something that has just started happening and it does not happen all of the time. Is this a glitch? Is it a setting? It only happens when it changes to a new tool as well.

The code should be as follows

1 T# M6

2 S# M#

3 G54

4 M8

5 G0 X_ Y_

6 G43 Z 0.6 H_

7 T#

8 G0 Z0.2

We have broken 2 taps and 2 drills due to this code. We are not copying and pasting anything, it happens in a new program in a new part.

[ToddHarris7556]

My first thought is : maybe your clearance/rapid/feed heights need to be checked. While this still might be true, if you say that it only happens at a toolchange, then

My second thought: it's more likely a post processor issue. While getting a post right for your machine can be a little intimidating if your not used to it, it's really not difficult. The post is really just a translator program that tells Fusion how to actually output the gcode for your machine. In this case, there's a section in there that probably says (paraphrased) "every time a new tool is required, output a G0 Z.6 before anything else". 

For what it's worth... I can share from personal experience that when you're trying to set up a new machine, or a new/edited post, there's almost no chance of breaking a tool if you take the time to cut a little air first. Either run without a tool, or just offset your Z up an inch, and cut an inch of air above the part. Once you feel confident that the gcode is doing what you want, go ahead and rezero. It takes a little bit of time, but it's still cheaper than crashing 😉

[AmandaFowler]

Hi @Anonymous 

Welcome to the Fusion 360 forums - Could you let us know what post processor you're using and attach a .f3d of a part you're seeing this in just so we can verify everything?

Thanks!

[Anonymous]

This is the code and the post processor we use. The highlighted code is incorrect and is what is causing the broken tools. It only happens after a tool change and it happens randomly. Sometimes we post and it does not happen at all, other times it happens once or twice. It has happened on taps, end mills, drills, you name it. It is random and inconsistent and even happens on two different computers.

[ToddHarris7556]

@Anonymous - with all due respect - the somewhat-tricky part to addressing issues with posts is that they're 100% NOT random. The post is simply not capable of being random. It follows a very specific, but sometimes convoluted, set of rules. 

I've never submitted a post-revision request, but we've customized a number of ours internally. In fact, we chased a problem which sounds almost exactly like what you're seeing. One of our machines would 'randomly' break tools with a rapid touch-off of Z0 at the beginning of drill cycles. The easy fix at the time was we just starting zeroing off the top of stock on that machine. We lived with that workaround for probably 18 months, until it became more of a pain point. When we actually dug in and chased it down, it took a couple of hours to find it, but it wasn't a hard fix.  

I might not get to it until tonight, but let me see if I can chase down the exact edits and share with you. 

[ToddHarris7556]

FWIW - 

I did find it. It was under the ForceXYZ function in my post.  The old version used this:

  if (!machineConfiguration.isHeadConfiguration()) {
      writeBlock(
        gAbsIncModal.format(90),
        gMotionModal.format(0), xOutput.format(initialPosition.x), yOutput.format(initialPosition.y)
      );
      writeBlock(gMotionModal.format(0), zOutput.format(initialPosition.z));
    } else {
      writeBlock(
        gAbsIncModal.format(90),
        gMotionModal.format(0),
        xOutput.format(initialPosition.x),
        yOutput.format(initialPosition.y),
        zOutput.format(initialPosition.z)
      );
    }

and it was the 

  writeBlock(gMotionModal.format(0), zOutput.format(initialPosition.z));

 that was messing us up.  I replaced it with  

   //writeComment("Is not Head configuration");
	  writeBlock(
        gAbsIncModal.format(90),
        gMotionModal.format(0), 
		zOutput.format(clearanceHeight),
		xOutput.format(initialPosition.x),
		yOutput.format(initialPosition.y)
      );

 Your mileage may vary - It doesn't sound like you have the exact same issue, so this won't be a cut & paste solution. It might give you some clues as to how to fix it, though. 

If you're going to fix it yourself, then the general procedure is something like this:

RULE #1 for editing POSTS : **** ALWAYS WORK ON A COPY **** When you get it working right, then rename it, but never contaminate the file you had (almost) working before.

2) Make use of the DUMP post. This just dumps a very long list of all the raw output variables and lets you see what's going on. That in itself is semi-useful, but won't narrow things down a ton. 

3) Make use use of comments. Go ahead and stick a   "writeComment("Edit your comment text here");" anywhere you want in the post. (Yes, the semicolon is important). When you post it out, that comment will be inserted in your GCode. Use a ton of comments, and you'll be able to narrow down which parts of the post are outputting which parts of the GCode.

[ToddHarris7556]

I should have also added this:

In the onSection function, (which runs everytime a new operation is encountered, I added this up at the top:

 var clearanceHeight = getParameter("operation:clearanceHeight_value");	

which allows use of the clearanceHeight variable when calling ForceXYZ

[AmandaFowler]

Hi @Anonymous

I just wanted to follow up on this thread - did the information @ToddHarris7556 passed along resolve your issue? If not, we're glad to keep helping you out but we'll need the .f3d file to verify that the problem is wholly in the post processor.

Thanks,