[Emc-users] G0 vs G1

It has always been my experience G40 cancels cutter compensation.

On Jul 2, 2017 2:44 PM, <tom-***@bgp.nu> wrote:

Why would G0 to a given location in one axis (X) differ such that a G1
movement in another axis (Z) causes the first axis to move? Let me
explain...

Attached is a screenshot of the back plot from Axis:
http://bgp.nu/~tom/pub/G0G1.png

The highlighted line is "G0 X#<CurrentDiameter>"

However, if you look at the back plot that IS NOT the CurrentDiameter value
where it landed. It MIGHT be "CurrentDiameter - Cutter Compensation”.

But then 2 lines down I move "G1 Z#<Z-Start>" and the line rises up to
CurrentDiameter. That is, the move “G1 Z#<Z-Start>” is also causing a
move in X to CurrentDiameter (when it should already be there - but isn’t).
Why is this? Why is the G0 move different from the G1 move? Or phrased
another way, why is that first line at an angle rather than horizontal?

According to the G-Code reference it appears both G1 and G0 are both
affected by cutter compensation so they should be the same shouldn’t they?

-Tom

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

t***@bgp.nu

2017-07-02 20:40:54 UTC

I don’t disagree but am failing to see the connection to my question…?
-Tom

Post by Stuart Stevenson
It has always been my experience G40 cancels cutter compensation.
Why would G0 to a given location in one axis (X) differ such that a G1
movement in another axis (Z) causes the first axis to move? Let me
explain...
http://bgp.nu/~tom/pub/G0G1.png
The highlighted line is "G0 X#<CurrentDiameter>"
However, if you look at the back plot that IS NOT the CurrentDiameter value
where it landed. It MIGHT be "CurrentDiameter - Cutter Compensation”.
But then 2 lines down I move "G1 Z#<Z-Start>" and the line rises up to
CurrentDiameter. That is, the move “G1 Z#<Z-Start>” is also causing a
move in X to CurrentDiameter (when it should already be there - but isn’t).
Why is this? Why is the G0 move different from the G1 move? Or phrased
another way, why is that first line at an angle rather than horizontal?
According to the G-Code reference it appears both G1 and G0 are both
affected by cutter compensation so they should be the same shouldn’t they?
-Tom
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Stuart Stevenson

2017-07-02 21:29:28 UTC

You SHOULD see different results.

Post by t***@bgp.nu
I don’t disagree but am failing to see the connection to my question…?
-Tom

value

Post by Stuart Stevenson
where it landed. It MIGHT be "CurrentDiameter - Cutter Compensation”.
But then 2 lines down I move "G1 Z#<Z-Start>" and the line rises up to
CurrentDiameter. That is, the move “G1 Z#<Z-Start>” is also causing a
move in X to CurrentDiameter (when it should already be there - but

isn’t).

Post by Stuart Stevenson
Why is this? Why is the G0 move different from the G1 move? Or phrased
another way, why is that first line at an angle rather than horizontal?
According to the G-Code reference it appears both G1 and G0 are both
affected by cutter compensation so they should be the same shouldn’t

they?

Post by Stuart Stevenson
-Tom
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------

------------------

Post by Stuart Stevenson
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

t***@bgp.nu

2017-07-02 21:45:11 UTC

Yes, I do see different results, the line becomes horizontal rather than angled. But my question is, why when cutter compensation IS on, are the moves treated differently. By the way, even if we change the first G0 to a G1, we still get the angled line. So, it isn’t G0 vs G1, it is simply that the first move is lower than it should be (by the tool diameter in the tool table) and the second move in Z causes X to rise to the compensated value. How/why?

-Tom

Post by Stuart Stevenson
You SHOULD see different results.

Post by t***@bgp.nu
I don’t disagree but am failing to see the connection to my question…?
-Tom

value

isn’t).

they?

------------------

Stuart Stevenson

2017-07-02 21:54:13 UTC

Are you sure it is cancelling cutter comp or is it changing cutter comp to
the other side of the programmed path?

On Jul 2, 2017 4:50 PM, <tom-***@bgp.nu> wrote:

Yes, I do see different results, the line becomes horizontal rather than
angled. But my question is, why when cutter compensation IS on, are the
moves treated differently. By the way, even if we change the first G0 to a
G1, we still get the angled line. So, it isn’t G0 vs G1, it is simply that
the first move is lower than it should be (by the tool diameter in the tool
table) and the second move in Z causes X to rise to the compensated value.
How/why?

-Tom

Post by Stuart Stevenson
You SHOULD see different results.

Post by t***@bgp.nu
I don’t disagree but am failing to see the connection to my question…?
-Tom

value

isn’t).

they?

------------------

------------------------------------------------------------

------------------

t***@bgp.nu

2017-07-02 22:07:52 UTC

I admit that compensation confuses me on a lathe. I have no idea if it is cancelling or changing - but why would it change? There is a single G42 at the beginning of the routine. The routine is simply cutting a taper (as can be seen by the steeper lines in the back plot) starting at CurrentDiameter and ending at X-End, Z-End.
-Tom

Post by Stuart Stevenson
Are you sure it is cancelling cutter comp or is it changing cutter comp to
the other side of the programmed path?
Yes, I do see different results, the line becomes horizontal rather than
angled. But my question is, why when cutter compensation IS on, are the
moves treated differently. By the way, even if we change the first G0 to a
G1, we still get the angled line. So, it isn’t G0 vs G1, it is simply that
the first move is lower than it should be (by the tool diameter in the tool
table) and the second move in Z causes X to rise to the compensated value.
How/why?
-Tom

Post by Stuart Stevenson
You SHOULD see different results.

Post by t***@bgp.nu
I don’t disagree but am failing to see the connection to my question…?
-Tom

value

isn’t).

they?

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Stuart Stevenson

2017-07-02 22:32:48 UTC

The motion I see in the link looks like I would expect it to look. Are you
expecting cutter comp on just the X axis or just the Z axis or both X and Z?

Post by t***@bgp.nu
I admit that compensation confuses me on a lathe. I have no idea if it is
cancelling or changing - but why would it change? There is a single G42 at
the beginning of the routine. The routine is simply cutting a taper (as
can be seen by the steeper lines in the back plot) starting at
CurrentDiameter and ending at X-End, Z-End.
-Tom

Post by Stuart Stevenson
Are you sure it is cancelling cutter comp or is it changing cutter comp

Post by Stuart Stevenson
the other side of the programmed path?
Yes, I do see different results, the line becomes horizontal rather than
angled. But my question is, why when cutter compensation IS on, are the
moves treated differently. By the way, even if we change the first G0

to a

Post by Stuart Stevenson
G1, we still get the angled line. So, it isn’t G0 vs G1, it is simply

that

Post by Stuart Stevenson
the first move is lower than it should be (by the tool diameter in the

tool

Post by Stuart Stevenson
table) and the second move in Z causes X to rise to the compensated

value.

Post by Stuart Stevenson
How/why?
-Tom

Post by Stuart Stevenson
You SHOULD see different results.

Post by t***@bgp.nu
I don’t disagree but am failing to see the connection to my question…?
-Tom

value

Post by Stuart Stevenson
where it landed. It MIGHT be "CurrentDiameter - Cutter Compensation”.
But then 2 lines down I move "G1 Z#<Z-Start>" and the line rises up

Post by Stuart Stevenson
CurrentDiameter. That is, the move “G1 Z#<Z-Start>” is also

causing a

Post by Stuart Stevenson
move in X to CurrentDiameter (when it should already be there - but

isn’t).

Post by Stuart Stevenson
Why is this? Why is the G0 move different from the G1 move? Or

phrased

Post by Stuart Stevenson
another way, why is that first line at an angle rather than

horizontal?

Post by Stuart Stevenson
According to the G-Code reference it appears both G1 and G0 are both
affected by cutter compensation so they should be the same shouldn’t

they?

------------------

------------------------------------------------------------

------------------

t***@bgp.nu

2017-07-02 23:56:32 UTC

I would expect compensation to be on or off period (that is, not PER axis). I am curious why you expect it to look that way. Why would you expect the first move to position itself one cutter diameter lower than where the cut should be?

We are using a NGCGUI routine that was written by someone else. After modifying it to make a taper with depth-of-cut as a consideration (as opposed to plowing through material at massive depths ;-) we saw this odd angled move that we were not expecting. We then noticed that the unexpected location was exactly 1 tool diameter below were we thought it should go, and then noticed that there was a G42 in the code. One thing lead to another and here we are...

I have been playing with G41, G42 trying to understand what the $%%@ cutter compensation means on a lathe. I think I am more confused than ever. But one thing is clear, I do not understand why G42 would cause that line to angle up like that, or more specifically why it would seem to be turn on on one move and then off on the next.

Also, Also…I have very weird behavior in Axis when trying to set G41 (to just play with what the back plot looks like using each one). It complains that you can’t have G41 with G17 (plane). Ok, all well and good. This is why there is a G18 clearly in the file, but even though the program runs Axis does not switch to G18. I have to issue G18 at the MDI prompt. At which point G41 works. But, then Axis says, when I go to move the machine home that it cannot use G53 with Cutter Compensation on. Why? G53 is machine coord, who cares if cutter compensation is on? To add insult to injury Axis also shows G40 in it’s active G-Codes even though I can issue G18 and G41. There is some really strange stuff happening.

At this point, my eyes have glazed over and I think my inclination is to just completely ignore G41/G42 from now on. G40 will be my friend. Ugh.

-Tom

Post by Stuart Stevenson
The motion I see in the link looks like I would expect it to look. Are you
expecting cutter comp on just the X axis or just the Z axis or both X and Z?

Post by Stuart Stevenson
Are you sure it is cancelling cutter comp or is it changing cutter comp

to a

Post by Stuart Stevenson
G1, we still get the angled line. So, it isn’t G0 vs G1, it is simply

that

Post by Stuart Stevenson
the first move is lower than it should be (by the tool diameter in the

tool

Post by Stuart Stevenson
table) and the second move in Z causes X to rise to the compensated

value.

Post by Stuart Stevenson
How/why?
-Tom

Post by Stuart Stevenson
You SHOULD see different results.

Post by t***@bgp.nu
I don’t disagree but am failing to see the connection to my question…?
-Tom

value

Post by Stuart Stevenson
where it landed. It MIGHT be "CurrentDiameter - Cutter Compensation”.
But then 2 lines down I move "G1 Z#<Z-Start>" and the line rises up

Post by Stuart Stevenson
CurrentDiameter. That is, the move “G1 Z#<Z-Start>” is also

causing a

Post by Stuart Stevenson
move in X to CurrentDiameter (when it should already be there - but

isn’t).

Post by Stuart Stevenson
Why is this? Why is the G0 move different from the G1 move? Or

phrased

Post by Stuart Stevenson
another way, why is that first line at an angle rather than

horizontal?

Post by Stuart Stevenson
According to the G-Code reference it appears both G1 and G0 are both
affected by cutter compensation so they should be the same shouldn’t

they?

------------------

------------------------------------------------------------

------------------

andy pugh

2017-07-03 08:59:22 UTC

It attempts to keep the insert tip tangential to the programmed path.
(You can see this quite nicely in the sim, if you make the tool radius
nice and big).
Tip radius is not important (typically) for straight X or Z moves, bit
becomes important for tapered cuts, which is presumably why the
routine uses it.

Be aware that you absolutely need the correct tool orientation
programmed in the tool table for the results to be correct. Also be
aware that LinuxCNC assumes a front-toolpost lathe where orientations
are concerned. You need to miror the diagram in the docs for a
back-toolpost.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

Les Newell

2017-07-03 10:34:53 UTC

Is there an option to make soft limits to work in world space on a
non-cartesian machine? I notice now I am using my kinematics module soft
limits apply to joints rather than axes. In cartesian mode the machine
comes to a graceful halt if you try jogging into a limit. In
non-cartesian mode the machine comes to an instant halt which can be
problematic.

Les

Andrew

2017-07-03 11:45:43 UTC

What is your LinuxCNC version?

Post by Les Newell
Is there an option to make soft limits to work in world space on a
non-cartesian machine? I notice now I am using my kinematics module soft
limits apply to joints rather than axes. In cartesian mode the machine
comes to a graceful halt if you try jogging into a limit. In non-cartesian
mode the machine comes to an instant halt which can be problematic.

Les Newell

2017-07-03 12:47:40 UTC

I'm running Git master at the moment.

les

Post by Andrew
What is your LinuxCNC version?

Jeff Epler

2017-07-03 13:52:30 UTC

No, it's not currently possible. It would be a welcome topic for
improvement.

Right now, kinematics is confined to the realtime trajectory planner, so
nothing is known about it at the time soft limits are being enforced in
task.

A naive approach would be to put a copy of kinematics into task; for
each motion that task considers for soft limits, divide it up "finely"
and make sure each of the points along the motion, it has a kinematics
solution. However, this is probably going to be computationally
intensive, since you're doing the work of kinematics twice.

I think a plausible way to do this is to allow definition of arbitrary
working volumes using a standard format like .stl. Then, task would
have to answer a much simpler problem: whether any part of the motion is
outside this defined volume. However, it might be wise to use an
existing library to perform this test, rather than writing an original
implementation in LinuxCNC. For example, CGAL's Side_of_triangle_mesh
can tell you whether a particular point is on the interior or exterior
of the volume.

Of course, while thinking about this it will also be a good time to do
something about the related issue which can be seen on trivkins
machines: some arcs that go outside of soft limits aren't detected by
task. I think this is because only the two endpoints are tested (which
works fine with lines and convex working volumes, but doesn't work with
circular motion or non-convex working volumes):
https://github.com/LinuxCNC/linuxcnc/issues/80
For arcs which come near the edge (where the AABB of the arc is not
entirely inside the working volume), I suspect a strategy of dividing up
the arc will be neessary to fix this for the complex working volume
case. And remember, "arcs" now includes multi-turn helices which can
additionally be rotated. Oh yeah, and there are NURBs too, even if
nobody uses them.

Jeff

Gene Heskett

2017-07-03 17:31:12 UTC

Post by Jeff Epler
No, it's not currently possible. It would be a welcome topic for
improvement.
Right now, kinematics is confined to the realtime trajectory planner,
so nothing is known about it at the time soft limits are being
enforced in task.
A naive approach would be to put a copy of kinematics into task; for
each motion that task considers for soft limits, divide it up "finely"
and make sure each of the points along the motion, it has a kinematics
solution. However, this is probably going to be computationally
intensive, since you're doing the work of kinematics twice.
I think a plausible way to do this is to allow definition of arbitrary
working volumes using a standard format like .stl. Then, task would
have to answer a much simpler problem: whether any part of the motion
is outside this defined volume. However, it might be wise to use an
existing library to perform this test, rather than writing an
original implementation in LinuxCNC. For example, CGAL's
Side_of_triangle_mesh can tell you whether a particular point is on
the interior or exterior of the volume.
Of course, while thinking about this it will also be a good time to do
something about the related issue which can be seen on trivkins
machines: some arcs that go outside of soft limits aren't detected by
task. I think this is because only the two endpoints are tested
(which works fine with lines and convex working volumes, but doesn't
https://github.com/LinuxCNC/linuxcnc/issues/80
For arcs which come near the edge (where the AABB of the arc is not
entirely inside the working volume), I suspect a strategy of dividing
up the arc will be neessary to fix this for the complex working volume
case. And remember, "arcs" now includes multi-turn helices which can
additionally be rotated. Oh yeah, and there are NURBs too, even if
nobody uses them.

I am going to try Jeff, if I can figure out how to actually use them. The
manpage is sorely lacking in an explanation of how it keeps track
of "points" when you feed it a more than 2 sets of points. I have an SS
rifle barrel that needs to lose some weight, but I don't envision doing
those long sweeping curves using just arcs with 20 yard radii. NURBS
looks like it would blend them if I understand it correctly, but I
probably don't. :( If, after the next master update, the docs for G5 and
G5.x were more explanatory than they are now, I'd be very pleased. Like
what does xy, ij and pq actually control when the 2nd, 3rd, 4th etc sets
of data are fed to G5 and family. What are the interactions? And how
can I make that work on a lathe, where G18 is probably in effect.

If I could understand that, the special config using y connected to the z
motor could be hacked up. That way it could run in G17 mode maybe?
Confusing, but sortable I believe.

Post by Jeff Epler
Jeff
----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett

--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Les Newell

2017-07-03 19:22:40 UTC

Hi Jeff,

Sorry, I probably didn't phrase it right. I understand that deceleration
on soft limits for joints on a non cartesian machine is a computational
nightmare. What I am after is to specify soft limits in world space,
just like a cartesian machine. I am interested in it for my lathe but it
has applications for many machine types. For example take a hexapod.
Depending on the Z position the head can try to move way outside the
available machining envelope without hitting soft or hard limits on the
joints. You could quite easily end up over stressing the pivot points or
hitting the structure of the machine. If you can specify soft limits in
world space (i.e stay in this XYZ box) this is less likely to happen.
This code is already in place for use on cartesian machines but it is
disabled for non-cartesian machines.

IMO soft limits on joints aren't nearly as useful. All they do is
replace hard switches. Again IMO you should have hard limit switches for
anything other than a very small machine so no matter what happens you
won't run into the end stops.

Les

Andrew

2017-07-03 19:32:37 UTC

For example take a hexapod. Depending on the Z position the head can try
to move way outside the available machining envelope without hitting soft
or hard limits on the joints. You could quite easily end up over stressing
the pivot points or hitting the structure of the machine. If you can
specify soft limits in world space (i.e stay in this XYZ box) this is less
likely to happen

I definitely remember soft world limits on my hexapod in master branch.
So I'm surprised why you don't observe that.
It should obey the world limits defined in AXIS_ sections.

WBR,
Andrew

Les Newell

2017-07-03 20:02:12 UTC

Aw hell, I've done it again. My fault. I didn't realize there were two
sets of limits. My config was automatically converted to the new format
and I didn't notice limits appear in two places now. When I changed my
limits I ended up only changing the joint limits, not the axis limits.

I've been doing a good job of making myself look dumb these last few days.

Les

Post by Andrew
I definitely remember soft world limits on my hexapod in master branch.
So I'm surprised why you don't observe that.
It should obey the world limits defined in AXIS_ sections.
WBR,
Andrew

Jon Elson

2017-07-04 01:55:59 UTC

Post by Les Newell
Aw hell, I've done it again. My fault. I didn't realize
there were two sets of limits. My config was automatically
converted to the new format and I didn't notice limits
appear in two places now. When I changed my limits I ended
up only changing the joint limits, not the axis limits.
I've been doing a good job of making myself look dumb
these last few days.

Go easy on yourself! EMC was a fairly complicated piece of
software when we took it over from NIST. It has grown quite
a bit in complexity since then. Many deficiencies or
limitations have been corrected by very sharp programming
since then (HAL, Joints-axis and the new trajectory planner,
for instance) but these have increased complexity. I was
only competent in a small area of the code back then (mostly
servo region) and work hard to just keep aware of what is new.

As for looking dumb, I have totally given up! I KNOW that
what I don't know is out there for everybody to see, but I
still get great use out of LinuxCNC, and HATS OFF to the
guys who really know it so well!

Jon

Mark

2017-07-04 11:27:07 UTC

Go easy on yourself! EMC was a fairly complicated piece of software
when we took it over from NIST. It has grown quite a bit in
complexity since then. Many deficiencies or limitations have been
corrected by very sharp programming since then (HAL, Joints-axis and
the new trajectory planner, for instance) but these have increased
complexity. I was only competent in a small area of the code back
then (mostly servo region) and work hard to just keep aware of what is
new.
As for looking dumb, I have totally given up! I KNOW that what I
don't know is out there for everybody to see, but I still get great
use out of LinuxCNC, and HATS OFF to the guys who really know it so well!
Jon

I know how you feel. I feel pretty clueless compared to guys like Andy,
John, Seb, Sam and a whole bunch of others. I try to absorb the
knowledge here like a sponge, but my mind is more like a sieve. ;-)

Mark

theman whosoldtheworld

2017-07-05 07:41:15 UTC