Machsupport Forum
G-Code, CAD, and CAM => G-Code, CAD, and CAM discussions => Topic started by: eagleplasma 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
-
Thousands of people have been using the UC100 with Mach3 for many years, so I'd have to side with CNC Drive on this one.
-
Hi,
ger21 is right, how could G02 not work when thousands have been using it?
Whom replied to your enquiry, and to whom did you direct your query? Doesn't really sound like CNCDrive at all.
Craig
-
Hi Al,
I am not sure the explanation you received from UC100 has any credibility or not – It certainly seems strange to me.
You need to look at your ‘Mach3 plasma.scpost’ Post Processor as a matter of urgency – it is not preparing the Mach3 Gcode correctly (at least not as Mach3 wants to see it) and it is creating errors.
Perhaps the most important change to make is to have it place the G91.1 on a separate line (certainly not on the same line as the G90).
Try placing the G91.1 on a separate line and see if your UC100 works correctly then. ;)
Tweakie.
-
email was sent to Balazs Klincsik at cncdrive dubblecnc@gmail.com
-
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.
This has always been my understanding of how motion controllers work with Mach3.
Mach3 reads the g-code, and it's trajectory planner tells the UC-100 where to move to. So the UC100 never knows if it's movements are from a G0,G1,G2,G3.....
What version of Mach3 are you using? And do you have the latest version of the UC100 plugin?
In Mach3, go to Config > Plugins, then click Config, next to the UC100 plugin. A window will open, with a button to get the latest plugin. This plugin will often be newer than the latest release plugin.
-
UC100 V2.148 Mach3 R3.043.066
-
Have you tried Mach3 3.043.062?
3.043.066 is know to be very buggy.
2.151 is the latest plugin on the CNC Drive website, and there may be a newer one if you check with the method I listed above.
-
I am also having essentially the same issue, using the UC100 Motion Controller, with mach 3. Everything works, except for the G2 I,J circle interpolation.
Has anyone definitively solved this issue as of yet? We just changed machines and we have work needing to be completed.
-
As posted above, thousands of people have been using the UC100 for over a decade, and the only time I've ever heard of this is in this thread.
-
Config -> General Config -> I/J Mode Abs/Inc ?
-
Naturally that was the first thing I tried.
-
I've gotten it to somewhat work, by changing the post processor in SheetCam to "MACH THC with scriber" however, I must not have the appropriate options turned on in the post processor, the machine continues to climb in the Z-axis with every retraction about.