Chris Radek wrote:
Is this something we want? It's very simple and I don't think it
breaks anything.
Is this something that is used on a live tool lathe? A small spindle
mounted to the cross slide and the chuck as a C axis to drill holes and
do milling? Ed.
On Sun, Dec 27, 2009 at 09:18:21PM -0600, Chris Radek wrote:
With this scheme there are no modes, no new readouts, no new gcodes.
In any place where you would normally specify X and/or Y, you can
specify @RT instead.
I went ahead and incorporated this change today. I changed the
@RT
If you want to make it completely 3D compatible then defining angle in
planar and angle perpendicular direction would have to be defined.
This all could be taken relative to the working plane selected, if I am not
mistaken, right?
I propose making @P the perpendicular angle symbol.
something
Is this something we want? It's very simple and I don't think it
breaks anything.
http://timeguy.com/cradek-files/emc/0001-Allow-use-of-polar-coordinates-in-radius-angle-form.patch
--
This SF.Net email is sponsored by
That looks quite useful Chris. The embedded examples show how easy
several very useful operations are to hand code. Does it belong in
gcode? good question If we had a good cam package to complement emc,
then it would not be needed in the gcode interpreter. Do you know of
something similar in
On Sun, Dec 27, 2009 at 01:11:38PM -0800, Lawrence Glaister wrote:
That looks quite useful Chris. The embedded examples show how easy
several very useful operations are to hand code. Does it belong in
gcode? good question If we had a good cam package to complement emc,
then it would not
In the past I have redrawn prints using polar coordinates to demonstrate a
problem with the original print. It is a natural notation for any part with
radial placed features or arcs. I do agree that it is likely a little bit of
a drift from strict NCL but useful, and as Chris put it, should not
I don't personally want or need this, but if the feature works right I
don't have an objection.
I noticed a few things about the proposed patch:
+CHKS((!_readers['x'] || !_readers['y']), _(Cannot read polar coordinate
on a machine lacking X or Y axes));
one natural thing to do might be to
On Sun, Dec 27, 2009 at 03:48:00PM -0700, EBo wrote:
If I could add my 2c, it would be that I
would like to see the mathematical transformations between the proposed
instructions and standard g-codes.
Could you elaborate on this? I don't understand what you mean.
Sure. I see that my comment was about as clear as mud... :-/
In computer graphics programming we often represent a vertex as a 4D vector
{X,Y,Z,1}. The 1 is nothing more than a convenience variable used in the
matrix multiplication. The standard operations of translation, scaling, and
rotation
On Sun, Dec 27, 2009 at 08:50:00PM -0600, Jon Elson wrote:
Drilling bolt circles would become TRIVIAL with this, touch off (0,0)
at the center, set the radius and go in 60 degree increments for a 6-hole
pattern, without consulting a calculator, or worrying about entering a
wrong digit
On Sun, Dec 27, 2009 at 06:35:54PM -0600, Chris Radek wrote:
On Sun, Dec 27, 2009 at 06:09:55PM -0600, Jeff Epler wrote:
rejected for now when not in G17
@2.5140 X0 Y0 an error; this is nonsense code, right?
Thanks, two good catches. I will add both things.
Please see the new
Hello
IMO polar coordinates are a solution looking for a problem. They are
not essential because it is always possible to use Cartesian coordinates.
For certain types of application, polar coordinates are much easier to
use than Cartesian. Polar coordinates would be used if they are
13 matches
Mail list logo
