UC100 skipping G code(specifically circles)

[Maxim]

I just added a UC100 to a machine(plasma cutter) and although its running smooth and stable, it seems to skip some parts of the code. For example, if i cut a simple box with three circles inside, it will cut two of the circles, but not the third. It will cut the lead-out but not the circle itself?? I ran the exact same file through the printer port(without uc100) on the exact same computer and it works perfect. I get the same results with the UC100 on two very different computers. I have emailed support twice but no response - can anyone help?
thx

[cncdrive]

Since you've mentioned you used printer port I guess you not running the UCCNC, but Mach3 or 4?
If so please post your profile file and an example code.

[Maxim]

Hi - yes, using Mach 3. When I get back to the machine, I'll copy the file and post it
thx

[Maxim]

Hi - please see attached cut file. It looks like the UC100 doesn't see or recognize the G02 command. Any ideas why? I tried posting the machine profile, but I cant for some reason - the steps per are:
x axis - 354.4845801
y axis - 1017.924028
z axis - 21586.36453
The Kernel speed is set to 25000 in both Mach3 and Uc100. Please advise
thx

[Maxim]

Hi - has anyone had a chance to take a look yet?

[cncdrive]

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.

[Maxim]

Ok, as unfirmiliar as this sounds, i think i actually understand it. Since the source of the problem comes from the resolution, do you think increasing the resolution can correct it? Or, would it need to be so high that it wouldn't be practical? I dont like the idea of cutting circles in quadrants.
thx

[cncdrive]

The issue is that whatever small the resolution is the circles are always defined with the start point as the current point and the endpoint is programmed in the G2/G3 arc code line.
So, whatever small the resolution is even a very small difference can make a full circle an about null circle.
I've attached a small drawing on which the arc startpoint is where the black line crosses the black circle. Now if the circle start point is that point and the endpoint is also that point and a CCW circle is programmed then that will do a 360° circle.
But if the startpoint shifts to the left even a tiny bit then the same CCW circle coded will mean a very small arc which ends at the same point, so only a very tiny angle will be done before the circle code execution angle reaches the programmed endpoint's angle. This difference may be very small 0.1, 0.01 or 0.00000000001 etc. because mathematically with even a minimal shift of the coordinate to the left will change the full circle to a tiny angle arc.

And the solution of programming half circles or quadrants should not make a difference as Mach3 will optimise the path in G64 mode and so the circle will be still executed from one piece.
And ofcourse we still looking for a solution for this problem. As I said the same issue was already fixed in the UCCNC, but in Mach3 it is much harder, because we have no access to the source code and we can only work with it's public interface which is complex and also is limited in many ways.

[Maxim]

Ok, I fully understand. It looks like my only option is to cut circles in sections(or return the UC100). Assuming this is a good place to ask, does anyone know how to set Sheetcam so that it outputs circles in that manner? is there a simple option to select?
thx

[ger21]

It looks like my only option is to cut circles in sections

You could switch to UCCNC, like everyone else here has done.