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

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

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

> > -- > > 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: <561bbb

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

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

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

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

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

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

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

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 >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >>>

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

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

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

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; >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Emc-developers] normal.z=0.039370

Hi, when i do the ' g02 x2 y3 z4 r3' or other similar gcodes, i watch the 'normal' of the arc from TASK to MOTION, the normal always is 'normal.x=0.00 normal.y=0.00 normal.z=0.039370' , and the'normal' dont change at all. why？ Best regards.

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

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

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

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