3
« on: November 22, 2017, 07:26:56 PM »
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