Synthetos Shop

Arc Specification Errors and Decimal Accuracy

From the original Synthetos forum (2011–2025)

Started by S221B on in TinyG Support. 5 replies, last activity Jan 10, 2020.

S221B #

Hi everyone.

As I continue to learn the nuts-and-bolts of how TinyG (and the related ecosystem of Fusion 360 CAM and CNCjs) work, I have come across a bit of a puzzle.

In G2/G3 arcs, due to decimal rounding error, it is not unusual for the calculated distance between startpoint-to-center and the calculated distance between endpoint-to-center to be slightly different. Ideally, they'd be the same, but with a constrained number of digits to work with, rounding error occurs - in my observations, typically around 0.001mm.

When sending GCode to the TinyG using CNCjs, I seem to often run into "arc specification errors". Clicking "continue" allows the machine to keep going, and the parts seem to turn out fine, which suggests that this is a warning and not a fatal error.

I can disable pause-on-error in CNCjs, in which case the job will run without my needing to click "continue", so from a functional standpoint I am fine. As an engineer, however, it rubs me the wrong way to need to do this.

I would think that there must be some internal error tolerance in the TinyG that throws a flag when the error is greater than a specified level. Likewise, there must be some spec in the post processor that tells Fusion 360 how many decimal places to output when generating Gcode.

My thought is that either a) upping the TinyG tolerance of acceptable error, or b) upping the number of decimal places output in the Gcode from Fusion 360 would effect a permanent solution without needing to disable pause-on-error.

Three questions:

1) Does this line of reasoning seem valid?
2) Does anybody know what the tolerance is for radial error, and if/how it can be changed in TinyG?
3) Does anybody know if/how the number of decimal places in Fusion 360 post-processor can be changed?
4) Will tinyG ignore input of more than three decimal places when in mm mode?

Thanks in advance for the input!

cmcgrath5035Staff #

Some random thoughts since you are willing to dig in and experiment.
I am not a developer and have not dug into the code, so these comments are based on accumulated input from the devs.

Your reasoning is OK but , I think, misses the point that the predominant errors are math rounding errors because the hardware is only an 8 bit machine. More digits into that machine will not improve results, most likely.

Working in mm rather than inch settings helps because all tinyG calcs are in mm, so specifying mm data and parameters minimizes the error introduced by repeated calls to the inch-to-mm conversion routines.

The most significant issue seems to be "Large I and J" parameters in arc specifications. My guess is that the work to improve performance has been to refactor the equations to minimize computational error when radius values>>increment values need to be dealt with. I might suggest that relaxing the allowed deviation accuracy in the Post Processor, which would have the effect of turning "almost straight arcs" into short linear moves.
Not using G2/G3 almost always works, but results in very large Gcode files.

The devs do not like the idea of relaxing the tinyG tolerance, as the accumulated errors in a long job could be worse than the current result.

These are thoughts, not necessarily solutions.

S221B #

Update:

Well, I dove into the Fusion 360 post-processor. I am not a JavaScript expert, but I did recognize one line that seems to control the number of decimals in the output.

(I include this for the benefit of anyone else who goes down this path.)

The stock line is:
var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true});

This means "if unit is set to MM, use 3 decimal places for xyz values, else use 4".

I tweaked it to read:

var xyzFormat = createFormat({decimals:(unit == MM ? 4 : 4), forceDecimal:true});

This forces mm-unit output to have four decimal places instead of 3. I could have changed the second 4 to a 5, but I never work in inches so it's irrelevant to me. (Changing it to 5 would force inch-unit output to have an extra fifth decimal.)

I also found the stock line:

allowedCircularPlanes = 1 << PLANE_XY;

Which basically enables G2/G3 in the XY plane. I discovered changing it to read:

allowedCircularPlanes = (0<<PLANE_XY)|(0<<PLANE_ZX)|(0<<PLANE_YZ);

This has the effect of disabling G2/G3 on all three planes and forces everything to be linear (G1) moves.

There may be a more elegant way to make these tweaks (as I said, I am not a JavaScript expert, and this is my first try editing a post processor) but I figured it was worth sharing.

Cheers!

cmcgrath5035Staff #

You will likely find that disabling G2/G3 will work well, , but do expect much larger Gcode files.

Reach41 #

I am working in inches. I made one change: var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4) , I changed to MM ? 4 : 5. That fixed the problem I was having with generating a single hole out of three. All three were on the same y line, the only variance was in the x position.

cmcgrath5035Staff #

Sounds like you resolved your issue, cool.
BTW, I use a simpler Gcode generator.
Has and option "Use Arcs Y/n"

This topic is from the original forum (January 2020). Your reply starts a new discussion linked to it.

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.