by **cncdrive** » Tue Apr 24, 2018 9:31 pm

We have checked this problem today.

The issue is the same what was also a problem in the UCCNC for some time, but we managed to correct this issue recently in the UCCNC.

The problem is that with Mach3 we have no access to the source code and the issue is so complicated that so far we could not figure out a way to fix this problem, however we know about this problem for some time now and have tried to fix it already.

Let me describe the problem:

The issue is with full circles and when there is a command between the start point of the circle and the circle code, which inbetween command requires syncronisation between the software and the motion controller.

Functions like macros require syncronisation.

A circle is defined in G-code with the endpoint and the center, but the start point of the arc is not defined in that line of g-code, but the start point of the arc or circle is the current coordinates.

So, when there is a G2 or G3 then the macine moves from the current point to the programmed endpoint.

The steps per values set for the axes defines the resolution. So, for example if an axis has a 100 steps per value and the home coordinate is e.g. 0 then the axis can step to 0, 0.01, 0.02, 0.03 etc. the same is to the negative direction.

In a g-code like in yours there is a movement prior to the circle which defines the start point of the circle and after the circle is programmed with a G2 or G3,

but between the startpoint movement and the circle code there is inbetween code which forces the controller to syncronise (e.g. a macro).

The problem is that the prior movement which defines the startpoint of the circle contains coordinates which are not the multiple of the 1/steps per value.

Let's take the above example that the home is 0 and the steps per is 100, so the axis can move the 0, 0.01, 0.02 etc.

If the prior movement contains a coordinate like 0.006 then the axis can't step on that coordinate, because the steps per value is larger and the axis ofcourse can't make smaller steps than the 1/steps value.

This is not a problem yet, but when the macro between the prior movement and the circle code syncronises the motion controller to the software then basicly Mach3 will get 0.01 instead of 0.006, because the controller can't syncronise 0.006, because Mach3 will not accept that as it is not a multiple of the 1/steps per, so it is an invalid inbetween coordinate.

So, Mach3 will have the 0.01 coordinate instead of 0.006.

And after the syncronisation comes the full circle code which's programmed start point should be 0.006, but it is now 0.01 which is a problem because if this small difference is a shift to the direction where the circle will start then the full circle is no more a full circle by g-code, but a very small around null circle. The 360° angle will become only a bit over 0° angle.

We so far could not figure out how could we solve this problem in Mach3.

But there is usually a solution for this issue in CAM softwares. For this exact reason, to solve this problem there is mostly option for the post processor about how to handle large circles.

There is usually an option to cut them to 2 halves or 4 quadrate and to not output very large/full circles.