Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread andy pugh 
On 12 October 2015 at 06:44, EBo  wrote:
> I agree with option #3.  The question is what g-code whould be
> defined/chosen?   How about G78.9 (a generalization of G17, G18, and
> G19)?

I note that G16 is spare and that whereas some G-code systems use G15
/ G16 to switch between polar and cartesian coordinates, LinuxCNC
already has polar coordinates without a mode-switch so will never need
those codes for that purpose.

I like the idea of arbitrary arcs in theory, but at the same time no
CAM system would know how to use it, and only a very small sub-set of
hand-coders would use it. However those that did might well be very
grateful.

I think it would end up like the polar-coordinate syntax, useful to
those that know about it, but not widely used.

(FWIW I use polar coordinates quite frequently, it is ideal for
MDI-ing a bolt circle)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread Stuart Stevenson 
>
> --
>
> Message: 5
> Date: Mon, 12 Oct 2015 08:54:45 -0500
> From: Chris Lesiak <chris.les...@licor.com>
> Subject: Re: [Emc-developers] normal.z=0.039370
> To: <emc-developers@lists.sourceforge.net>
> Message-ID: <561bbba5.6020...@licor.com>
> Content-Type: text/plain; charset="windows-1252"; format=flowed
>
> On 10/12/2015 08:08 AM, andy pugh wrote:
> > I think we need to consider whether we want arbitrary arcs or
> > arbitrary working planes. They are not really the same thing. Out of
> > interest, with the Heidenhain code, what happens to the apparent XYZ
> > when you change plane? Are XYZ still in machine cartesian space, or
> > does the entire coordinate system shift?
>
> If you decide that arbitrary working plane is the way to go, you might
> also consider the Fanuc model.
>
> G68 X Y Z I J K R
>
Chris,
thanks for the clarification :)
heh - this IS the correct command - my memory was fuzzy


> X, Y, and Z specify the origin of the transformed coordinate system.  I,
> J, and K specify a vector about which the coordinate system is rotated
> by angle R.  It is possible to have two G68 transformations active at
> once, the second applied on top of the first.
>
> G69 cancels all G68 coordinate transformations.
>
> --
> Chris Lesiak
> Principal Design Engineer, Software
> LI-COR, Inc.
> chris.les...@licor.com
>
> Any opinions expressed are those of the author and
> do not necessarily represent those of his employer.
>
>
>
I think we should be able to probe coordinate rotations

Two points for a plane rotation and three for a complete coordinate system
orientation

thanks
Stuart

-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread Chris Lesiak 
On 10/12/2015 08:08 AM, andy pugh wrote:
> I think we need to consider whether we want arbitrary arcs or 
> arbitrary working planes. They are not really the same thing. Out of 
> interest, with the Heidenhain code, what happens to the apparent XYZ 
> when you change plane? Are XYZ still in machine cartesian space, or 
> does the entire coordinate system shift? 

If you decide that arbitrary working plane is the way to go, you might 
also consider the Fanuc model.

G68 X Y Z I J K R

X, Y, and Z specify the origin of the transformed coordinate system.  I, 
J, and K specify a vector about which the coordinate system is rotated 
by angle R.  It is possible to have two G68 transformations active at 
once, the second applied on top of the first.

G69 cancels all G68 coordinate transformations.

-- 
Chris Lesiak
Principal Design Engineer, Software
LI-COR, Inc.
chris.les...@licor.com

Any opinions expressed are those of the author and
do not necessarily represent those of his employer.


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread TJoseph Powderly 
On 10/12/2015 08:08 AM, andy pugh wrote:
> On 12 October 2015 at 13:59, TJoseph Powderly  wrote:
>> Hint: you only need 2 angles, 3 is really overconstrained.
>> It ___really___ makes programming easy.
>> All programming is just like you had a trunnion table.
>
> You can do this already in LinuxCNC with kinematics, I think (not that
> that is necessarily the right way)
>
> I think we need to consider whether we want arbitrary arcs or
> arbitrary working planes. They are not really the same thing.
>
> Out of interest, with the Heidenhain code, what happens to the
> apparent XYZ when you change plane? Are XYZ still in machine cartesian
> space, or does the entire coordinate system shift?
>
tricky question because it requires some explanation of the Heidenhain 
way of thinking.
These plane tiltings were intended to be a modal change prior to calling 
very controlled user macros ( filled in by conversational dialogs )
These were crafted to avoid any misallignment of measuring systems.
In them, I inspected the current position, insured the current position 
was stable, then tipped the plane from HERE, so no jerk occured, THEN 
allowed motion. Motion was relative to the macro's start position (HERE)
The user moved in cartesian space PRIOR to tipping the plane and calling 
my macros. Exit of the macro UN-Tipped the plane.

Since Heidenhain has thousand of work offests arranged in tables 
(DATUMS), the use simply reference a datum to work at ( identify the 
Datum table and the index into that file ). That caused the DRO to 
change ( it was now measuring form the new datum ). Then he moved to 
0,0,0,0,0,0,0,0,0 and called the plane function ( tilt ) then the action 
( one of many macros for thread at arbitrary angles etc ).

Once tilted, the DRO acted like 'normal'. You could select an alternate
screen to display it in Machine coordinates or Cartesian. But, once 
tilted, its easier to think in terms of the new plane.

the sequence was
finish one detail
pick next detail datum
move there
tilt plane
call macro
...
rinse repeat

hey i just listed 2 of the controls on eBay if you'd liek to play ;)
works fine for mills but can do real 5 axis sink edm too.

i'd like to see how it could be done in kinematics
I hope to get back into this soon, moving now

HTH
TomP tjtr33

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread TJoseph Powderly 
On 10/12/2015 08:50 AM, Stuart Stevenson wrote:
> Gentlemen,
> On my Fanuc 15mb control I would use G68 and G69 to rotate the coordinate
> system.
> I was allowed to rotate any axis by an amount
>
> ex.
> G68 X0 Y0 Z1 R20 was a rotation of the XY plane by 20 degrees. I am not
> sure R was the correct symbol but the example still stands. I was only
> allowed to one of the planes XY, YZ, ZX at a time.
>
> A second G68 would then rotate one of the other planes by a specified
> amount.
> ex.
> G68 X1 Y0 Z0 R20 rotated the ZX plane 20 degrees.
>
>   I was allowed to use two G68 lines, one right after the other.
> ex.
> G68 X0 Y0 Z1 R20
> G68 X1 Y0 Z0 R20
> would rotate the XY plane by 20 degrees and then rotate the YZ plane by 20
> degrees giving me a 3D coordinate system to work in.
>
> G69 would cancel the G68 coordinate system modification.
>
> This allowed me to align the Z axis normal to any surface on a prismatic
> part and use all of the mill/drill cycles (G01, G02, G03, G81, ...) normal
> to the face of the part.
>
> This, to me, was a very useful feature and worked until the
> manufacturer/integrator changed the pulse generator switches and added
> three more steps.
> We now have X Y Z B C (unmarked) (unmarked) (unmarked)
> The three unmarked switches all the pulse generator to:
>
> 1: Move the Z axis as if it is a quill. This allows drilling at whatever
> angle the tool is pointing. I would call this the W axis.
>
> 2: Move the tool in a X axis facing motion with the XY plane rotated to a
> normal position to the Z axis. I would call this the U axis
>
> 3: The same as 2 but with the tool moving in a Y axis facing motion. I
> would call this the V axis
>
> After the integrator implemented this 'feature' G68/G69 no longer was a
> valid command.
>
> thanks
> Stuart
>
Yes Stuart, great example of tilting planes.
My dialogs asked 'rotaion about Z'  then 'Rotation from X+'
( I wrote a lot of user dialogs in Heidenhain, aka 'conversational' )
I also had a custom macro 'untilt' , as well as 'unshift' and 'unrot'
No parms for these, they just returned to normality.
tomp tjtr33

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread TJoseph Powderly 
On 10/12/2015 08:54 AM, Chris Lesiak wrote:
> On 10/12/2015 08:08 AM, andy pugh wrote:
>> I think we need to consider whether we want arbitrary arcs or
>> arbitrary working planes. They are not really the same thing. Out of
>> interest, with the Heidenhain code, what happens to the apparent XYZ
>> when you change plane? Are XYZ still in machine cartesian space, or
>> does the entire coordinate system shift?
>
> If you decide that arbitrary working plane is the way to go, you might
> also consider the Fanuc model.
>
> G68 X Y Z I J K R
>
> X, Y, and Z specify the origin of the transformed coordinate system.  I,
> J, and K specify a vector about which the coordinate system is rotated
> by angle R.  It is possible to have two G68 transformations active at
> once, the second applied on top of the first.
>
> G69 cancels all G68 coordinate transformations.
>
yes consider these as models
not the final implementation,
the PMAC and Aerotech solutions are also different
but Roberts suggestion that its an underlying translation
that rules the way the standard interpreter acts afterwards
is a good idea.
The user interface is separate from the benefit/action
TomP tjtr33

BTW when a simple ROTATE (not the 3D titl plane )
is used on Heidenhain, theres a
machine parm that allows the DRO to show the new X' and Y'
so radial moves make more sense.


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread andy pugh 
On 12 October 2015 at 13:59, TJoseph Powderly  wrote:
> Hint: you only need 2 angles, 3 is really overconstrained.
> It ___really___ makes programming easy.
> All programming is just like you had a trunnion table.

You can do this already in LinuxCNC with kinematics, I think (not that
that is necessarily the right way)

I think we need to consider whether we want arbitrary arcs or
arbitrary working planes. They are not really the same thing.

Out of interest, with the Heidenhain code, what happens to the
apparent XYZ when you change plane? Are XYZ still in machine cartesian
space, or does the entire coordinate system shift?

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread Stuart Stevenson 
Gentlemen,
On my Fanuc 15mb control I would use G68 and G69 to rotate the coordinate
system.
I was allowed to rotate any axis by an amount

ex.
G68 X0 Y0 Z1 R20 was a rotation of the XY plane by 20 degrees. I am not
sure R was the correct symbol but the example still stands. I was only
allowed to one of the planes XY, YZ, ZX at a time.

A second G68 would then rotate one of the other planes by a specified
amount.
ex.
G68 X1 Y0 Z0 R20 rotated the ZX plane 20 degrees.

 I was allowed to use two G68 lines, one right after the other.
ex.
G68 X0 Y0 Z1 R20
G68 X1 Y0 Z0 R20
would rotate the XY plane by 20 degrees and then rotate the YZ plane by 20
degrees giving me a 3D coordinate system to work in.

G69 would cancel the G68 coordinate system modification.

This allowed me to align the Z axis normal to any surface on a prismatic
part and use all of the mill/drill cycles (G01, G02, G03, G81, ...) normal
to the face of the part.

This, to me, was a very useful feature and worked until the
manufacturer/integrator changed the pulse generator switches and added
three more steps.
We now have X Y Z B C (unmarked) (unmarked) (unmarked)
The three unmarked switches all the pulse generator to:

1: Move the Z axis as if it is a quill. This allows drilling at whatever
angle the tool is pointing. I would call this the W axis.

2: Move the tool in a X axis facing motion with the XY plane rotated to a
normal position to the Z axis. I would call this the U axis

3: The same as 2 but with the tool moving in a Y axis facing motion. I
would call this the V axis

After the integrator implemented this 'feature' G68/G69 no longer was a
valid command.

thanks
Stuart

-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread EBo 
On Oct 12 2015 10:01 AM, Stuart Stevenson wrote:
>
> I think we should be able to probe coordinate rotations
>
> Two points for a plane rotation and three for a complete coordinate 
> system
> orientation

If you only probe 2, there are special collinear cases which could 
still be two of the three standard planes.  I think you have to choose 
three to definitively define even the the three standard ones (without 
having to worry about special cases.

   EBo --


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread EBo 
On Oct 12 2015 9:42 AM, TJoseph Powderly wrote:
>
> BTW when a simple ROTATE (not the 3D titl plane )
> is used on Heidenhain, theres a
> machine parm that allows the DRO to show the new X' and Y'
> so radial moves make more sense.

I can see that being useful, but if that functionality was added to 
LCNC what would the interface look like?

   EBo --


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread TJoseph Powderly 
On 10/12/2015 12:20 PM, EBo wrote:
> On Oct 12 2015 9:42 AM, TJoseph Powderly wrote:
>>
>> BTW when a simple ROTATE (not the 3D titl plane )
>> is used on Heidenhain, theres a
>> machine parm that allows the DRO to show the new X' and Y'
>> so radial moves make more sense.
>
> I can see that being useful, but if that functionality was added to
> LCNC what would the interface look like?
>
> EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
the dros stay the same, theres just a dialog ( and maybe a notification 
like tool number, that identifies the current translation values )

NB, often, you'll be moving the 'X' axis but if you watch the Machine 
coordinates, you will see many axis moving ;) Its a brain teaser for 
those unaccustomed to it

tomp tjtr33

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread TJoseph Powderly 
On 10/12/2015 12:11 PM, EBo wrote:
> On Oct 12 2015 10:01 AM, Stuart Stevenson wrote:
>>
>> I think we should be able to probe coordinate rotations
>>
>> Two points for a plane rotation and three for a complete coordinate
>> system
>> orientation
>
> If you only probe 2, there are special collinear cases which could
> still be two of the three standard planes.  I think you have to choose
> three to definitively define even the the three standard ones (without
> having to worry about special cases.
>
> EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
yes people like to do this.
remember there is a loss of precision when you do this.
your stepper or sale cannot resolve the 1/2 or less units that
the translation incurs. thats why putting stuff on the table and 
indicating it in is a _good_ idea.
tomp tjtr33


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread EBo 
On Oct 12 2015 12:38 PM, TJoseph Powderly wrote:
> On 10/12/2015 12:11 PM, EBo wrote:
>> On Oct 12 2015 10:01 AM, Stuart Stevenson wrote:
>>>
>>> I think we should be able to probe coordinate rotations
>>>
>>> Two points for a plane rotation and three for a complete coordinate
>>> system
>>> orientation
>>
>> If you only probe 2, there are special collinear cases which could
>> still be two of the three standard planes.  I think you have to 
>> choose
>> three to definitively define even the the three standard ones 
>> (without
>> having to worry about special cases.
>>
> yes people like to do this.
> remember there is a loss of precision when you do this.
> your stepper or sale cannot resolve the 1/2 or less units that
> the translation incurs. thats why putting stuff on the table and
> indicating it in is a _good_ idea.
> tomp tjtr33

I'm actually a fan of taking statistically meaningful samples for such 
things.  I would have to look at the error propagation, but given 
sufficient samples you can resolve the 1/2 step transition as long as 
the errors are normally distributed.  That raises the question on how 
the bed/part/etc. would be sampled (to account for any swarf or 
deformations in the probed part, etc.).  That said, there is very good 
reason to indicate it in as you suggest.

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-12 Thread Jullian 
Thanks, i will do some research on the TP codes.


2015年10月12日星期一，Robert Ellenberg  写道：
> Hi Julian,
>
> As you've discovered, the trajectory planner itself can already create
arcs
> in an arbitrary plane. However, the interpreter and canon only support the
> subset that Jeff mentioned. Internally, the TP's circular arc segment is
> defined with a start point, end point, center point, and normal vector.
> Depending on the normal vector, the result is either a circular arc in the
> plane perpendicular to the normal, or a helix with the helical axis along
> the normal vector. It would be possible to support arbitrary-plane arcs in
> linuxcnc if we added interpreter / canon / plotting support, but we'd have
> to decide how to support such a thing in G-code. Here are a few options I
> can see:
>
>
>1. Extend existing G2 / G3 with an additional mode to interpret (X Y Z)
>as the end point, and ( I J K) as the center point of a spherical arc
(with
>no helical component). This is nice because it wouldn't require any
>additional parameters. Unfortunately, as Brian pointed out, it breaks
down
>for 180 deg arcs.
>2. Create a from-scratch G code that accepts 9 parameters (X Y Z as end
>point, I J K as center, and 3 others for a normal). This would solve
the
>180 deg problem (as well as the clockwise / counterclockwise problem),
but
>will be a pain to get a valid normal direction. This would make sense
only
>if there was an existing standard that CAM or other CNC controllers
>supported, and we wanted to emulate it.
>3. Add a G code to specify an arbitrary normal vector for all circular
>arcs (i.e. generalize G17-G19). This would be nice because it
preserves the
>current G2 / G3 behavior, and having an explicit normal direction
solves
>the 180 deg problem. It would involve a bunch of changes (adding extra
>modal state for the normal vector, and re-writing canon's
arc-processing
>code to handle an arbitrary normal).
>
> I'd vote for (3) if anything because it doesn't change existing syntax,
and
> it would be easier to write G-code by hand to use it. Still, it's not
> something that can happen overnight due to the scope of the changes.  Is
> anyone else interested in this capability? It will be a few months before
I
> can devote serious time to it, but I'd be willing to take a crack at it
> eventually if there's enough demand.
>
> -Rob
> On Fri, Oct 9, 2015, 7:10 PM Jullian  wrote:
>
>> Thanks for the replies,
>> Now, it's sure that a generic 3D arc is not supported by g-code。
>> But in the LinuxCNC'' codes, it has the following code like:
>> typedef struct {
>> SphericalArc xyz;
>> PmCartesian abc;
>> PmCartesian uvw;
>> } Arc9;
>>
>> is not these codes to implement  the generic arbitrary arc??
>>
>> 2015-10-09 21:06 GMT+08:00 Jeff Epler :
>>
>> > On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
>> > > Thanks,Jeff,
>> > > no bug, it's my comprehension fault,
>> > >
>> > > What i wonder now is that how the LinuxCNC do a spherical 3D arc by
>> > G_Code
>> > > or by other way?
>> >
>> > As far as I know, LinuxCNC's gcode dialect does not allow specification
>> > of fully generic arcs.
>> >
>> > You can get arcs with the normal in the Z direction in G17.  In G18 or
>> > G19 you can get arbitrary mixtures of X and Y in the normal by using
>> > coordinate system rotation (G10's R value).  But right now you can't
get
>> > an arc where the normal has a Z component and an XY component.
>> >
>> > I'm not aware of any current project to change this, but it would not
be
>> > unwelcome.  One challenge is the gcode syntax: how do you specify the
>> > normal to be used?  I think many of the other layers of code are
>> > prepared to accept arbitrary arcs, though the preview plots may need
>> > additional modification.
>> >
>> > Jeff
>> >
>> >
>> >
>>
--
>> > ___
>> > Emc-developers mailing list
>> > Emc-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>>
>>
--
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
--
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net

Re: [Emc-developers] normal.z=0.039370

2015-10-11 Thread Jullian 
No one konwing about this?

2015-10-10 7:08 GMT+08:00 Jullian :

> Thanks for the replies,
> Now, it's sure that a generic 3D arc is not supported by g-code。
> But in the LinuxCNC'' codes, it has the following code like:
> typedef struct {
> SphericalArc xyz;
> PmCartesian abc;
> PmCartesian uvw;
> } Arc9;
>
> is not these codes to implement  the generic arbitrary arc??
>
> 2015-10-09 21:06 GMT+08:00 Jeff Epler :
>
>> On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
>> > Thanks,Jeff,
>> > no bug, it's my comprehension fault,
>> >
>> > What i wonder now is that how the LinuxCNC do a spherical 3D arc by
>> G_Code
>> > or by other way?
>>
>> As far as I know, LinuxCNC's gcode dialect does not allow specification
>> of fully generic arcs.
>>
>> You can get arcs with the normal in the Z direction in G17.  In G18 or
>> G19 you can get arbitrary mixtures of X and Y in the normal by using
>> coordinate system rotation (G10's R value).  But right now you can't get
>> an arc where the normal has a Z component and an XY component.
>>
>> I'm not aware of any current project to change this, but it would not be
>> unwelcome.  One challenge is the gcode syntax: how do you specify the
>> normal to be used?  I think many of the other layers of code are
>> prepared to accept arbitrary arcs, though the preview plots may need
>> additional modification.
>>
>> Jeff
>>
>>
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-11 Thread EBo 
I agree with option #3.  The question is what g-code whould be 
defined/chosen?   How about G78.9 (a generalization of G17, G18, and 
G19)?

On Oct 11 2015 9:35 PM, Robert Ellenberg wrote:
> Hi Julian,
>
> As you've discovered, the trajectory planner itself can already 
> create arcs
> in an arbitrary plane. However, the interpreter and canon only 
> support the
> subset that Jeff mentioned. Internally, the TP's circular arc segment 
> is
> defined with a start point, end point, center point, and normal 
> vector.
> Depending on the normal vector, the result is either a circular arc 
> in the
> plane perpendicular to the normal, or a helix with the helical axis 
> along
> the normal vector. It would be possible to support arbitrary-plane 
> arcs in
> linuxcnc if we added interpreter / canon / plotting support, but we'd 
> have
> to decide how to support such a thing in G-code. Here are a few 
> options I
> can see:
>
>
>1. Extend existing G2 / G3 with an additional mode to interpret (X 
> Y Z)
>as the end point, and ( I J K) as the center point of a spherical 
> arc (with
>no helical component). This is nice because it wouldn't require 
> any
>additional parameters. Unfortunately, as Brian pointed out, it 
> breaks down
>for 180 deg arcs.
>2. Create a from-scratch G code that accepts 9 parameters (X Y Z 
> as end
>point, I J K as center, and 3 others for a normal). This would 
> solve the
>180 deg problem (as well as the clockwise / counterclockwise 
> problem), but
>will be a pain to get a valid normal direction. This would make 
> sense only
>if there was an existing standard that CAM or other CNC 
> controllers
>supported, and we wanted to emulate it.
>3. Add a G code to specify an arbitrary normal vector for all 
> circular
>arcs (i.e. generalize G17-G19). This would be nice because it 
> preserves the
>current G2 / G3 behavior, and having an explicit normal direction 
> solves
>the 180 deg problem. It would involve a bunch of changes (adding 
> extra
>modal state for the normal vector, and re-writing canon's 
> arc-processing
>code to handle an arbitrary normal).
>
> I'd vote for (3) if anything because it doesn't change existing 
> syntax, and
> it would be easier to write G-code by hand to use it. Still, it's not
> something that can happen overnight due to the scope of the changes.  
> Is
> anyone else interested in this capability? It will be a few months 
> before I
> can devote serious time to it, but I'd be willing to take a crack at 
> it
> eventually if there's enough demand.
>
> -Rob
> On Fri, Oct 9, 2015, 7:10 PM Jullian  wrote:
>
>> Thanks for the replies,
>> Now, it's sure that a generic 3D arc is not supported by g-code。
>> But in the LinuxCNC'' codes, it has the following code like:
>> typedef struct {
>> SphericalArc xyz;
>> PmCartesian abc;
>> PmCartesian uvw;
>> } Arc9;
>>
>> is not these codes to implement  the generic arbitrary arc??
>>
>> 2015-10-09 21:06 GMT+08:00 Jeff Epler :
>>
>> > On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
>> > > Thanks,Jeff,
>> > > no bug, it's my comprehension fault,
>> > >
>> > > What i wonder now is that how the LinuxCNC do a spherical 3D arc 
>> by
>> > G_Code
>> > > or by other way?
>> >
>> > As far as I know, LinuxCNC's gcode dialect does not allow 
>> specification
>> > of fully generic arcs.
>> >
>> > You can get arcs with the normal in the Z direction in G17.  In 
>> G18 or
>> > G19 you can get arbitrary mixtures of X and Y in the normal by 
>> using
>> > coordinate system rotation (G10's R value).  But right now you 
>> can't get
>> > an arc where the normal has a Z component and an XY component.
>> >
>> > I'm not aware of any current project to change this, but it would 
>> not be
>> > unwelcome.  One challenge is the gcode syntax: how do you specify 
>> the
>> > normal to be used?  I think many of the other layers of code are
>> > prepared to accept arbitrary arcs, though the preview plots may 
>> need
>> > additional modification.
>> >
>> > Jeff
>> >
>> >
>> >
>> 
>> --
>> > ___
>> > Emc-developers mailing list
>> > Emc-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>>
>> 
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
> 
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-11 Thread Robert Ellenberg 
Hi Julian,

As you've discovered, the trajectory planner itself can already create arcs
in an arbitrary plane. However, the interpreter and canon only support the
subset that Jeff mentioned. Internally, the TP's circular arc segment is
defined with a start point, end point, center point, and normal vector.
Depending on the normal vector, the result is either a circular arc in the
plane perpendicular to the normal, or a helix with the helical axis along
the normal vector. It would be possible to support arbitrary-plane arcs in
linuxcnc if we added interpreter / canon / plotting support, but we'd have
to decide how to support such a thing in G-code. Here are a few options I
can see:


   1. Extend existing G2 / G3 with an additional mode to interpret (X Y Z)
   as the end point, and ( I J K) as the center point of a spherical arc (with
   no helical component). This is nice because it wouldn't require any
   additional parameters. Unfortunately, as Brian pointed out, it breaks down
   for 180 deg arcs.
   2. Create a from-scratch G code that accepts 9 parameters (X Y Z as end
   point, I J K as center, and 3 others for a normal). This would solve the
   180 deg problem (as well as the clockwise / counterclockwise problem), but
   will be a pain to get a valid normal direction. This would make sense only
   if there was an existing standard that CAM or other CNC controllers
   supported, and we wanted to emulate it.
   3. Add a G code to specify an arbitrary normal vector for all circular
   arcs (i.e. generalize G17-G19). This would be nice because it preserves the
   current G2 / G3 behavior, and having an explicit normal direction solves
   the 180 deg problem. It would involve a bunch of changes (adding extra
   modal state for the normal vector, and re-writing canon's arc-processing
   code to handle an arbitrary normal).

I'd vote for (3) if anything because it doesn't change existing syntax, and
it would be easier to write G-code by hand to use it. Still, it's not
something that can happen overnight due to the scope of the changes.  Is
anyone else interested in this capability? It will be a few months before I
can devote serious time to it, but I'd be willing to take a crack at it
eventually if there's enough demand.

-Rob
On Fri, Oct 9, 2015, 7:10 PM Jullian  wrote:

> Thanks for the replies,
> Now, it's sure that a generic 3D arc is not supported by g-code。
> But in the LinuxCNC'' codes, it has the following code like:
> typedef struct {
> SphericalArc xyz;
> PmCartesian abc;
> PmCartesian uvw;
> } Arc9;
>
> is not these codes to implement  the generic arbitrary arc??
>
> 2015-10-09 21:06 GMT+08:00 Jeff Epler :
>
> > On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
> > > Thanks,Jeff,
> > > no bug, it's my comprehension fault,
> > >
> > > What i wonder now is that how the LinuxCNC do a spherical 3D arc by
> > G_Code
> > > or by other way?
> >
> > As far as I know, LinuxCNC's gcode dialect does not allow specification
> > of fully generic arcs.
> >
> > You can get arcs with the normal in the Z direction in G17.  In G18 or
> > G19 you can get arbitrary mixtures of X and Y in the normal by using
> > coordinate system rotation (G10's R value).  But right now you can't get
> > an arc where the normal has a Z component and an XY component.
> >
> > I'm not aware of any current project to change this, but it would not be
> > unwelcome.  One challenge is the gcode syntax: how do you specify the
> > normal to be used?  I think many of the other layers of code are
> > prepared to accept arbitrary arcs, though the preview plots may need
> > additional modification.
> >
> > Jeff
> >
> >
> >
> --
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-09 Thread Jullian 
Thanks for the replies,
Now, it's sure that a generic 3D arc is not supported by g-code。
But in the LinuxCNC'' codes, it has the following code like:
typedef struct {
SphericalArc xyz;
PmCartesian abc;
PmCartesian uvw;
} Arc9;

is not these codes to implement  the generic arbitrary arc??

2015-10-09 21:06 GMT+08:00 Jeff Epler :

> On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
> > Thanks,Jeff,
> > no bug, it's my comprehension fault,
> >
> > What i wonder now is that how the LinuxCNC do a spherical 3D arc by
> G_Code
> > or by other way?
>
> As far as I know, LinuxCNC's gcode dialect does not allow specification
> of fully generic arcs.
>
> You can get arcs with the normal in the Z direction in G17.  In G18 or
> G19 you can get arbitrary mixtures of X and Y in the normal by using
> coordinate system rotation (G10's R value).  But right now you can't get
> an arc where the normal has a Z component and an XY component.
>
> I'm not aware of any current project to change this, but it would not be
> unwelcome.  One challenge is the gcode syntax: how do you specify the
> normal to be used?  I think many of the other layers of code are
> prepared to accept arbitrary arcs, though the preview plots may need
> additional modification.
>
> Jeff
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-09 Thread Brian Morel 
3 points would define the plain as long as they are not co-linear.  If it's
a 180 deg. arc., you lose the ability to define the plain.

-Original Message-
From: andy pugh [mailto:bodge...@gmail.com] 
Sent: Friday, October 09, 2015 9:14 AM
To: EMC developers
Subject: Re: [Emc-developers] normal.z=0.039370

On 9 October 2015 at 14:06, Jeff Epler <jep...@unpythonic.net> wrote:
> I'm not aware of any current project to change this, but it would not 
> be unwelcome.  One challenge is the gcode syntax: how do you specify 
> the normal to be used?  I think many of the other layers of code are 
> prepared to accept arbitrary arcs, though the preview plots may need 
> additional modification.

I _think_ that a start, end, and centre point define no more than two
candidate arcs for any set of three points. If the interpreter always chose
the one with the smallest swept angle then I think that would be
unambiguous.

Having said that, 3D arcs would be something more easily cmputed by CAM, yet
CAM rarely seems to use even 2D arcs.

I had assumed that this was aimed at 3D arcs:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/arbitr
ary-arc
Though it hasn't had much recent attention.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-09 Thread Jeff Epler 
On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
> Thanks,Jeff,
> no bug, it's my comprehension fault,
> 
> What i wonder now is that how the LinuxCNC do a spherical 3D arc by G_Code
> or by other way?

As far as I know, LinuxCNC's gcode dialect does not allow specification
of fully generic arcs.

You can get arcs with the normal in the Z direction in G17.  In G18 or
G19 you can get arbitrary mixtures of X and Y in the normal by using
coordinate system rotation (G10's R value).  But right now you can't get
an arc where the normal has a Z component and an XY component.

I'm not aware of any current project to change this, but it would not be
unwelcome.  One challenge is the gcode syntax: how do you specify the
normal to be used?  I think many of the other layers of code are
prepared to accept arbitrary arcs, though the preview plots may need
additional modification.

Jeff

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-09 Thread EBo 
On Oct 9 2015 7:06 AM, Jeff Epler wrote:
> On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
>> Thanks,Jeff,
>> no bug, it's my comprehension fault,
>>
>> What i wonder now is that how the LinuxCNC do a spherical 3D arc by 
>> G_Code
>> or by other way?
>
> As far as I know, LinuxCNC's gcode dialect does not allow 
> specification
> of fully generic arcs.
>
> You can get arcs with the normal in the Z direction in G17.  In G18 
> or
> G19 you can get arbitrary mixtures of X and Y in the normal by using
> coordinate system rotation (G10's R value).  But right now you can't 
> get
> an arc where the normal has a Z component and an XY component.
>
> I'm not aware of any current project to change this, but it would not 
> be
> unwelcome.  One challenge is the gcode syntax: how do you specify the
> normal to be used?  I think many of the other layers of code are
> prepared to accept arbitrary arcs, though the preview plots may need
> additional modification.

The only way I know to do this is with NURBS.  It would be nice 
capability to have fore sure.

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-09 Thread andy pugh 
On 9 October 2015 at 14:06, Jeff Epler  wrote:
> I'm not aware of any current project to change this, but it would not be
> unwelcome.  One challenge is the gcode syntax: how do you specify the
> normal to be used?  I think many of the other layers of code are
> prepared to accept arbitrary arcs, though the preview plots may need
> additional modification.

I _think_ that a start, end, and centre point define no more than two
candidate arcs for any set of three points. If the interpreter always
chose the one with the smallest swept angle then I think that would be
unambiguous.

Having said that, 3D arcs would be something more easily cmputed by
CAM, yet CAM rarely seems to use even 2D arcs.

I had assumed that this was aimed at 3D arcs:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/arbitrary-arc
Though it hasn't had much recent attention.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-08 Thread Jeff Epler 
If you try an arc in a different plane (e.g., G18 or G19) you will see a
different value for normal.

The specific value 0.039370 occurs because the normal vector is
erroneously treated as a length and converted from mm to in.

If you have encountered a bug that you are trying to fix, can you please
say what the bug is?

Jeff

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

2015-10-08 Thread Jullian 
Thanks,Jeff,
no bug, it's my comprehension fault,

What i wonder now is that how the LinuxCNC do a spherical 3D arc by G_Code
or by other way?



2015-10-08 22:32 GMT+08:00 Jeff Epler :

> If you try an arc in a different plane (e.g., G18 or G19) you will see a
> different value for normal.
>
> The specific value 0.039370 occurs because the normal vector is
> erroneously treated as a length and converted from mm to in.
>
> If you have encountered a bug that you are trying to fix, can you please
> say what the bug is?
>
> Jeff
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers