CAM G-code issue with Mach3 post processor

[Anonymous]

Hi folks,

I created a simple part in Fusion360 for testing G-Code generation. CAD, CAM and also generation of G code with the mach3mill post processor works like a charm.

But I figured out, that some instructions cause problems during machining. I have attached my simple test design and corresponding G code.

Within this file, instruction "N255" causes problems:

...
N195 G0 Z5.
N200 X11.453 Y-3.278
N205 G1 Z2.5 F200.
N210 Z-5.
N215 G2 X11.233 Y-3.27 I0.047 J4.283 F500.
N220 G3 X10.965 Y-3.261 I-0.267 J-4.275
N225 X10.903 Y-3.488 I0. J-0.122
N230 G2 X11.512 Y-4.097 I-0.903 J-1.512
N235 G3 X11.739 Y-4.035 I0.104 J0.062
N240 X11.73 Y-3.767 I-4.283 J0.
N245 G2 X11.722 Y-3.5 I4.275 J0.267
N250 G3 X11.5 Y-3.278 I-0.222 J0.
N255 G2 X11.453 I0. J4.283
N260 G0 Z5.
...

In Instruction "N255" there is only movement in X-Axis, Y-Axis stays at its position, although it is a circular movement (G2). This caused my machine control justifiably to fail --> "No circular movement possible".

Also Radius at the beginning and at the end of the movemend is slightly different. If I replace "I0." with "I-0.024" it works well. But replacing "G2" with "G1" and ommiting I and J would do a even better job, since it is a linear movement anyways.

Why uses Fusion G2 in such situations and how can I pevent fusion from doing so?

Thanks in advance and best regards,

Alex

 

[Anonymous]

Please, try delete in first line next codes G94 G91.1 G40 G49, G21 in second line you can delete, also.

My opinion is that G91.1 makes trauble,but...

Second problem can be in mach3 setup or configuration. We have turning machine with mach3 control. After install mach3 instead fanuc 0T , only one problem was be G2/G3 orientation. Than we call service guy and he is change something in configuration, i dont know what! But, until today, machine works fine, without any issues.

Check the version of mach3 mill postprocessor, because last realise works fine. 

Best regards

[Anonymous]

Please, try this postprocessor.

This is my modification for one machine on mach3. 

NOTE: i am working with R, not I/J , but You can choose what you want. 

Offcourse, pay attention, please.

[Anonymous]

The issue is not related to these G94 G91.1 G40 G49, G21. When using I and J, command G91.1 is needed to specify whether I and J are absolute or relative.

To make this clear, I am using a Mach3 compatible machine controller, not Mach3 itself. Should have mentioned that above in a more clear manner...

G2/G3 movements do work fine, it is definetly not related to settings of the machine controller. Only those G2/G3 movements which actually do not form an Arc (like N255 above) cause problems.

[Anonymous]

Thanks for your newer version of the Mach3 postprocessor! With this version, initial commands are different but the faulty instruction is generated the very same way:

...

G3 X11.739 Y-4.035 I0.104 J0.062
X11.73 Y-3.767 I-4.283 J0.
G2 X11.722 Y-3.5 I4.275 J0.267
G3 X11.5 Y-3.278 I-0.222 J0.
G2 X11.453 I0. J4.283
G0 Z5.
X11.722 Y-11.453

...

Best regards,

Alex

[AchimN]

Try to change the minimumChordLength into your post from this:

minimumChordLength = spatial(0.01, MM);

to eg this:

minimumChordLength = spatial(0.05, MM);

[Anonymous]

I have not any issues with this postprocessor.

Line without X or Y looks like prepair for lead out, G2 X... I... J...  ;

Now, i am try with IJ, very complicate 3d forms , without any problems or alarms (3d pocket, 3d contour,2d contour and scallop), 

[AchimN]

The setting proposed above just eliminates very small arc moves, so by testing the sample part i did the a G1 move instead of a tiny G2 movement.

[Anonymous]

I have tested your suggested setting:

minimumChordLength = spatial(0.05, MM);

It indeed omitts the small arc and executes a G1 instead:

...

N245 G2 X11.722 Y-3.5 I4.275 J0.267
N250 G3 X11.5 Y-3.278 I-0.222 J0.
N255 G1 X11.453
N260 G0 Z5.
N265 X11.722 Y-1

...

So my controller is able to execute all the code. Thumbs up!

My only concern is that this seems to be a workaround for this specific scenario. In this case the small arc was 0.047mm, what if Fusion decides to use 0.055mm somewhere else in the future, will I face the same issue again?

Thank you very much for your help!

[AchimN]

It could potentially since I do not know the specific capabilities of your control regarding arcs. The proposed setting you are now using helped in 99,99% where users had issues with small arcs.

[Strooom]

Hi,

I am improving the Openbuilds postProcessor as it has some issues with very small arcs as well.

I'd like to understand what the following parameters are doing (this seems not to be documented here) :

minimumChordLength : ???

minimumCircularRadius : seems to be self-explaining, but what happens if Fusion360  needs a smaller radius arc ? will it linearize ?
maximumCircularRadius  : again, what happens if exceeded ? why set a maximum ?
minimumCircularSweep : is this the minimum angle of the arc ? why set such  a minimum ?

maximumCircularSweep : is this the maximum angle of the arc ? what does Fusion360 do when it needs eg 270deg and maximum is set to 180deg..

If maximumCircularSweep equals 180deg, will isFullCircle() ever evaluate true ? I guess not, so this branch in onCircular could be removed...

What does .format() do ? as in 

function onLinear(_x, _y, _z, feed)
	{
	var x = xOutput.format(_x);
	var y = yOutput.format(_y);
	var z = zOutput.format(_z);
...
	}

it seems you can test it for true / false because further-on there is..

if (x || y || z)
		{
		writeBlock(gMotionModal.format(1), x, y, z, f);
		}

It would be helpful to understand what .format(1) is then doing...

[HughesTooling]

---

@Strooom wrote:

Hi,

I am improving the Openbuilds postProcessor as it has some issues with very small arcs as well.

I'd like to understand what the following parameters are doing (this seems not to be documented here) :

minimumChordLength : ???

minimumCircularRadius : seems to be self-explaining, but what happens if Fusion360  needs a smaller radius arc ? will it linearize ?
maximumCircularRadius  : again, what happens if exceeded ? why set a maximum ?
minimumCircularSweep : is this the minimum angle of the arc ? why set such  a minimum ?

maximumCircularSweep : is this the maximum angle of the arc ? what does Fusion360 do when it needs eg 270deg and maximum is set to 180deg..

---

Minimum chord length and radius.  I've seen some controls that produce a full circle if the end point is the same as the start. As the g code is only 3 decimal places for mm and 4 for inches there a bit of fuss at times so a very arc short move will make the control do a full circle so I always set these 2 to 0.03. I think the sizes on the dialog are all in mm by the way.

For minimum sweep I guess you might run into the same problem as above.

Max sweep, I have a Heidenhain control that does helical moves and allows something like 15 turns max, I have this set to 5400 so the post will just split helical moves of more than that into however many are needed. If your control can do a full circle set it to 360. To answer your question above Fusion would just split the arc in to 2 arcs I guess 1 of 180° and one 90°.

Mark

[Strooom]

Ok, thanks for sharing that.

So what does Fusion360 do when it needs to output an arc shorter than minimumChordLength or radius smaller than minimumCircularRadius ? Will it linearize that part of the toolpath ?

I guess I could find out with a little experimenting, but it's always great to get inside information 🙂

P

[HughesTooling]

Yes it just linearises them, lets face it a 0.03mm line or arc isn't going to make much difference. 

A thought about max radius, I have a Anilam control that's constantly complaining about arcs out of tolerance, they work fine on my other controls. The problem is again down to not enough decimal places to define the arc, the better controls allow for the inaccuracies but the problem gets worse the bigger the radius so converting to lines might be more accurate.

Mark

[Strooom]

I've tested :

using a 10mm diameter tool, cutting a 5.01mm fillet radius internal corner. This creates a 90deg arc with 0.01 mm radius: 

Y14.9900
G3 X14.9900 Y15.0000 I-0.0100
G1 X-14.9900
G3 X-15.0000 Y14.9900 J-0.0100
G1 Y-14.9900
G3 X-14.9900 Y-15.0000 I0.0100
G1 X14.9900
G3 X15.0000 Y-14.9900 J0.0100
G1 Y0.0000

1. when Fusion360 needs to output an arc with an angle more than maximumCircularSweep, it linearizes this. So it's not splitting it into multiple sub-arcs.

2. when Fusion360 needs to output an arc with a radius smaller than minimumCircularRadius, it linearizes this.

3. when Fusion360 needs to output an arc with a radius smaller than minimumCircularRadius, it linearizes this.

In all 3 cases, the output becomes :

Y14.9900
X14.9900 Y15.0000
X-14.9900
X-15.0000 Y14.9900
Y-14.9900
X-14.9900 Y-15.0000
X14.9900
X15.0000 Y-14.9900
Y0.0000

[Strooom]

ok thanks!

I'm not complaining, I just want to understand how it all works together so I can write the most robust/performant GRBL postProcessor.

[Strooom]

one more test-result : when I reduce tolerance, Fusion does split a 90deg arc into multiple smaller arcs.. eg when maximumCircularSweep = toRad(45); 

The linearization in my previous was probably done because the sub-arcs could be replaced with linear segments, still respecting tolerance. (arc radius was 0.01mm, tolerance was 0.005mm)

It all starts to make sense 🙂