uc100 G02 doesnot work

N0010 (Filename: screwin around.tap)

N0020 (Post processor: Mach3 plasma.scpost)

N0030 (Date: 22/11/2017)

N0040 G20 (Units: Inches)

N0050 G53 G90 G91.1 G40

N0060 F1

N0070 S500

N0080 (Part: screwin around)

N0090 (Operation: Inside Offset, layer 2, T1: Plasma,

0.0591 in kerf)

N0100 M06 T1 F60.0 (Plasma, 0.0591 in kerf)

N0110 G00 Z0.3937

N0120 X3.0146 Y0.9558

N0130 Z0.1181

N0140 M03

N0150 G04 P0.5

N0160 G01 Z0.0591 F3.937

N0170 G02 X3.0146 Y0.9558 I0.0000 J1.9704 F60.0

N0180 (Operation: Outside Offset, 0, T1: Plasma, 0.0591

in kerf)

N0190 M05

N0200 G00 Z0.3937

N0210 X2.8024 Y-0.0231

N0220 Z0.1181

N0230 M03

N0240 G04 P0.5

N0250 G01 Z0.0591 F3.937

N0260 G03 X5.9642 Y2.3744 I0.1976 J3.0231 F60.0

N0270 G01 X11.4106 Y2.3571

N0280 X11.4103 Y1.1365

N0290 G03 X11.4399 Y1.1070 I0.0295 J-0.0000

N0300 G01 X11.9399 Y1.1066

N0310 G03 X11.9694 Y1.1361 I0.0000 J0.0295

N0320 G01 X11.9690 Y2.3566

N0330 X12.6579 Y2.3579

N0340 Y1.1375

N0350 G03 X12.6873 Y1.1080 I0.0296 J0.0000

N0360 G01 X13.4373 Y1.1052

N0370 G03 X13.4670 Y1.1347 I0.0001 J0.0295

N0380 G01 X13.4668 Y3.2089

N0390 G03 X13.4372 Y3.2385 I-0.0295 J-0.0000

N0400 G01 X6.0202 Y3.2378

N0410 G03 X2.8024 Y-0.0231 I-3.0202 J-0.2378

N0420 M05

N0430 G00 Z0.3937

N0440 M05 M30

We are now sending the uc100 to our customers and

found that it does not

work on G02, it skips the code.

Reply from UC100

This is not a problem of the UC100, but a problem how

your g-code is constructed.

The problem is that the circle is full (360°) which is

a known problematic case in CNC control.

Let me highlight the problematic code and what is

happening for you:

N0120 X3.0146 Y0.9558

N0170 G02 X3.0146 Y0.9558 I0.0000 J1.9704 F60.0

The first line is a linear movement, it moved the X

axis to X = 3.0146 and the Y axis to Y=0.9558 and after

that the XY axes are no more moved, the next time they

move is the G02 line.

So, the 3.0146;0.9558 coordinate is where the machine

stops in XY, however the 3.0146;0.9558 coordinate is

not sure that the machine can step on it, because the

grid where the axes can step is defined by the steps

per value.

For example your steps per value is just for simplicity

is 100 units per step, then your resolution is 0.01

units. If the unit is inches or mm does not matter for

this example. And I think it is simple to understand

that the axis then can step only on 0.01, 0.02, 0.03

and so on positions if the home position was 0 just to

keep the example simple. The axis then can't step on

for example 0.005, because it is between 2 grid points,

the coordintate is in between the resolution grid, so

stepping there is physically not possible.

Now you code an arc like you did with the end and start

points are the same, then the problem is that right

before the arc execution it is not sure that the

machine is really standing on the 3.0146;0.9558,

because your axis resolution might not make it possible

(depends on what your axis resolution, the steps per

value is) and so the registered coordinate prior to the

arc execution could be slightly different than what is

the programmed coordinate, e.g. your resolution is just

again make the same simple example is 0.01 and you

command an axis to move to 0.9558, then the axis could

step to 0.96 or 0.95, there is no inbetween coordinate

possible with this resolution.

So, when your circle code has to be cut, e.g. in a

Single block cycle, then the last registered coordinate

(the current coordinate) will be a bit different of

what you programmed in your code and with your code

that could mean a totally different circle. A full

circle can become a close to null arc angle size circle

and a close to null arc angle size circle can become a

full circle.

And this is because of the same XY start and end

coordinates, because in your example code this is a

clockwise G2 circle, so the movement vector on the

start will point fully left and if the last registered

coordinate in this example on the X axis is not 3.0146,

but for example 3.02 because of the poor steps per

resolution then this will mean a very small arc angle,

because the start X coordinate is on the right of the

3.0146 point and the programmed arc is G2, so it will

start left and so the machine will move from 3.02 to

3.0146 only, or 3.02 to 3.01 technically if we keep the

example 0.01 (100 steps per) resolution and then that

is the end of this arc, programmatically it will be

proper, because by coordinates it will mean a very

small angle arc. Further explaining this, this is

because an arc is coded with the start point coordinate

is where the machine stands prior to executing the arc

and the endpoint is programmed in the G2 or G3 line.

And what will not be proper is where your machine will

stand prior to the arc execution, because it can't step

on the start coordinate, the low steps/value will limit

where it can stand.

And so, this type of problem is not a problem of the

UC100 and not even a problem of Mach3, but it is a

problem of how the g-code is constructed.

Any good CAM programs have an option in the post

processor about how to handle very small and very large

angle arcs. A good practise is to order the CAM

software to not generate these, but to construct very

small arcs from lines and to cut up large angle

circles, like full circles to 2 * 180°or 4 * 90° arcs

then this problem will never happen, because the start

and the endpoint of the arcs are then not so close to

eachother, they will be more far with more then one

step size on the steps grid, so the issue will not

happen.

My reply

This sounds good but The code works on mach3 printer

port and on the smoothstepper.

We now sell the smoothsteper,and would like to sell

UC100. This defect is needed to be fixed. If it is not

then I will post about it on the web.

UC100 reply

Then you do not have the same settings with the

Smoothstepper and parallel port and the UC100, because

this is not something which is handled by the UC100.

The UC100 don't know anything about your g-code, what

the UC100 and Smoothstepper see is what Mach3 sending

and that is a stream of position coordinates of the

path, not g-code.

So, it can't be a UC100 problem.

And I've tested your code meanwhile with a printer port

and it skips the G2 code with the proper steps per

units settings. Which is understandable that it is

doing it, I described you why it is happening.

So, again it is not a UC100 problem, but is the g-code

and this problem will exist with basicly any CNC

controls, it does not even have to be Mach3.

My reply

This code came from a customer.

The code runs on the other vendors product. I have 8

customers the we have included the UC100 with the

system we sold. We are Eagleplasma.com.

The settings are the same, as I have both units or this

computer.

Thanks Al