Fusion Manufacture
Talk shop with the Fusion (formerly Fusion 360) Manufacture Community. Share tool strategies, tips, get advice and solve problems together with the best minds in the industry.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2D contour produces incorrect gcode M03 - Bug?

Message 1 of 5
250 Views, 4 Replies

2D contour produces incorrect gcode M03 - Bug?

I have found an issue with the 2D contour toolpath which produces incorrect gcode on holes, resulting in them being undersized.

I have a part with multiple 6.05 mm holes. They were drawn using a rectangular array so I know they are definitely all the correct size, and checking with the inspection tool on the model confirms this.

If each of the individual holes are done with there own 2D contour operation it works fine. However if all 32 holes are selected in a single 2D contour operation, then it produces errors in approximately 8 of the holes.
This is the main reason why I believe it to be a bug rather than an issue with my workflow.


I am using the "FANUC - Inverse Time and A-axis" post processor as instructed by our machine manufacturer. Our machine is a MACH MDS-700-4T, a servo ball screw direct drive, 3 axis knee mill.

Here is an example of a correct 2D contour that I am using to clean a previous bore operation;


Tool is 5mm Diameter endmill, doing a .25mm radius vertical lead in, then a .25mm horizontal lead, then 2 finishing passes both at 6.05mm.


N30160 Z23.8
N30165 G01 Z19.8 F100.
N30170 Z7.05
N30175 G18 G02 X424.025 Z6.8 I0.25 F200.
N30180 G01 X424.275
N30185 G17 G03 X424.525 Y-16.975 J0.25
N30190 X423.475 I-0.525 F150.
N30195 X424.525 I0.525
N30200 X423.475 I-0.525
N30205 X424.525 I0.525
N30210 G00 Z24.8
N30215 X450.018 Y-17.311
N30220 Z23.8


See how the "I" value is I0.525 (line N30190 to N30205), which is correct for a 6.05mm hole ((2.5mm r + 0.525)*2 = 6.05)
Also note that the 0.25 vertical (N30175) and horizontal (N30185) lead-in is is also given as an "I"/"J" value on a G02/G03 command.


Now on an identical hole in the model next to the example above, this is the code that is produced;


N30010 Z23.8
N30015 G01 Z19.8 F100.
N30020 Z7.05
N30025 X372.022 Y-17.306 Z6.994 F200.
N30030 X372.035 Y-17.293 Z6.942
N30035 X372.056 Y-17.272 Z6.894
N30040 X372.084 Y-17.244 Z6.855
N30045 X372.118 Y-17.211 Z6.825
N30050 X372.155 Y-17.173 Z6.806
N30055 X372.194 Y-17.134 Z6.8
N30060 X372.371 Y-16.957
N30065 G03 Y-16.604 I-0.177 J0.177
N30070 X371.629 Y-17.346 I-0.371 J-0.371 F150.
N30075 X372.371 Y-16.604 I0.371 J0.371
N30080 X371.629 Y-17.346 I-0.371 J-0.371
N30085 X372.371 Y-16.604 I0.371 J0.371
N30090 G00 Z24.8
N30095 X397.775 Y-17.225
N30100 Z23.8


For the vertical lead-in it has made it into G01 linear movements (lines N30025 to N30055) rather than G02. It has also changed the radius for the horizontal lead-in (N30065) to 0.177 rather than 0.25.


The main issue can be seen with the G03 circle radius of 0.371mm (lines N30070 to N30085) which produces an undersized hole of 5.742mm ((2.5mm r + 0.371)*2 = 5.742), this matches the physical part that has been produced.


Furthermore I have analysed the gcode in the program NC Corrector, which shows the same issue.

NC Corrector Showing DifferencesNC Corrector Showing Differences


Another thing I noticed was that on the holes that were being programmed incorrectly the lead in was at a different angle to the correct holes. Not sure what this means, but just shows there is definitely something wrong.


I would really appreciate any suggestions as, or someone who can also replicate the issue so that it can be flagged as an issue asap.


Attached is a copy of the full gcode, as a well as the fusion 360 file. The post processor "FANUC - Inverse Time and A-axis" can be found in the fusion 360 post processor library.

Labels (3)
Message 2 of 5
in reply to: JunctionInc

Technically, the code is correct. In your first hole example, you have a single value of I-.525.

In your second hole example, there's an I and a J. When presented with both these values, calculating the hole size is as follows:

√(x²+y²)  which in this case would be: √(.371²+.371²) = .52467. With rounding, we get to .525. At most, it should be .0003mm undersize.


Now, let's examine some other issues:

1) In some holes, you have a clean G18 arc-in move, but in other holes you do not. This is a result of the arc move taking place along multiple axis, instead of a Z/X or Z/Y. When this occurs, there is no G18/G19 solution and we end up with linear fragmentation.  

2) You have no lead-out move, so the tool is going to retract along the length of the hole. Desired?

There are better solutions, if you're interested:


A) Program one hole to your liking. Use Pattern > Duplication to copy that operation across all holes.

A1) If you choose to remain using a 2D Contour (I too prefer that toolpath for most instances), I would set my leads to be at 135 degrees and get the plunge/retract point to be somewhat close to center of hole

B) Use the Circular toolpath instead and set the option for "Lead to Center".


Seth Madore
Customer Advocacy Manager - Manufacturing
Message 3 of 5
in reply to: seth.madore

Hi Seth, Thanks for your clarification.
I'm not sure why the holes that had the different gcode came out undersized then. Seems like too much of a coincidence.

What still I don't understand is why some of the hole were being processed differently to others, when they were all apart of the same operation? To me, they should be identical as nothing different was specified about them. Even if I specify lead in position and post process, some will still do linear fragmentation.

I would like to note that if I use the "circular toolpath" operation and select all the holes in one go, all gcode is identical and correct without any linear fragmentation.

Message 4 of 5
in reply to: JunctionInc

It's (regarding 2D Contour) just the way that the toolpaths calculate in the kernel. This is something that's beyond my ability to discuss with any level of intelligence (it's like black magic, voodoo and automatic transmissions). It has something to do with the sketch that is created behind the scenes and the calculations needed to determine where a toolpath should start. Multiple identical selections should "in theory" result in the same type of toolpath, but history shows that not to be the case

Seth Madore
Customer Advocacy Manager - Manufacturing
Message 5 of 5
in reply to: JunctionInc

I have seen these happen with Surfcam also, so I wouldn't really call it a bug. It is just the way that the kernel processes the code, and yes, I agree it is just plain weird.  



Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums