Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Sunday 21 January 2018 23:18:01 MC Cason via Emc-users wrote:

> Gene,
>
>    It's working for me.  Maybe everyone took a long weekend?
>
Must be, or everyones busy.

> On 01/21/2018 08:40 PM, Gene Heskett wrote:
> > Its Sunday evening, 21:40, 1/21/18, and the last message is the
> > above reply on Thursday. Is the list down?
> >
> >
> > Cheers, Gene Heskett
==
> > The above content, added by Maurice E. Heskett, is Copyright 2018 by
> > Maurice E. Heskett.
==
The amanda mailing list is claiming copyright by CARBONITE INC. So thats 
my way of claiming a prior copyright. And I often forget to delete that 
for other mailing list replies. Unfortunately, kmail cannot use a custom 
sig on a per list basis. Or at least I've not found a way around it.  
Sorry for the noise.

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 

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[MC Cason via Emc-users]

Gene,

  It's working for me.  Maybe everyone took a long weekend?



On 01/21/2018 08:40 PM, Gene Heskett wrote:

Its Sunday evening, 21:40, 1/21/18, and the last message is the above
reply on Thursday. Is the list down?


Cheers, Gene Heskett
The above content, added by Maurice E. Heskett, is Copyright 2018 by
Maurice E. Heskett.



--
MC Cason
Eagle3D - github.com/mcason/Eagle3D
Lathe Electronic Edge Finder - raccoonelectronics.com.



--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Thursday 18 January 2018 20:55:55 Gene Heskett wrote:

> On Thursday 18 January 2018 15:08:58 tom-...@bgp.nu wrote:
> > > On Jan 18, 2018, at 1:04 PM, Gene Heskett 
> > > wrote:
> > >
> > > On Thursday 18 January 2018 10:41:50 Kirk Wallace wrote:
> > >> On 01/17/2018 11:45 AM, tom-...@bgp.nu 
>
> wrote:
> >  On Jan 17, 2018, at 10:43 AM, Kirk Wallace
> >   >  > wrote:
> > 
> >  I did a rewrite a while back:
> > > http://wallacecompany.com/tmp/G76/G76-7b.cc
> > > 
> > >  > > >
> > >
> > > Interesting Kirk.
> > >
> > > However it generates a couple of questions, first of which is that
> > > this looks as if it could be duplicated in a gcode file with the
> > > use of named subroutines. Given the speed of available machinery,
> > > would it make any diff in execution time?
> > >
> > > Second, this seems workable only for std 60 degree sidewall
> > > threads, so it would have to grow a knowledge of acme threads in
> > > order to solve Tom E's problem.
> >
> > Why is his code only good for 60 degree threads?
>
> Probably a good question, but I'd assume it would need a working
> knowledge of the tools cutting edges geometry to use correctly. Q
> would change to something in the 7.48 to 7.502 range in order to
> assure it is cutting only on the flat tool face and the leading edge.
> How much extra would depend on the tools shank flexibility, it it
> bends down from the cutting forces, that may effectively shorten it
> enough to bring the rear edge into play, and that isn't a desirable
> situation. We commonly use less than 30 degrees with a std thread
> shape tool, and it may scrape the back of the groove, which normally
> will just clean up the outer tip of the thread, but it may also grab
> the tool because its cutting on both faces.
>
> After that broken tool at 29 degrees, I haven't used less than 29.75.
> More than 30 makes it clear that side of the tooth, but that tends if
> the tool is getting dull, to leave a finger slicing wire edge on the
> tooth tips.
>
> > > Tom, can you give the math that describes your single point tools
> > > geometry? I think the side angles,(s/b 15 degrees for /most/
> > > acme's) the width of the point those angles pivot on (here I'd
> > > assume the previously quoted .125") which implies the actual width
> > > of your tool, at the 50% of cut depth point is then .0630", the
> > > extra half a thou being just enough backlash to allow a .0625"
> > > width tooth to turn easy if well lubed.
> >
> > The tool geometry is shown here (IAT-1500-8):
> > https://bgp.nu/~tom/pub/IAT-1500-8.png
> >
> > -Tom
>
> And thats enough,since it shows the width of the flat on the tip, the
> rest s/b filling in the blanks.
>
> 2x 0.041 is 0.82" used for the flat, and the pitch of 8=.125 - .082=
> 0.043 for both sides of the tooth, then /2=0.0215" for the total z
> feed by the time you reached full depth of the x at 15 degrees
> included angle. This distance should be divided by the same divisor
> used to get your per pass x feed, and subtracted from the z position
> by moving it inward just before the g33 call as its waiting for the
> index pulse. Poor backlash comp in z can play games at movements this
> small.
> You may want to add moves so that the backlash has already been taken
> up before the g33 call is invoked. not a lot can be safely done in the
> bottom of the hole w/o crashing the back of the tool as you back out
> of the thread getting ready to retrace back out of the hole, so I'd
> check and correct the backlash first, then fiddle with the other
> stuff.
>
> I hope I'm making sense here. :(
>
> [...]
>
> Cheers, Gene Heskett

Its Sunday evening, 21:40, 1/21/18, and the last message is the above 
reply on Thursday. Is the list down?


Cheers, Gene Heskett
The above content, added by Maurice E. Heskett, is Copyright 2018 by 
Maurice E. 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 

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Thursday 18 January 2018 15:08:58 tom-...@bgp.nu wrote:

> > On Jan 18, 2018, at 1:04 PM, Gene Heskett 
> > wrote:
> >
> > On Thursday 18 January 2018 10:41:50 Kirk Wallace wrote:
> >> On 01/17/2018 11:45 AM, tom-...@bgp.nu  
wrote:
>  On Jan 17, 2018, at 10:43 AM, Kirk Wallace
>    > wrote:
> 
>  I did a rewrite a while back:
> > http://wallacecompany.com/tmp/G76/G76-7b.cc
> > 
> >  > >
> >
> > Interesting Kirk.
> >
> > However it generates a couple of questions, first of which is that
> > this looks as if it could be duplicated in a gcode file with the use
> > of named subroutines. Given the speed of available machinery, would
> > it make any diff in execution time?
> >
> > Second, this seems workable only for std 60 degree sidewall threads,
> > so it would have to grow a knowledge of acme threads in order to
> > solve Tom E's problem.
>
> Why is his code only good for 60 degree threads?

Probably a good question, but I'd assume it would need a working 
knowledge of the tools cutting edges geometry to use correctly. Q would 
change to something in the 7.48 to 7.502 range in order to assure it is 
cutting only on the flat tool face and the leading edge. How much extra 
would depend on the tools shank flexibility, it it bends down from the 
cutting forces, that may effectively shorten it enough to bring the rear 
edge into play, and that isn't a desirable situation. We commonly use 
less than 30 degrees with a std thread shape tool, and it may scrape the 
back of the groove, which normally will just clean up the outer tip of 
the thread, but it may also grab the tool because its cutting on both 
faces.

After that broken tool at 29 degrees, I haven't used less than 29.75. 
More than 30 makes it clear that side of the tooth, but that tends if 
the tool is getting dull, to leave a finger slicing wire edge on the 
tooth tips.

> > Tom, can you give the math that describes your single point tools
> > geometry? I think the side angles,(s/b 15 degrees for /most/ acme's)
> > the width of the point those angles pivot on (here I'd assume the
> > previously quoted .125") which implies the actual width of your
> > tool, at the 50% of cut depth point is then .0630", the extra half a
> > thou being just enough backlash to allow a .0625" width tooth to
> > turn easy if well lubed.
>
> The tool geometry is shown here (IAT-1500-8): 
> https://bgp.nu/~tom/pub/IAT-1500-8.png
>
> -Tom

And thats enough,since it shows the width of the flat on the tip, the 
rest s/b filling in the blanks.

2x 0.041 is 0.82" used for the flat, and the pitch of 8=.125 - .082= 
0.043 for both sides of the tooth, then /2=0.0215" for the total z feed 
by the time you reached full depth of the x at 15 degrees included 
angle. This distance should be divided by the same divisor used to get 
your per pass x feed, and subtracted from the z position by moving it 
inward just before the g33 call as its waiting for the index pulse. Poor 
backlash comp in z can play games at movements this small.
You may want to add moves so that the backlash has already been taken up 
before the g33 call is invoked. not a lot can be safely done in the 
bottom of the hole w/o crashing the back of the tool as you back out of 
the thread getting ready to retrace back out of the hole, so I'd check 
and correct the backlash first, then fiddle with the other stuff.

I hope I'm making sense here. :(

[...]

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 

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Kirk Wallace]

On 01/18/2018 12:08 PM, tom-...@bgp.nu wrote:

... snip


Why is his code only good for 60 degree threads?


I think you can use whatever cross slide angle you what. Based on the 
tool link, maybe 29 / 2 = 14.4? You can also play with the depth of cut 
for each pass.



--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[tom-emc]

> On Jan 18, 2018, at 1:04 PM, Gene Heskett  wrote:
> 
> On Thursday 18 January 2018 10:41:50 Kirk Wallace wrote:
> 
>> On 01/17/2018 11:45 AM, tom-...@bgp.nu  wrote:
 On Jan 17, 2018, at 10:43 AM, Kirk Wallace
 mailto:kwall...@wallacecompany.com>> wrote:
 
 I did a rewrite a while back:
> http://wallacecompany.com/tmp/G76/G76-7b.cc 
> 
>  >
> Interesting Kirk.
> 
> However it generates a couple of questions, first of which is that this 
> looks as if it could be duplicated in a gcode file with the use of named 
> subroutines. Given the speed of available machinery, would it make any 
> diff in execution time?
> 
> Second, this seems workable only for std 60 degree sidewall threads, so 
> it would have to grow a knowledge of acme threads in order to solve Tom 
> E's problem.

Why is his code only good for 60 degree threads?

> 
> Tom, can you give the math that describes your single point tools 
> geometry? I think the side angles,(s/b 15 degrees for /most/ acme's) the 
> width of the point those angles pivot on (here I'd assume the previously 
> quoted .125") which implies the actual width of your tool, at the 50% of 
> cut depth point is then .0630", the extra half a thou being just enough 
> backlash to allow a .0625" width tooth to turn easy if well lubed.


The tool geometry is shown here (IAT-1500-8):  
https://bgp.nu/~tom/pub/IAT-1500-8.png

-Tom

> 
> So the angles could pivot at that width point, then what is the actual 
> depth, from which the width of the tools flat tip could be determined?
> 
> I'd assume (that word is scary, actual practice has made a fool of me 
> before) that the tools tooth is actually a few thou longer so that the 
> tool's shank would clear the top of the already cut tooth as its making 
> the final and spring passes.
> 
> Thoughts everybody?

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Thursday 18 January 2018 10:41:50 Kirk Wallace wrote:

> On 01/17/2018 11:45 AM, tom-...@bgp.nu wrote:
> >> On Jan 17, 2018, at 10:43 AM, Kirk Wallace
> >>  wrote:
> >>
> >> I did a rewrite a while back:
> >>> http://wallacecompany.com/tmp/G76/G76-7b.cc
> >>> 
Interesting Kirk.

However it generates a couple of questions, first of which is that this 
looks as if it could be duplicated in a gcode file with the use of named 
subroutines. Given the speed of available machinery, would it make any 
diff in execution time?

Second, this seems workable only for std 60 degree sidewall threads, so 
it would have to grow a knowledge of acme threads in order to solve Tom 
E's problem.

Tom, can you give the math that describes your single point tools 
geometry? I think the side angles,(s/b 15 degrees for /most/ acme's) the 
width of the point those angles pivot on (here I'd assume the previously 
quoted .125") which implies the actual width of your tool, at the 50% of 
cut depth point is then .0630", the extra half a thou being just enough 
backlash to allow a .0625" width tooth to turn easy if well lubed.

So the angles could pivot at that width point, then what is the actual 
depth, from which the width of the tools flat tip could be determined?

I'd assume (that word is scary, actual practice has made a fool of me 
before) that the tools tooth is actually a few thou longer so that the 
tool's shank would clear the top of the already cut tooth as its making 
the final and spring passes.

Thoughts everybody?

> >>> http://wallacecompany.com/tmp/G76/Screenshot-g76_kw-1a.png
> >>> 
> >>
> >> This might not be fully debugged.
> >>
> >> This still has a retract hazard with some end taper settings:
> >>> http://wallacecompany.com/t_tmp/G76_doc/g76_tool_clear.png
> >>> 
> >>
> >> The original drive line shifts with each pass. The direction of I
> >> doesn't match the documentation. This should affect diam/radius
> >> rather than behave like mill space.
> >
> > This is interesting.  In your re-write, is the drive line set by the
> > X position before the first move, or is it related to the I
> > parameter (and how)?  I would like to test this, what is the best
> > way to install it? -Tom
>
> Both the original and my version uses the current entry position as
> the base position. This saves having to have the entry position as
> part of the command. The original has a fixed pattern that shifts with
> each pass. Mine has a fixed drive line and alters the rest of the
> pattern. 'I' sets two features, the tool clearance from the stock, and
> the type of thread -- external or internal. 'I' is applied to the base
> position and tends to be the last parameter to be calculated after the
> rest of the requirements are met. 'I' works for front tool post lathes
> but these days tool posts can commonly be on both sides. A problem
> with my version is that it breaks old g-code, so this would need to be
> addressed. The original G76 was/is a great addition to LinuxCNC but I
> believe it needs refinement.


Cheers, Gene Heskett
The above content, added by Maurice E. Heskett, is Copyright 2018 by 
Maurice E. 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 

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Kirk Wallace]

On 01/18/2018 07:41 AM, Kirk Wallace wrote:

On 01/17/2018 11:45 AM, tom-...@bgp.nu wrote:


... snip


(and how)?  I would like to test this, what is the best way to
install it? -Tom


The G76 section in the interp_convert.cc file needs to be edited and 
recompiled. I use a command that takes care of this, so I've forgotten 
how this works. The LinuxCNC developer manual and documentation should 
provide what you need to modify source code.


I recall that I added a -D parameter to the G76 command so the 
interp_check.cc file needs to be edited too.

http://wallacecompany.com/t_tmp/interp_check.cc


Do a find 'G76' to find the juicy bit in the D parameter section.


--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Kirk Wallace]

On 01/17/2018 11:45 AM, tom-...@bgp.nu wrote:




On Jan 17, 2018, at 10:43 AM, Kirk Wallace
 wrote:



I did a rewrite a while back:

http://wallacecompany.com/tmp/G76/G76-7b.cc

http://wallacecompany.com/tmp/G76/Screenshot-g76_kw-1a.png


This might not be fully debugged.

This still has a retract hazard with some end taper settings:

http://wallacecompany.com/t_tmp/G76_doc/g76_tool_clear.png



The original drive line shifts with each pass. The direction of I
doesn't match the documentation. This should affect diam/radius
rather than behave like mill space.


This is interesting.  In your re-write, is the drive line set by the
X position before the first move, or is it related to the I parameter
(and how)?  I would like to test this, what is the best way to
install it? -Tom


Both the original and my version uses the current entry position as the
base position. This saves having to have the entry position as part of 
the command. The original has a fixed pattern that shifts with each

pass. Mine has a fixed drive line and alters the rest of the pattern.
'I' sets two features, the tool clearance from the stock, and the type 
of thread -- external or internal. 'I' is applied to the base position 
and tends to be the last parameter to be calculated after the rest of 
the requirements are met. 'I' works for front tool post lathes but these 
days tool posts can commonly be on both sides. A problem with my version 
is that it breaks old g-code, so this would need to be addressed. The 
original G76 was/is a great addition to LinuxCNC but I believe it needs 
refinement.


--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[tom-emc]

> On Jan 17, 2018, at 10:43 AM, Kirk Wallace  
> wrote:
>> 
> I did a rewrite a while back:
>> http://wallacecompany.com/tmp/G76/G76-7b.cc 
>> 
>> http://wallacecompany.com/tmp/G76/Screenshot-g76_kw-1a.png 
>> 
> This might not be fully debugged.
> 
> This still has a retract hazard with some end taper settings:
>> http://wallacecompany.com/t_tmp/G76_doc/g76_tool_clear.png 
>> 
> 
> The original drive line shifts with each pass. The direction of I doesn't 
> match the documentation. This should affect diam/radius rather than behave 
> like mill space.

This is interesting.  In your re-write, is the drive line set by the X position 
before the first move, or is it related to the I parameter (and how)?  I would 
like to test this, what is the best way to install it?
-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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Kirk Wallace]

On 01/17/2018 03:47 AM, andy pugh wrote:

On 17 January 2018 at 01:16,  wrote:


It seems like the Drive Line is where the tool should come back to on
every pass.  If it did it would always have clearance (assuming it had
clearance to get in the hole in the first place).  But that is not what is
happening. From the GCode reference of G76:
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76



 I think that only the full-depth retract is on the drive-line and each
other pass has the same retract distance as that last pass.
I imagine that this is to make every retract move exactly the same to
prevent any potential problems in the run-out area.

You should be able to carve your own G76 cycle using a sequence of G33
moves, possibly even as a remap. (G76.1?)


I did a rewrite a while back:

http://wallacecompany.com/tmp/G76/G76-7b.cc
http://wallacecompany.com/tmp/G76/Screenshot-g76_kw-1a.png

This might not be fully debugged.

This still has a retract hazard with some end taper settings:

http://wallacecompany.com/t_tmp/G76_doc/g76_tool_clear.png


The original drive line shifts with each pass. The direction of I 
doesn't match the documentation. This should affect diam/radius rather 
than behave like mill space.



--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Wednesday 17 January 2018 09:56:39 andy pugh wrote:

> On 17 January 2018 at 15:06, Gene Heskett  wrote:
> > Does this enco have enough -x room to cut the thread with the tool
> > mounted as shown in the youtube video?
> >
> > If so, this can be done with the g33.1 if the enco can reverse its
> > spindle fast enough.
>
> No need for G33.1. Ordinary G33 is more suitable.

Probably so Andy, then back to the "driveline" for x before retraction, 
which would be a little easier of the tool, But shouldn't it also have a 
starting point z increment to simulate the Q of a g76? Thread wall is 15 
degrees, and we sure don't want to pinch the tool by cutting on both 
leading and trailing faces. Its a very small advance but eases the force 
of the tool enough to not pinch it in the "kerf" and break it. So I'd 
set up an even loop by dividing the [end cut from the start cut] / 15 or 
perhaps a little more, then setup a z offset to be added per x 
increment, which ack my calculator would be obtained by a 
sin[15]*#<_x_inc>]

call it #<_z_inc> and make z a tmp and adjusting that after the x inc is 
done. I would advance the start, and reduce the end z by the same 
amount, attaining a fixed z stop point.
Sure seems like it should get the job done.

OTOH my coffee hasn't really kicked in yet...

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 

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[andy pugh]

On 17 January 2018 at 15:06, Gene Heskett  wrote:

>
> Does this enco have enough -x room to cut the thread with the tool
> mounted as shown in the youtube video?
>
> If so, this can be done with the g33.1 if the enco can reverse its
> spindle fast enough.
>
>
No need for G33.1. Ordinary G33 is more suitable.

-- 
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
--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Wednesday 17 January 2018 08:06:22 Gene Heskett wrote:

> On Wednesday 17 January 2018 02:42:51 Marcus Bowman wrote:
> > On 16 Jan 2018, at 23:16, tom-...@bgp.nu wrote:
> > > We are tying to cut some internal Acme threads on our lathe.   We
> > > have an internal Acme 8-pitch single point tool.  From the edge of
> > > the backside of tool to the tip of the cutting point is 0.490”. 
> > > The major diameter of our hole to thread is 0.506.  So, you can
> > > see there is very little clearance here.
> > >
> > > When we run G76 the backside of the tool slams into part when it
> > > retracts after the cut.  We are currently cutting (breaking is a
> > > better word) wax until we are confident that something good will
> > > result.
> > >
> > > This causes our tool to crash into the part when it tried to
> > > retract after the cut: G0 Z0.100
> > > G0 X0.248
> > > G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2
> > >
> > > In trying to measure things in the backplot window (not easy to do
> > > accurately) it appears like the tool is moving back nearly the
> > > full thread depth (0.075”).  In this image the distance from where
> > > the tip of the tool is on the first retract line up to the first
> > > cut line which is the lower edge of that white band is about
> > > .075”: https://www.bgp.nu/~tom/pub/IMG_5289.jpg. Considering we
> > > only have ~0.010 this clearly wont work.
> >
> > I have no direct experience of using G76, but this problem reminded
> > me a little of the retraction distance settings on peck drilling
> > canned cycles in a milling machine, where the program response to a
> > retract distance in, say, the G83 command depends on whether there
> > has been a previous G99 (retract to the R value used in the G83) or
> > a G98 (ignore the R and retract to the original Z value used before
> > the G83 was begun.
> >
> > > It seems like the Drive Line is where the tool should come back to
> > > on every pass.  If it did it would always have clearance (assuming
> > > it had clearance to get in the hole in the first place).  But that
> > > is not what is happening. From the GCode reference of G76:
> > > http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76
> >
> > The documentation does say the tool should return to the drive line,
> > but I don't immediately understand the diagram, which shows a
> > different retract after each pass (the same your your own screen
> > shot shows). This is either being done as a result of a previous
> > command like a G99 or G98, or the G76 is not doing what it is
> > supposed to do. I note the connection between G76 and G33, but Gene
> > knows more about G33.
> >
> > > This is youtube video showing the tool hitting the back side on
> > > retraction, twice in fact before the wax snaps off:
> > > http://www.youtube.com/watch?v=yxHFyVMocpU
> > > 
> >
> > Wax is a good idea. Must get some. I sometimes use plastic, but the
> > wax looks even softer.
> >
> > > In typical threading the tool size, thread depth, and initial bore
> > > diameter, are such that this problem may not be noticeable.
> >
> > Often the case, with this kind of problem.
> >
> > > But with an Acme thread where the size of the tool and the depth
> > > of the thread (0.0725 in our case) leaves very little room for
> > > error. So is the G76 code broken or is there something fundamental
> > > we are misunderstanding?
> >
> > This is an important cycle, so it would be good to understand what's
> > happening here.
> >
> > Marcus
>
> The more important point is to get the job done for Tom. But I
> also for some reason had a fixation on the boring head. Put it back in
> the box, its not needed.
>
> Does this enco have enough -x room to cut the thread with the tool
> mounted as shown in the youtube video?
>
> If so, this can be done with the g33.1 if the enco can reverse its
> spindle fast enough.
>
> Write a loop, executing the g33.1, but where one might adjust the z
> for use with a tap, use an increasing - x.
>
> Something like this, after touching off so xz=zero with z at least a
> turn out of the hole, and x centered in the hole.
>
> g7 g20
> S100m3
> g0z0
> g0x0
> #<_bottom_of_hole> = [-0.875 + enco's turnaround distance at 100
> rpms] #<_tmp_x> = 0.000
>
> o100 WHILE [#<_tmp_x> gt -0.07500]
>
> g33.1 z#<_bottom_of_hole> K0.1250
> #<_tmp_x> = [#<_tmp_x> + -0.00250]
> g1 f20 x#<_tmp_x>
>
> o100 ENDWHILE
>
> (now do spring passes)
> #<_tmp_h> = 3
>
> o200 WHILE[#<_tmp_h> ge 0.000]
>
> g33.1 z#<_bottom_of_hole> K0.1250
> #<_tmp_h> = [#<_tmp_h> -1.0]
>
> o200 ENDWHILE
> m5
> m2
>
> Obviously replace #<_bottom of hole> with a legal -z value if the hole
> is not a thru hole.
>
And I just realized that it also needs a small z starting offset as the x 
is advanced, to duplicate the q function of a g76. The advance angle is 
15 degrees so the advance is much less than the 29-30 factor used with a 
g76, the idea is the

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Wednesday 17 January 2018 02:42:51 Marcus Bowman wrote:

> On 16 Jan 2018, at 23:16, tom-...@bgp.nu wrote:
> > We are tying to cut some internal Acme threads on our lathe.   We
> > have an internal Acme 8-pitch single point tool.  From the edge of
> > the backside of tool to the tip of the cutting point is 0.490”.  The
> > major diameter of our hole to thread is 0.506.  So, you can see
> > there is very little clearance here.
> >
> > When we run G76 the backside of the tool slams into part when it
> > retracts after the cut.  We are currently cutting (breaking is a
> > better word) wax until we are confident that something good will
> > result.
> >
> > This causes our tool to crash into the part when it tried to retract
> > after the cut: G0 Z0.100
> > G0 X0.248
> > G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2
> >
> > In trying to measure things in the backplot window (not easy to do
> > accurately) it appears like the tool is moving back nearly the full
> > thread depth (0.075”).  In this image the distance from where the
> > tip of the tool is on the first retract line up to the first cut
> > line which is the lower edge of that white band is about .075”: 
> > https://www.bgp.nu/~tom/pub/IMG_5289.jpg. Considering we only have
> > ~0.010 this clearly wont work.
>
> I have no direct experience of using G76, but this problem reminded me
> a little of the retraction distance settings on peck drilling canned
> cycles in a milling machine, where the program response to a retract
> distance in, say, the G83 command depends on whether there has been a
> previous G99 (retract to the R value used in the G83) or a G98 (ignore
> the R and retract to the original Z value used before the G83 was
> begun.
>
> > It seems like the Drive Line is where the tool should come back to
> > on every pass.  If it did it would always have clearance (assuming
> > it had clearance to get in the hole in the first place).  But that
> > is not what is happening. From the GCode reference of G76: 
> > http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76
>
> The documentation does say the tool should return to the drive line,
> but I don't immediately understand the diagram, which shows a
> different retract after each pass (the same your your own screen shot
> shows). This is either being done as a result of a previous command
> like a G99 or G98, or the G76 is not doing what it is supposed to do.
> I note the connection between G76 and G33, but Gene knows more about
> G33.
>
> > This is youtube video showing the tool hitting the back side on
> > retraction, twice in fact before the wax snaps off: 
> > http://www.youtube.com/watch?v=yxHFyVMocpU
> > 
>
> Wax is a good idea. Must get some. I sometimes use plastic, but the
> wax looks even softer.
>
> > In typical threading the tool size, thread depth, and initial bore
> > diameter, are such that this problem may not be noticeable.
>
> Often the case, with this kind of problem.
>
> > But with an Acme thread where the size of the tool and the depth of
> > the thread (0.0725 in our case) leaves very little room for error. 
> > So is the G76 code broken or is there something fundamental we are
> > misunderstanding?
>
> This is an important cycle, so it would be good to understand what's
> happening here.
>
> Marcus

The more important point is to get the job done for Tom. But I 
also for some reason had a fixation on the boring head. Put it back in 
the box, its not needed.

Does this enco have enough -x room to cut the thread with the tool 
mounted as shown in the youtube video?

If so, this can be done with the g33.1 if the enco can reverse its 
spindle fast enough.

Write a loop, executing the g33.1, but where one might adjust the z for 
use with a tap, use an increasing - x.

Something like this, after touching off so xz=zero with z at least a 
turn out of the hole, and x centered in the hole.

g7 g20
S100m3
g0z0
g0x0
#<_bottom_of_hole> = [-0.875 + enco's turnaround distance at 100 rpms]
#<_tmp_x> = 0.000

o100 WHILE [#<_tmp_x> gt -0.07500]

g33.1 z#<_bottom_of_hole> K0.1250
#<_tmp_x> = [#<_tmp_x> + -0.00250]
g1 f20 x#<_tmp_x>

o100 ENDWHILE

(now do spring passes)
#<_tmp_h> = 3

o200 WHILE[#<_tmp_h> ge 0.000]

g33.1 z#<_bottom_of_hole> K0.1250
#<_tmp_h> = [#<_tmp_h> -1.0]

o200 ENDWHILE
m5
m2

Obviously replace #<_bottom of hole> with a legal -z value if the hole 
is not a thru hole.

Because you do have a wee bit of clearance, you will likely have to
adjust the value on the right of the gt in the first WHILE to get the 
correct thread depth. Cutting wax sounds like a heck of a good idea.

To determine the overshoot, put this in your hal file.
Obviously add the missing loadrt's and addf's to make it work. This is 
straight copy paste from my sheldon, which may have to reverse a 40 lb chuck!

=
# calculate spindle reversal overshoot distances.
setp  sum2.ovrtrv

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[andy pugh]

On 17 January 2018 at 01:16,  wrote:
>
> It seems like the Drive Line is where the tool should come back to on
> every pass.  If it did it would always have clearance (assuming it had
> clearance to get in the hole in the first place).  But that is not what is
> happening. From the GCode reference of G76:
> http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76


 I think that only the full-depth retract is on the drive-line and each
other pass has the same retract distance as that last pass.
I imagine that this is to make every retract move exactly the same to
prevent any potential problems in the run-out area.

You should be able to carve your own G76 cycle using a sequence of G33
moves, possibly even as a remap. (G76.1?)

-- 
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
--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Stuart Stevenson]

You could set the parameters of the G76 to cause it to do one pass.
That would allow you to change the parameters for every pass until you
reach your desired depth.

On Jan 17, 2018 1:43 AM, "Marcus Bowman" <
marcus.bow...@visible.eclipse.co.uk> wrote:


On 16 Jan 2018, at 23:16, tom-...@bgp.nu wrote:

> We are tying to cut some internal Acme threads on our lathe.   We have an
internal Acme 8-pitch single point tool.  From the edge of the backside of
tool to the tip of the cutting point is 0.490”.  The major diameter of our
hole to thread is 0.506.  So, you can see there is very little clearance
here.
>
> When we run G76 the backside of the tool slams into part when it retracts
after the cut.  We are currently cutting (breaking is a better word) wax
until we are confident that something good will result.
>
> This causes our tool to crash into the part when it tried to retract
after the cut:
> G0 Z0.100
> G0 X0.248
> G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2
>
> In trying to measure things in the backplot window (not easy to do
accurately) it appears like the tool is moving back nearly the full thread
depth (0.075”).  In this image the distance from where the tip of the tool
is on the first retract line up to the first cut line which is the lower
edge of that white band is about .075”:  https://www.bgp.nu/~tom/pub/
IMG_5289.jpg. Considering we only have ~0.010 this clearly wont work.
>
I have no direct experience of using G76, but this problem reminded me a
little of the retraction distance settings on peck drilling canned cycles
in a milling machine, where the program response to a retract distance in,
say, the G83 command depends on whether there has been a previous G99
(retract to the R value used in the G83) or a G98 (ignore the R and retract
to the original Z value used before the G83 was begun.

> It seems like the Drive Line is where the tool should come back to on
every pass.  If it did it would always have clearance (assuming it had
clearance to get in the hole in the first place).  But that is not what is
happening. From the GCode reference of G76:  http://linuxcnc.org/docs/html/
gcode/g-code.html#gcode:g76
>
The documentation does say the tool should return to the drive line, but I
don't immediately understand the diagram, which shows a different retract
after each pass (the same your your own screen shot shows). This is either
being done as a result of a previous command like a G99 or G98, or the G76
is not doing what it is supposed to do.
I note the connection between G76 and G33, but Gene knows more about G33.

> This is youtube video showing the tool hitting the back side on
retraction, twice in fact before the wax snaps off:
http://www.youtube.com/watch?v=yxHFyVMocpU 
>
Wax is a good idea. Must get some. I sometimes use plastic, but the wax
looks even softer.

> In typical threading the tool size, thread depth, and initial bore
diameter, are such that this problem may not be noticeable.

Often the case, with this kind of problem.

> But with an Acme thread where the size of the tool and the depth of the
thread (0.0725 in our case) leaves very little room for error.  So is the
G76 code broken or is there something fundamental we are misunderstanding?
>
This is an important cycle, so it would be good to understand what's
happening here.

Marcus
.
> -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-users@lists.sourceforge.net
> 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
Emc-users@lists.sourceforge.net
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Marcus Bowman]

On 16 Jan 2018, at 23:16, tom-...@bgp.nu wrote:

> We are tying to cut some internal Acme threads on our lathe.   We have an 
> internal Acme 8-pitch single point tool.  From the edge of the backside of 
> tool to the tip of the cutting point is 0.490”.  The major diameter of our 
> hole to thread is 0.506.  So, you can see there is very little clearance 
> here.  
> 
> When we run G76 the backside of the tool slams into part when it retracts 
> after the cut.  We are currently cutting (breaking is a better word) wax 
> until we are confident that something good will result.  
> 
> This causes our tool to crash into the part when it tried to retract after 
> the cut:
> G0 Z0.100
> G0 X0.248
> G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2
> 
> In trying to measure things in the backplot window (not easy to do 
> accurately) it appears like the tool is moving back nearly the full thread 
> depth (0.075”).  In this image the distance from where the tip of the tool is 
> on the first retract line up to the first cut line which is the lower edge of 
> that white band is about .075”:  https://www.bgp.nu/~tom/pub/IMG_5289.jpg. 
> Considering we only have ~0.010 this clearly wont work.   
> 
I have no direct experience of using G76, but this problem reminded me a little 
of the retraction distance settings on peck drilling canned cycles in a milling 
machine, where the program response to a retract distance in, say, the G83 
command depends on whether there has been a previous G99 (retract to the R 
value used in the G83) or a G98 (ignore the R and retract to the original Z 
value used before the G83 was begun.
 
> It seems like the Drive Line is where the tool should come back to on every 
> pass.  If it did it would always have clearance (assuming it had clearance to 
> get in the hole in the first place).  But that is not what is happening. From 
> the GCode reference of G76:  
> http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76
> 
The documentation does say the tool should return to the drive line, but I 
don't immediately understand the diagram, which shows a different retract after 
each pass (the same your your own screen shot shows). This is either being done 
as a result of a previous command like a G99 or G98, or the G76 is not doing 
what it is supposed to do.
I note the connection between G76 and G33, but Gene knows more about G33.

> This is youtube video showing the tool hitting the back side on retraction, 
> twice in fact before the wax snaps off:  
> http://www.youtube.com/watch?v=yxHFyVMocpU 
> 
> 
Wax is a good idea. Must get some. I sometimes use plastic, but the wax looks 
even softer.

> In typical threading the tool size, thread depth, and initial bore diameter, 
> are such that this problem may not be noticeable.  

Often the case, with this kind of problem.

> But with an Acme thread where the size of the tool and the depth of the 
> thread (0.0725 in our case) leaves very little room for error.  So is the G76 
> code broken or is there something fundamental we are misunderstanding?
> 
This is an important cycle, so it would be good to understand what's happening 
here.

Marcus
.
> -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-users@lists.sourceforge.net
> 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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Tuesday 16 January 2018 22:48:59 Tom Easterday wrote:

> Well, I hope if G76 is indeed broken it can be fixed?
>
> Acme taps exist but are expensive.  They are usually two stage in
> order to get the depth cut.  We can do rigid tapping on the Emco but
> not sure if we have enough travel for the long tap and not sure we
> have enough torque at lower speeds to pull it off. Acme tap example: 
> (https://www.amazon.com/Alfa-Tools-AT66572-8-8-Acme/dp/B00DYFSH30)
>
Oh...   My...   Gawd...

Which leaves the boring head solution, driven by a G33.1 using the single 
tooth tool you have as the only viable solution.  Is this a commercial 
size whose std measurements are known?  And can you accurately center 
this tool in the hole?

For that, I have a piece of teflon stock with a copper wire inserted in 
it, wired so it can be used with the G38.2 to find the 4 "corners" of 
the hole, and place the centerline of the tools turn axis within .0005" 
or better. Once thats established, swap the probe for the boring head, 
find the dial setting on the head that fits the hole, then run the G33.1 
to adequate depth, but don't forget to subtract the overshoot at the 
bottom of the hole thats used to do the spindle reversal, preventing the 
tool from hitting the bottom of the hole and destroying the tool.

I have code for that which you can add to your hal file, and watch what 
it says in encoder counts with a halmeter, which you will have to 
translate into actual distance traveled. At 10 tpi, and controlling the 
spindle with a vfd whose response is set gently, it can be several turns 
when 1 turn=.1000" of overshoot. My machine has one of Jon pwm-servo 
amps driving the pmdc spindle, and I can do a full reverse from 200 revs 
in about 300 milliseconds. And thats with the turn around being turned 
into a sine-squared profile so the max accel is at zero speed with a 
limit3 between the command from motion, and the input to the pid.

However. the torque to pull the single tooth should be well within the 
enco's torque delivery ability. You'll need a back away move in order to 
have room to get a gage in to check progress as the thread is done. I'd 
also check the x axis backlash so that it always hits the center of the 
hole if the head needs advanced.

If the hole is blind, how will the swarf be cleared? Hand applied air 
between strokes of the g33.1 run would seem to be about as "automatic" 
as I can get on my much simpler machine.

Can you put an air/coolant nozzle to do that in the tool turret? If so, 
write the gcode to bring it to the hole, maybe even into the hole  and 
give it a 1 second hi-pressure shot to clean the hole, then back out of 
the way and stop the spindle for progress checking. Time consuming, and 
I don't want to contemplate doing hundreds without an automatic boreing 
head.

The first such threading operation will be "uncharted" territory, so keep 
notes on the head settings as you progress. That will speed the 2nd and 
subsequent such "tapping" operations.

> > On Jan 16, 2018, at 8:58 PM, Gene Heskett 
> > wrote:
> >
> > I am inclined to agree in that g76 is broken in this regard. My
> > feeling is that it should retract to the drive_line, and no further.
> > I have in most cases managed a work around with the tools I have by
> > jumping in 2 directions, first being from USS threads to SAE, which
> > are marginally less deep, and then to the next bigger bolt if there
> > is room for it.
> >
> > But from previous discussions, it appears your bolt size is fixed.
> > Given that, I only see one workable solution, which is to make, or
> > buy if it can be found, a tap, and use the g33.1, rigid tapping.
> > This requires a keyed to the spindle mounting for the tap, and
> > adequate torque to turn the tap. I have neither but I have gotten
> > away with it by writing a peck tap wrapper, advancing the end point
> > only a small fraction of a turn per pass ever deeper into the hole.
> > When the tap is 8mm and above, its very difficult to get a std er32
> > collet tight enough that the shank won't slip, and I am talking
> > about wrenches 18" long. Ditto the drawbolt of an R-8 collet, with a
> > 3/4" bore to hold a TTS toolholder. The TTS, installed in an R8
> > collet, doesn't offer enough traction unless its that proverbial 1/8
> > turn from broke.
> >
> > I'd call Nook and ask them where they buy the taps for making their
> > nuts. I've made carefull note of how proud they are when the asking
> > for a 1/2" 10 tpi bronze is right at $50/copy the last time I bought
> > 2 of them. Its possible they make their own taps.
> >
> > Humm, useing the tool you have in a small boring head, driven by
> > g33.1 might be workable as that would then back out at the same
> > diameter it went in. Put a spindle shut down to adjust the boring
> > head, and a click to run the next cycle, to the same depth, but a
> > thou or 3 bigger each pass.  A boring head like Andy's would be
> > ideal as its self incrementing for diameter.

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Tom Easterday]

Well, I hope if G76 is indeed broken it can be fixed?

Acme taps exist but are expensive.  They are usually two stage in order to get 
the depth cut.  We can do rigid tapping on the Emco but not sure if we have 
enough travel for the long tap and not sure we have enough torque at lower 
speeds to pull it off.
Acme tap example:  
(https://www.amazon.com/Alfa-Tools-AT66572-8-8-Acme/dp/B00DYFSH30)

> On Jan 16, 2018, at 8:58 PM, Gene Heskett  wrote:
> 
> I am inclined to agree in that g76 is broken in this regard. My feeling 
> is that it should retract to the drive_line, and no further. I have in 
> most cases managed a work around with the tools I have by jumping in 2 
> directions, first being from USS threads to SAE, which are marginally 
> less deep, and then to the next bigger bolt if there is room for it.
> 
> But from previous discussions, it appears your bolt size is fixed. Given 
> that, I only see one workable solution, which is to make, or buy if it 
> can be found, a tap, and use the g33.1, rigid tapping. This requires a 
> keyed to the spindle mounting for the tap, and adequate torque to turn 
> the tap. I have neither but I have gotten away with it by writing a peck 
> tap wrapper, advancing the end point only a small fraction of a turn per 
> pass ever deeper into the hole. When the tap is 8mm and above, its very 
> difficult to get a std er32 collet tight enough that the shank won't 
> slip, and I am talking about wrenches 18" long. Ditto the drawbolt of an 
> R-8 collet, with a 3/4" bore to hold a TTS toolholder. The TTS, 
> installed in an R8 collet, doesn't offer enough traction unless its that 
> proverbial 1/8 turn from broke.
> 
> I'd call Nook and ask them where they buy the taps for making their nuts. 
> I've made carefull note of how proud they are when the asking for a 1/2" 
> 10 tpi bronze is right at $50/copy the last time I bought 2 of them. Its 
> possible they make their own taps.
> 
> Humm, useing the tool you have in a small boring head, driven by g33.1 
> might be workable as that would then back out at the same diameter it 
> went in. Put a spindle shut down to adjust the boring head, and a click 
> to run the next cycle, to the same depth, but a thou or 3 bigger each 
> pass.  A boring head like Andy's would be ideal as its self incrementing 
> for diameter.
> 
> Good luck Tom.
> 
> 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 
> 
> --
> 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-users@lists.sourceforge.net
> 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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[Gene Heskett]

On Tuesday 16 January 2018 18:16:04 tom-...@bgp.nu wrote:

> We are tying to cut some internal Acme threads on our lathe.   We have
> an internal Acme 8-pitch single point tool.  From the edge of the
> backside of tool to the tip of the cutting point is 0.490”.  The major
> diameter of our hole to thread is 0.506.  So, you can see there is
> very little clearance here.
>
> When we run G76 the backside of the tool slams into part when it
> retracts after the cut.  We are currently cutting (breaking is a
> better word) wax until we are confident that something good will
> result.
>
> This causes our tool to crash into the part when it tried to retract
> after the cut: G0 Z0.100
> G0 X0.248
> G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2
>
> In trying to measure things in the backplot window (not easy to do
> accurately) it appears like the tool is moving back nearly the full
> thread depth (0.075”).  In this image the distance from where the tip
> of the tool is on the first retract line up to the first cut line
> which is the lower edge of that white band is about .075”: 
> https://www.bgp.nu/~tom/pub/IMG_5289.jpg. Considering we only have
> ~0.010 this clearly wont work.
>
> It seems like the Drive Line is where the tool should come back to on
> every pass.  If it did it would always have clearance (assuming it had
> clearance to get in the hole in the first place).  But that is not
> what is happening. From the GCode reference of G76: 
> http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76
>
> This is youtube video showing the tool hitting the back side on
> retraction, twice in fact before the wax snaps off: 
> http://www.youtube.com/watch?v=yxHFyVMocpU
> 
>
> In typical threading the tool size, thread depth, and initial bore
> diameter, are such that this problem may not be noticeable.  But with
> an Acme thread where the size of the tool and the depth of the thread
> (0.0725 in our case) leaves very little room for error.  So is the G76
> code broken or is there something fundamental we are misunderstanding?
>
> -Tom

I am inclined to agree in that g76 is broken in this regard. My feeling 
is that it should retract to the drive_line, and no further. I have in 
most cases managed a work around with the tools I have by jumping in 2 
directions, first being from USS threads to SAE, which are marginally 
less deep, and then to the next bigger bolt if there is room for it.

But from previous discussions, it appears your bolt size is fixed. Given 
that, I only see one workable solution, which is to make, or buy if it 
can be found, a tap, and use the g33.1, rigid tapping. This requires a 
keyed to the spindle mounting for the tap, and adequate torque to turn 
the tap. I have neither but I have gotten away with it by writing a peck 
tap wrapper, advancing the end point only a small fraction of a turn per 
pass ever deeper into the hole. When the tap is 8mm and above, its very 
difficult to get a std er32 collet tight enough that the shank won't 
slip, and I am talking about wrenches 18" long. Ditto the drawbolt of an 
R-8 collet, with a 3/4" bore to hold a TTS toolholder. The TTS, 
installed in an R8 collet, doesn't offer enough traction unless its that 
proverbial 1/8 turn from broke.

I'd call Nook and ask them where they buy the taps for making their nuts. 
I've made carefull note of how proud they are when the asking for a 1/2" 
10 tpi bronze is right at $50/copy the last time I bought 2 of them. Its 
possible they make their own taps.

Humm, useing the tool you have in a small boring head, driven by g33.1 
might be workable as that would then back out at the same diameter it 
went in. Put a spindle shut down to adjust the boring head, and a click 
to run the next cycle, to the same depth, but a thou or 3 bigger each 
pass.  A boring head like Andy's would be ideal as its self incrementing 
for diameter.

Good luck Tom.

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 

--
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G76 tool path not behaving as expected (bad code or bad expectations?)

[tom-emc]

We are tying to cut some internal Acme threads on our lathe.   We have an 
internal Acme 8-pitch single point tool.  From the edge of the backside of tool 
to the tip of the cutting point is 0.490”.  The major diameter of our hole to 
thread is 0.506.  So, you can see there is very little clearance here.  

When we run G76 the backside of the tool slams into part when it retracts after 
the cut.  We are currently cutting (breaking is a better word) wax until we are 
confident that something good will result.  

This causes our tool to crash into the part when it tried to retract after the 
cut:
G0 Z0.100
G0 X0.248
G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2

In trying to measure things in the backplot window (not easy to do accurately) 
it appears like the tool is moving back nearly the full thread depth (0.075”).  
In this image the distance from where the tip of the tool is on the first 
retract line up to the first cut line which is the lower edge of that white 
band is about .075”:  https://www.bgp.nu/~tom/pub/IMG_5289.jpg. Considering we 
only have ~0.010 this clearly wont work.   

It seems like the Drive Line is where the tool should come back to on every 
pass.  If it did it would always have clearance (assuming it had clearance to 
get in the hole in the first place).  But that is not what is happening. From 
the GCode reference of G76:  
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76

This is youtube video showing the tool hitting the back side on retraction, 
twice in fact before the wax snaps off:  
http://www.youtube.com/watch?v=yxHFyVMocpU 


In typical threading the tool size, thread depth, and initial bore diameter, 
are such that this problem may not be noticeable.  But with an Acme thread 
where the size of the tool and the depth of the thread (0.0725 in our case) 
leaves very little room for error.  So is the G76 code broken or is there 
something fundamental we are misunderstanding?

-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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Gene Heskett]

On Thursday 22 May 2014 19:14:52 Gregg Eshelman did opine
And Gene did reply:
> On 5/22/2014 6:20 AM, Gene Heskett wrote:
> > Cutting off is a PIMA on this piece of rubber, and I finally wrote a
> > routine that will work for one cutoff per cutoff blade sharpening. 
> > It goes inward about .2mm then pulls back before it can dig in and
> > lock things up, then moves .5mm sideways and repeats back and forth,
> > preventing the blade from being pinched in the groove, till it
> > finally parts off. Then I have to remove about 3mm of the end to get
> > back to a full width tool.
> 
> What kind of cheap tool are you parting with, or what metal are you
> cutting that makes such a mess of the tool?

Some sort of a 1/16" wide, tapered from top to bottom tool steel sold as 
"cutoff" blade. I have 2 of them, bought from 2 different sources (LMS & 
Grizzly) about a year apart.  Seem to be approximately equal.

Much of my stock steel came from a recycling yard, the majority of the rod 
up to say 2" they carry is worn mine shafting. Exact alloy UNK, but I'd 
guess it starts with 4340 and gets uglier from there, rapidly.  Its tough 
stuff all the way to the core.  But for smaller stuff, hot or cold roll 
from TSC's bin, cuts easier, but that doesn't seem to help the rubber 
toolpost problem when doing a cut off.

Thanks Gregg.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Gregg Eshelman]

On 5/22/2014 6:20 AM, Gene Heskett wrote:

> Cutting off is a PIMA on this piece of rubber, and I finally wrote a
> routine that will work for one cutoff per cutoff blade sharpening.  It
> goes inward about .2mm then pulls back before it can dig in and lock
> things up, then moves .5mm sideways and repeats back and forth, preventing
> the blade from being pinched in the groove, till it finally parts off.
> Then I have to remove about 3mm of the end to get back to a full width
> tool.

What kind of cheap tool are you parting with, or what metal are you 
cutting that makes such a mess of the tool?


---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Steve Blackmore]

On Thu, 22 May 2014 08:20:45 -0400, you wrote:


>> However - I don't use home in LinuxCNC, it's not lathe friendly -
>
>I don't find it all that helpful for other than reestablishing positions 
>after a forced shut down in the middle of a job, chip broke, whatever.

I don't even find that much use - On the odd occasion it's been required
I just use the end of the work for Z and measure the diameter. If I've
already faced the end, even better. I can work out where I am from
there.

>> I have no homing set in ini. Limit switches are enabled though. I simply
>> zero on the end of the work. Just have to remember to leave enough
>> stuck out the chuck so the tool don't hit it on external
>> turning/threading and parting off.
>
>I have done that too, with a touch off, or occasionally, when the piece 
>has been cut off, clean up the nipple on the end and slide the workpiece 
>up to the zeroed tool for the next piece.

My tool 1 is my reference tool with 0,0 offsets. All others have offsets
compared to that, so once I got it right it just a matter of moving tool
1 to Z0 and making stock touch it.

>Cutting off is a PIMA on this piece of rubber, and I finally wrote a 
>routine that will work for one cutoff per cutoff blade sharpening.  It 
>goes inward about .2mm then pulls back before it can dig in and lock 
>things up, then moves .5mm sideways and repeats back and forth, preventing 
>the blade from being pinched in the groove, till it finally parts off.  
>Then I have to remove about 3mm of the end to get back to a full width 
>tool.

I often use a rear part off tool inverted. It forces the saddle down at
the back and seems to work better for me on tougher type materials. On
larger diameter stock two inch or more I do alternate cuts to widen
also. I use an insert type that curls the swarf into tight watch springs
and they usually clear easily. I have had one memorable jam up, work
came loose in chuck, the end of the holder (blade type) shattered and
fired shrapnel all over, one piece hit me on the forehead - small cut,
but deep - had to resort to salt to stop it bleeding :) Since then I
have ALWAYS wore safety glasses.

Steve Blackmore
--

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Gene Heskett]

On Thursday 22 May 2014 03:25:24 Steve Blackmore did opine
And Gene did reply:
> On Wed, 21 May 2014 08:31:19 -0400, you wrote:
> >Since lcnc has no clue about the ballistics of the reverse, and
> >therefore cannot predict the over travel, I'm not sure there can be a
> >fix for that other than setting the -limit well into the chuck.
> 
> My neg working units limit is often well into the spindle - cant
> bore/drill etc inside the chuck otherwise. I have a moveable limit
> switch on the spindle end of the bed and a home/limit switch on the
> base of the tailstock where the saddle hits it.

My tailstock isn't even mounted unless I am center drilling something.  
But that would be a neat trick I should remember. :)  But the home switch 
is under the rear edge of the bed, rigged so the back gib depresses it. 
Not portable, but also out of swarf's way so far.
 
> However - I don't use home in LinuxCNC, it's not lathe friendly -

I don't find it all that helpful for other than reestablishing positions 
after a forced shut down in the middle of a job, chip broke, whatever.
 
> I have no homing set in ini. Limit switches are enabled though. I simply
> zero on the end of the work. Just have to remember to leave enough
> stuck out the chuck so the tool don't hit it on external
> turning/threading and parting off.

I have done that too, with a touch off, or occasionally, when the piece 
has been cut off, clean up the nipple on the end and slide the workpiece 
up to the zeroed tool for the next piece.

Cutting off is a PIMA on this piece of rubber, and I finally wrote a 
routine that will work for one cutoff per cutoff blade sharpening.  It 
goes inward about .2mm then pulls back before it can dig in and lock 
things up, then moves .5mm sideways and repeats back and forth, preventing 
the blade from being pinched in the groove, till it finally parts off.  
Then I have to remove about 3mm of the end to get back to a full width 
tool.

> The end of the stock is my master datum point Z0. Everything else
> relies on that. CAM sorts out the tool change position for each tool
> and the start/finish "at rest" position. My tool table in CAM is set
> up. It's all zero's in LinuxCNC.
> 
> CAM knows the shape, working length and overhang for each tool. (plus
> lots of other params) and works out tool paths using all these
> parameters. Frightens me at times when the tool misses the end of the
> job by tiny amounts - I have it set to adjust them as work
> diameter/length changes during the job if I am making a lot of parts -
> saves time.

No CAM here other than pcb2gcode for circuit boards which are done on the 
mill.

So I'm stuck writing my own gcode.  Obviously single operation loops, 
rarely more than 40 LOC.  CAM's aren't great at that anyway.

> Steve Blackmore
> --
> 
> ---
> --- "Accelerate Dev Cycles with Automated Cross-Browser Testing -
> For FREE Instantly run your Selenium tests across 300+ browser/OS
> combos. Get unparalleled scalability from the best Selenium testing
> platform available Simple to use. Nothing to install. Get started now
> for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> 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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Steve Blackmore]

On Wed, 21 May 2014 08:31:19 -0400, you wrote:


>Since lcnc has no clue about the ballistics of the reverse, and therefore 
>cannot predict the over travel, I'm not sure there can be a fix for that 
>other than setting the -limit well into the chuck.

My neg working units limit is often well into the spindle - cant
bore/drill etc inside the chuck otherwise. I have a moveable limit
switch on the spindle end of the bed and a home/limit switch on the base
of the tailstock where the saddle hits it.

However - I don't use home in LinuxCNC, it's not lathe friendly - I have
no homing set in ini. Limit switches are enabled though. I simply zero
on the end of the work. Just have to remember to leave enough stuck out
the chuck so the tool don't hit it on external turning/threading and
parting off.

The end of the stock is my master datum point Z0. Everything else relies
on that. CAM sorts out the tool change position for each tool and the
start/finish "at rest" position. My tool table in CAM is set up. It's
all zero's in LinuxCNC. 

CAM knows the shape, working length and overhang for each tool. (plus
lots of other params) and works out tool paths using all these
parameters. Frightens me at times when the tool misses the end of the
job by tiny amounts - I have it set to adjust them as work
diameter/length changes during the job if I am making a lot of parts -
saves time.

Steve Blackmore
--

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Gene Heskett]

On Wednesday 21 May 2014 10:30:44 Kirk Wallace did opine
And Gene did reply:
> On 05/21/2014 05:07 AM, Gene Heskett wrote:
> ...
> 
> > raising the squeak to several kilohertz.  So most of my threads are
> > 40 to 50 pass, 5 to 10 minutes runtime affairs, to get a decent
> > looking thread.
> 
> For a thread of that size (19,5 mm), make J about one quarter to one
> third of K, maybe even half in aluminum. One needs to take off enough
> material to get the tool below the surface. This should give five to
> three passes before any spring passes which I would not bother doing.
> Otherwise, I'd use a tool post grinder with many passes.

No doubt good advice Kirk, but the flex in the tool bends it down to where 
the cut depth is controlled by the clearance below the cutting edge which 
I purposely leave very little of.  Then it decides to cut and springs 
back.  That of course leaves a very poor quality thread, with crap 
sticking out you can paper cut yourself with.  Sometimes I can reduce the 
singing by a quick resharpening of the tool. But its likely going to come 
back as soon as its making chips.  This isn't helped in the present setup 
as the jaws are turned around, which forces me to extend the compound such 
that there is no saddle support under the cutting tip.  I normally  keep 
it pulled back far enough so the downforce from the cut is back of the 
front edge of the saddle. 

I think today that I will uncouple the apron (the same 2 screws that held 
the original apron) and pull it toward the headstock to gain access to the 
bit of steel they optimistically call a gib, and see if I can tighten it a 
degree or so to take up the play at the back of the saddle.  Its super 
ultra critical as there isn't a lot of weight on the v-way. It would have 
helped if I had made the new apron to carry that ballnut out of steel.  
The weight would I think help since the motor, a 425 oz, is hanging off 
the rear of the crossfeed.  Lots more weight on the back, flat of the bed 
than on the v-way.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Kirk Wallace]

On 05/21/2014 05:07 AM, Gene Heskett wrote:
...
> raising the squeak to several kilohertz.  So most of my threads are 40 to
> 50 pass, 5 to 10 minutes runtime affairs, to get a decent looking thread.

For a thread of that size (19,5 mm), make J about one quarter to one 
third of K, maybe even half in aluminum. One needs to take off enough 
material to get the tool below the surface. This should give five to 
three passes before any spring passes which I would not bother doing. 
Otherwise, I'd use a tool post grinder with many passes.


-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Gene Heskett]

On Wednesday 21 May 2014 03:13:10 Steve Blackmore did opine
And Gene did reply:
> On Tue, 20 May 2014 23:39:28 -0400, you wrote:
> >Greetings docs maintainers;
> >
> >I expect those interactions were expected to be self-evident by the
> >guru's, but from the docs, its not all that well explained.
> 
> Hi Gene - I've never used the G76 in Linuxcnc but it certainly looks
> different to the Mach version. Never really used that either apart from
> testing. I prefer using G33 (G32 in Mach). I do use CAM so it's easy
> for me to control it more precisely and not rely on how somebody else
> thinks it should be done.
> 
> Steve Blackmore
> --

I just the other day, used G33 in a g76 like cycle to make the tapered 
thread and nut that grabs the X screw, which looks like its going to work 
well, with no glue needed.  And now that I have synthesized a stop till 
stopped on a direction change in my record setting, longest ever .hal 
file, I can also use g33.1 for rigid tapping.

But there is a potential broken tap gotcha! If in the slowdown & stop 
phase, Z (following in sync with the spindle), passes the -limit setup in 
the .ini, Z stops instantly while the chuck is still coasting to a stop, 
and then picks it back up as it comes back past the limit in the reversing 
move. I haven't broken a tap, but as I've reported before, I have seen it 
do it while cutting air quite a few times.

Since lcnc has no clue about the ballistics of the reverse, and therefore 
cannot predict the over travel, I'm not sure there can be a fix for that 
other than setting the -limit well into the chuck.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Gene Heskett]

On Wednesday 21 May 2014 01:59:34 Kirk Wallace did opine
And Gene did reply:
> On 05/20/2014 08:39 PM, Gene Heskett wrote:
> > Greetings docs maintainers;
> > 
> > I found this after noon that there is a large interaction between the
> > driveline value, and the J and K values.
> 
> My understanding from studying the G76 source is that the J value is
> intended to be depth of cut for the first pass. But the first pass is
> based on I, and I is based on the drive line location, which is based
> on the initial tool location just before G76 is invoked. I is intended
> to be the tool clearance, or space between the initial tool position
> and the surface of the workpiece. This assumes that the workpiece has
> already been turned down to the thread's major diameter in the case of
> an external thread. The position the tool is in is sort of a data
> input defining one end of the drive line and therefore the thread
> diameters and thread length. So if you find the major diameter of the
> thread in question and add I, that will be the X value the tool needs
> to be in before starting G76. Also note that I, J and K follow the
> setting of the G7 diameter or G8 radius mode. Figure out the distance
> you want for the tool clearance, for G7 enter it for I, for G8 double
> it and enter for I. The same goes for J and K, even though none of
> theses values correspond to any real diameters. If you happen to set J
> equal to K, G76 should take one cut with a depth of cut equal to J,
> except I believe setting J equal to K will throw an error so make K
> just a tiny bit bigger.
> 
> After G76 cuts J, the next depth of cut is J multiplied with a
> digression factor which makes the depth of cut smaller for each pass.
> Passes are run until just before reaching K. At this point K is used
> for the final pass and any spring passes. So the last pass ends up at
> the initial tool position, plus I and K. R sets the behavior of the
> digression factor, with 2 giving the chip produced on each pass the
> same cross sectional area, or close to the same chip load. Which is
> not the same as equal depth of cut in this case.
> 
> The number of passes needed will depend on J, and the rate of
> digression (R) on J. The source code looks like this:
> 
> depth = full_dia_depth + cut_increment * pow(++pass, 1.0/digression);
> 
> Making J as large as you can really reduces the number of passes.
> Changing the value of I should not have any affect on the number of
> passes.

I think that is all assuming a stiff tool and a stiff machine.  In this 
case I am boring threads about 19.5mm in diameter, using a rubber machine 
and a rubber boring bar, so its almost a necessity that I am working with 
cutting forces that aren't much more than scraping, with a thread shaped 
tool.  And using an advance angle of 30.1 degrees. 30 and under chatters 
to beat hell, and even this needs a pair of vice grips on the tool shank, 
raising the squeak to several kilohertz.  So most of my threads are 40 to 
50 pass, 5 to 10 minutes runtime affairs, to get a decent looking thread.

My mill is laid up, the table is out at a local machine shop, getting 
about 90 thou deeper a screw clearance groove in the bottom, making room 
for a nut holder that might be 21.5mm tall when I am finished with it.  
Present clearance for the factory nut is around 19.15mm, these ball nuts 
are 19.07mm, and it needs enough steel wrapped around it to maintain the 
integrity.  I will have to put the mill back together long enough to carve 
a small pocket on one side for the ball return tube.  That will destroy 
about 9mm of the threads I just cut yesterday, and will require that once 
the ball nut retainer disk has been screwed in and torqued up against the 
felt, a dollop of loctite's Goop to seal out the dirt where the threads 
are missing.

There is room in the depth of this pocket of this nut holder for a disk 
cut from one of my old Woolrich western hats, with a 1/4" center hole, 
forced over the screw on each side of the nut, that will serve as a swarf 
cleaner and lubricating wiper, with the lube being fed in by some weed 
eater fuel line hooked to a small manifold with a flip top oil cover, with 
an elevation above the nuts of perhaps 4".  Same felt wiper idea is 
already done for the Y screw but it hasn't been cut to length yet.

As there are no home/limit switches on the mill, I need to survey its .hal 
file and see if I left a pin for shared limits, because I need to figure 
out a means of absolute shutdown in order to stop it from unscrewing 
itself from the nut, treating them as a limit switch I can move away from 
if its tripped.  As its setup 4 axis plus probe, + pwm & reverse for the 
spindle, (thats 10 outputs) I'm not entirely sure I have any port pins 
left.  Seems like I ought to be able to lay the flat spring lever of a 
microswitch alongside the screw and detect when the end of it is within 
about 3mm of the nut holder.

Anybody have a better idea for limit switch locat

Re: [Emc-users] G76 docs need a better explanation

[Steve Blackmore]

On Tue, 20 May 2014 23:39:28 -0400, you wrote:

>Greetings docs maintainers;

>I expect those interactions were expected to be self-evident by the 
>guru's, but from the docs, its not all that well explained.

Hi Gene - I've never used the G76 in Linuxcnc but it certainly looks
different to the Mach version. Never really used that either apart from
testing. I prefer using G33 (G32 in Mach). I do use CAM so it's easy for
me to control it more precisely and not rely on how somebody else thinks
it should be done.

Steve Blackmore
--

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 docs need a better explanation

[Kirk Wallace]

On 05/20/2014 08:39 PM, Gene Heskett wrote:
> Greetings docs maintainers;
>
> I found this after noon that there is a large interaction between the
> driveline value, and the J and K values.

My understanding from studying the G76 source is that the J value is 
intended to be depth of cut for the first pass. But the first pass is 
based on I, and I is based on the drive line location, which is based on 
the initial tool location just before G76 is invoked. I is intended to 
be the tool clearance, or space between the initial tool position and 
the surface of the workpiece. This assumes that the workpiece has 
already been turned down to the thread's major diameter in the case of 
an external thread. The position the tool is in is sort of a data input 
defining one end of the drive line and therefore the thread diameters 
and thread length. So if you find the major diameter of the thread in 
question and add I, that will be the X value the tool needs to be in 
before starting G76. Also note that I, J and K follow the setting of the 
G7 diameter or G8 radius mode. Figure out the distance you want for the 
tool clearance, for G7 enter it for I, for G8 double it and enter for I. 
The same goes for J and K, even though none of theses values correspond 
to any real diameters. If you happen to set J equal to K, G76 should 
take one cut with a depth of cut equal to J, except I believe setting J 
equal to K will throw an error so make K just a tiny bit bigger.

After G76 cuts J, the next depth of cut is J multiplied with a 
degression factor which makes the depth of cut smaller for each pass. 
Passes are run until just before reaching K. At this point K is used for 
the final pass and any spring passes. So the last pass ends up at the 
initial tool position, plus I and K. R sets the behavior of the 
degression factor, with 2 giving the chip produced on each pass the same 
cross sectional area, or close to the same chip load. Which is not the 
same as equal depth of cut in this case.

The number of passes needed will depend on J, and the rate of degression 
(R) on J. The source code looks like this:

depth = full_dia_depth + cut_increment * pow(++pass, 1.0/degression);

Making J as large as you can really reduces the number of passes. 
Changing the value of I should not have any affect on the number of passes.

-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G76 docs need a better explanation

[Gene Heskett]

Greetings docs maintainers;

I found this after noon that there is a large interaction between the 
driveline value, and the J and K values.

I believe it should be pointed out that all 3 interact. I made some mods 
to my wrapper script a few days ago that resulted in only 3 passes to cut 
the complete thread because I had set the driveline too far away.

So today I set it (driveline) a lot closer to shaving the teeth of the 
thread on the final backstroke, then set J for about 1/3rd the initial 
depth, leaving K=2.97, by which I was trying to get more passes and a 
cleaner thread in the previous usage last week.

It would have taken that version nearly 3 hours to run as the advance was 
only about .0025mm per pass.  And this was for a 32 tpi thread!

So it would seem that it needs a better explanation, in that driveline 
needs to be only far enough away that it still clears the cut thread while 
retracing on the spring strokes.  And that J, which sets the initial cut 
depth, is also the value of subsequent cuts, reduced to finer in the 
ending passes by the setting of K.

I expect those interactions were expected to be self-evident by the 
guru's, but from the docs, its not all that well explained.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76?

[Gene Heskett]

On Sunday 20 January 2013 18:45:33 Dave Caroline did opine:
Message additions Copyright Sunday 20 January 2013 by Gene Heskett

> On Sun, Jan 20, 2013 at 2:49 AM, Gene Heskett  wrote:
> > Greetings all;
> > 
> > Has anyone cut any threads with g76 lately?
> 
> yes and I checked the change log looking for updates to see if any
> changes were made

Dave, call the St. Bernard's back in, I found it.  Turns out that when I 
was trying to make the encoder wheel out of alu, I was using a 1/16" mill 
and 39 slots was all I could get to fit. That figure got welded into my 
brain because I only made about 10 of them.  But when I gave up on that 
after having obtained some smaller mills for pcb's, and made the last one 
out of brass, I had changed the number of cycles in that code to 50 because 
I now had a narrower slot.  And just promptly forgot it.  That faint 
banging from the general direction of north central WV?  Me, beating head 
on shop door.  I think (I hope anyway) it will feel good when I stop.

So go cut a switch & give me fifty virtual lashes for wasting your time.

Now I need to figure out a way to hit the home switch with x, and get the 
same radius cut regardless of the tool, since I am in fact measuring the 
mounted tool.  And I seem to be getting about a .020" offset between the 
two tools I have checked so far.

Oh, and I'll need wade thru the .hal file and recalibrate the spindle 
tachometer display.  Minor detail.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

Why was I born with such contemporaries?
-- Oscar Wilde
I was taught to respect my elders, but its getting 
harder and harder to find any...

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76?

[Gene Heskett]

On Sunday 20 January 2013 12:36:58 John Prentice (FS) did opine:
Message additions Copyright Sunday 20 January 2013 by Gene Heskett

> Gene, greetings
> 
> -Original Message-
> From: Gene Heskett [mailto:ghesk...@wdtv.com]
> Sent: 20 January 2013 05:30
> 
> > Has anyone cut any threads with g76 lately?
> > 
> > I fired off a routine that 4 months back worked great, carving a
> > 1/4-28 thread for me several times last fall.  Tonight, without any
> > changes in the .hal file that would affect threading ops, still set to
> > make a
> > 1/4-28 SAE thread, and it came out at about 24 tpi.  And I haven't a
> > clue.  My encoder still has 39 slots. Etc, etc.  I am on the bleeding
> > edge development branch.
> 
> This is a stab in the dark. I have been bitten with coarse pitch threads
> caused by the Z ais not being capable of meeting the required rate for
> the pitch and spindle RPM. I had an error in VFD scaling and spindle
> was running a lot faster than I commanded.
> 
> It is a pita that LCNC does not complain about the "impossible" motion
> but just limits on the set Z max-vel.
> 
> John Prentice
> 
No chance John. 39ipm capable z, 28 tpi, 100 rpm, but it will do the same 
at 750 revs or more, but slid to the left half a thread at 750 revs.
In fact, 100 revs is too slow, the tool doesn't cut as clean.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

An aphorism is never exactly true; it is either a half-truth or
one-and-a-half truths.
-- Karl Kraus
I was taught to respect my elders, but its getting 
harder and harder to find any...

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76?

[Gene Heskett]

On Sunday 20 January 2013 11:28:00 Dave Caroline did opine:
Message additions Copyright Sunday 20 January 2013 by Gene Heskett

> On Sun, Jan 20, 2013 at 2:49 AM, Gene Heskett  wrote:
> > Greetings all;
> > 
> > Has anyone cut any threads with g76 lately?
> 
> yes and I checked the change log looking for updates to see if any
> changes were made
> 
> > I fired off a routine that 4 months back worked great, carving a
> > 1/4-28 thread for me several times last fall.  Tonight, without any
> > changes in the .hal file that would affect threading ops, still set
> > to make a 1/4-28 SAE thread, and it came out at about 24 tpi.  And I
> > haven't a clue.  My encoder still has 39 slots. Etc, etc.  I am on
> > the bleeding edge development branch.
> > 
> > If someone could go cut a thread with this 2.6 code and check it for
> > true tpi, it might help me find whatever dumb effect I've put into
> > this in my spindle servo tuning.
> > 
> > Thanks folks.
> > 
> > --
> > Cheers, Gene
> > --
> 
> I believe the docs need updating to show some problems inherent in the
> code

I'd agree, but what I've found sure wasn't the show stopper this is.
 
> The acceleration and deceleration time is not mentioned in the docs
> and also does it fire off an error
> if the acceleration and deceleration is programmed IN your desired
> thread drive line
> also if you set your spindle at a speed where your Z needs to run at
> or above its maximum velocity no error is given

Already noted.

I've not seen an error of that nature, and in any event, the spindle speed 
in this example code, 100 rpm, is well below any accel/maxvel limits.  I 
have run that same code at 750 rpms & the only thing that seemed to change 
was the left/right registration of the cut thread, it slides to the left as 
the rpms go up because the actual sync point is late, internally delayed 
from the index pulse by the accel time from a dead stop. X accel's for the 
leadout cut were at one time chosen to be about 1/2 turn of the spindle but 
the spindle was turning about 400 revs when I did that calc.

At 100 revs, z has probably a 10x or more headroom, it can run 39 ipm 
steady state.  Current settings are:

[TRAJ]
DEFAULT_VELOCITY = 0.250
MAX_LINEAR_VELOCITY = 0.65

[X axis]:
MAX_VELOCITY = 0.60
MAX_ACCELERATION = 5.50
STEPGEN_MAXACCEL = 11.00

[Z axis:]
MAX_VELOCITY = 0.3765
MAX_ACCELERATION = 3.00
STEPGEN_MAXACCEL = 6.00

Z is slower, its a 2/1 geardown to the screw, both motors are 430 triple 
stacks, x is 8 wire series, z is 8 wire parallel wired, amp wide open to 
get better accel's.  Screw is 16tpi, but will eventually be a 16mmx5mm, its 
on a boat by now I hope.  I probably won't change the gearing as creep 
speeds now aren't even worth calling a surveyer to set stake & measure it 
later...  And it is geared, not belted, using the old 'change gears' gears.

> I believe to get good threads with the current code run more slowly
> and have a good entry and exit time

That code I posted has a start point at +.200" from the start of the thread 
itself, lots of time to steady the motion.
 
> There is also a strange path seen when making a left hand thread with
> an entry taper

Not tried yet. :)

> I do a tool change, the next move is to the start point, except it
> seems to have two parts to the move, the first going to the drive line
> rather than the taper start.

Thats correct.

With separate homing operations in my setup, I did the x home to that gage 
when I switched to the single tooth, a cutoff tool blade suitably 
sharpened, and it appears I need to fine tune the code, the thread is about 
-0.015" undersized, but thats my problem because that code never before had 
a known home setting to work from, the tpi it cut is the real problem.

In fact, the next thing I did after seeing that was to put a 1.050" travel 
dial indicator on the carriage to see if a 1.000" move was actually 1.000", 
and it was.

I haven't figured out a way to home the Z with that tool as the broad side 
of the tool holder would hit the Z side of gage first.  I should make some 
measurements of the offset & put it in the tool table, but haven't gotten 
to that point just yet.  One thing at a time lest I overload my now ancient 
wet ram. :)

> Your question has made me say something before I did a bug report.
> 
> 
> Dave Caroline
> 
Thanks for looking at this Dave.

Thinking out loud, would it be possible to include the ChangeLog in the 
package I get 2-4x a week from the buildbot?  That would tend to give us 
enough we might even be able to point a bit more specifically when a 
problem pops up.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

I bought some used paint. It was in the shape of a house.
-- Steven Wright
I was taug

Re: [Emc-users] G76?

[John Prentice (FS)]

Gene, greetings

-Original Message-
From: Gene Heskett [mailto:ghesk...@wdtv.com] 
Sent: 20 January 2013 05:30

> 
> Has anyone cut any threads with g76 lately?
> 
> I fired off a routine that 4 months back worked great, carving a 
> 1/4-28 thread for me several times last fall.  Tonight, without any 
> changes in the .hal file that would affect threading ops, still set to 
> make a
> 1/4-28 SAE thread, and it came out at about 24 tpi.  And I haven't a 
> clue.  My encoder still has 39 slots. Etc, etc.  I am on the bleeding 
> edge development branch.

This is a stab in the dark. I have been bitten with coarse pitch threads
caused by the Z ais not being capable of meeting the required rate for the
pitch and spindle RPM. I had an error in VFD scaling and spindle was running
a lot faster than I commanded.

It is a pita that LCNC does not complain about the "impossible" motion but
just limits on the set Z max-vel.

John Prentice


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76?

[Dave Caroline]

On Sun, Jan 20, 2013 at 2:49 AM, Gene Heskett  wrote:
> Greetings all;
>
> Has anyone cut any threads with g76 lately?

yes and I checked the change log looking for updates to see if any
changes were made

>
> I fired off a routine that 4 months back worked great, carving a 1/4-28
> thread for me several times last fall.  Tonight, without any changes in the
> .hal file that would affect threading ops, still set to make a 1/4-28 SAE
> thread, and it came out at about 24 tpi.  And I haven't a clue.  My encoder
> still has 39 slots. Etc, etc.  I am on the bleeding edge development
> branch.
>
> If someone could go cut a thread with this 2.6 code and check it for true
> tpi, it might help me find whatever dumb effect I've put into this in my
> spindle servo tuning.
>
> Thanks folks.
>
> --
> Cheers, Gene
> --

I believe the docs need updating to show some problems inherent in the code

The acceleration and deceleration time is not mentioned in the docs
and also does it fire off an error
if the acceleration and deceleration is programmed IN your desired
thread drive line
also if you set your spindle at a speed where your Z needs to run at
or above its maximum velocity no error is given

I believe to get good threads with the current code run more slowly
and have a good entry and exit time

There is also a strange path seen when making a left hand thread with
an entry taper
I do a tool change, the next move is to the start point, except it
seems to have two parts to the move, the first going to the drive line
rather than the taper start.

Your question has made me say something before I did a bug report.


Dave Caroline

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76?

[Gene Heskett]

On Sunday 20 January 2013 00:02:02 Gene Heskett did opine:
Message additions Copyright Sunday 20 January 2013 by Gene Heskett

> Greetings all;
> 
> Has anyone cut any threads with g76 lately?
> 
> I fired off a routine that 4 months back worked great, carving a 1/4-28
> thread for me several times last fall.  Tonight, without any changes in
> the .hal file that would affect threading ops, still set to make a
> 1/4-28 SAE thread, and it came out at about 24 tpi.  And I haven't a
> clue.  My encoder still has 39 slots. Etc, etc.  I am on the bleeding
> edge development branch.
> 
> If someone could go cut a thread with this 2.6 code and check it for
> true tpi, it might help me find whatever dumb effect I've put into this
> in my spindle servo tuning.
> 
> Thanks folks.

A PS of sorts here.  I just recalled that I had changed the servo-thread 
to run at 2khz a couple weeks ago.  This of course doubles the capture 
rate of encoder.capture.position.

Could this be why the threads I tried to cut were coarser than I expected?  

If that scales directly, then I should have gotten 14 tpi threads, 
but they were about 24 tpi when set for 28.  That is nowhere near a 2/1 
error.  So that doesn't grok at all.

Here is that routine:
%
g7
s100
( all measurements in inches, set thread pitch )
# = 28
# = [1.000 / #]

( set threads OD )
# = 0.250

( from thread_OD set drive& retrace diameters )
( set drive line OD )
# = [# + 0.060]

( set z far enough away sync is good. -0.1 leaves .2" for startup accel 
wibblies )
#= -0.1

( ending point of thread at first pass, Q will advance it! )
#=-0.503

( calculate this K from pitch )
( set k, peak to valley of std USS/USF thread format = pitch/0.866 -10% clipped 
from peak and valley )
(# should=0.032993, debug print it)

( so I want to use 80% of pitch /0.866 according to the Handbook)
# = [0.8 * [# / 0.866]]

( set threads OD, drive_line minus i )
# = [0.000 -[# - #] - 0.003]
g1f26 x#
g1f26 z#
m3
g76 p# z# i# j0.005 k# r1.7 q29.5 h2 e0.015 l2

( leave it where it started from )
g1f26 x#

( but move it out of the way of gages )
g1f26 z[# +6.00]
g1x0.000
m5
m2
%
==
I will change the servo-thread back to 1 kilohertz and retest tomorrow.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 
Tact is the art of making a point without making an enemy.
I was taught to respect my elders, but its getting 
harder and harder to find any...

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G76?

[Gene Heskett]

Greetings all;

Has anyone cut any threads with g76 lately?

I fired off a routine that 4 months back worked great, carving a 1/4-28 
thread for me several times last fall.  Tonight, without any changes in the 
.hal file that would affect threading ops, still set to make a 1/4-28 SAE 
thread, and it came out at about 24 tpi.  And I haven't a clue.  My encoder 
still has 39 slots. Etc, etc.  I am on the bleeding edge development 
branch.

If someone could go cut a thread with this 2.6 code and check it for true 
tpi, it might help me find whatever dumb effect I've put into this in my 
spindle servo tuning.

Thanks folks.

-- 
Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

A husband is what is left of the lover after the nerve has been extracted.
-- Helen Rowland
I was taught to respect my elders, but its getting 
harder and harder to find any...

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76, G33 revisited.

[andy pugh]

On 10 June 2012 00:11, gene heskett  wrote:

> despite Z being limited by its maxvel, it kept on trucking,
> which of course would have wrecked the thread in progress.

The normal reaction to a f-error problem is to stop the axes and
spindle, which would probably break the tool during threading.

> This would be a special case since X
> really should be pulled for clearance while the spindle is winding down if
> the following error were to be asserted

Actually, I think it should simply refuse to start the thread. I
rather thought it did.

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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G76, G33 revisited.

[gene heskett]

I just made another discovery.  There apparently is not a following error 
stopper while G76 is running.

Cutting all air, and after slowing the Z accel and maxvel to 75% of what I 
was using 3 days ago, I found that my Z can make a bit over 21" without any 
following errors regardless of what jig I dance on the jog keys.  That is 
about a 30% improvement in the rapids that could possibly be expanded to 35 
or 40%.

Then I loaded up that 4mm x.7mm metric thread cutter routine and reset the 
spindle from 200 to 700.  No problems cutting air.  So I crept on up with 
the spindle override slider until at about 770 revs, the forward cut was 
the same speed as the retrace, 533 mm according to the display.  Knowing Z 
was tapped out I was expecting a following error, but I went on up to about 
1000 rpms, and despite Z being limited by its maxvel, it kept on trucking, 
which of course would have wrecked the thread in progress.

Not that I will ever do that on purpose, so to me it is a shrug, but I 
thought maybe I should mention it.  This would be a special case since X 
really should be pulled for clearance while the spindle is winding down if 
the following error were to be asserted, then it might be that the part 
could be saved.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: 
Wherever you go...There you are.
- Buckaroo Banzai

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 thread depth

[Andy Pugh]

On 17 May 2010 13:08, Daniel Goller  wrote:
>
> On a side note, G76 on our Fanuc, using thread depth out of the
> machinist handbook/threadmaker app, we finish OD threads at a good
> -.010 to -.030 ( varies by diameter and pitch) wear offset before the
> gages show the thread in tolerance.
> Seems like a common problem in other words.

I have been looking at
http://www.tribology-abc.com/calculators/metric-iso.htm
And see plenty of scope for confusion, but I am not sure that the
diagram is actually right. It seems to indicate that the nominal
diameter is to the centre of the crest-rounding, so the actual OD is
bigger than the nominal size, whereas every bolt I have ever measured
is less than the nominal diameter.


-- 
atp

--

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

Re: [Emc-users] G76 thread depth

[Daniel Goller]

On a side note, G76 on our Fanuc, using thread depth out of the
machinist handbook/threadmaker app, we finish OD threads at a good
-.010 to -.030 ( varies by diameter and pitch) wear offset before the
gages show the thread in tolerance.
Seems like a common problem in other words.

On Mon, May 17, 2010 at 6:27 AM, Andy Pugh  wrote:
> I have noticed that I need a lot more thread depth in G76 than the
> tables say I should need. For instance an M12 thread should have a
> thread depth of 1.08mm, but I needed 1.55mm before the nut would fit
> on.
> I was using a 29.5 degree "compound slide" angle (Q), do I need to
> allow for this like you would manually machining?
> Is it possible that things are getting confused by being in diameter mode?
> (I have already realised that the first cut is "I" inside the start
> position, though it took a while)
>
> --
> atp
>
> --
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--

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

[Emc-users] G76 thread depth

[Andy Pugh]

I have noticed that I need a lot more thread depth in G76 than the
tables say I should need. For instance an M12 thread should have a
thread depth of 1.08mm, but I needed 1.55mm before the nut would fit
on.
I was using a 29.5 degree "compound slide" angle (Q), do I need to
allow for this like you would manually machining?
Is it possible that things are getting confused by being in diameter mode?
(I have already realised that the first cut is "I" inside the start
position, though it took a while)

-- 
atp

--

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

Re: [Emc-users] G76 Threading

[Andy Pugh]

2009/9/29 Kirk Wallace :

> I have only read the original post and watched the video, so I may be
> off base here. I had the same symptoms on my lathe. I believe the thread
> pitch and spindle RPM are at a rate that is beyond the Z axis abilities
> to accelerate. I slowed my spindle RPM down and allowed for a fair
> amount of air cutting to allow Z to stabilize before reaching the real
> threading.

I have tried as low as 50 rpm (where there probably isn't enough
torque to actually cut) and things are marginally better, but still
not good enough to thread.

>  I also tried to optimize my acceleration settings. Too high
> of an acceleration number created following errors, so it's a
> compromise.

My z-accel is as fast as it can be, tuned in stepconf.

-- 
atp

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 Threading

[Kirk Wallace]

On Tue, 2009-09-29 at 17:04 +0100, Andy Pugh wrote:
... snip
> 
> > http://www.youtube.com/watch?v=NDA48nLdbiI
> 
> More data after a long discussion on the IRC channel:
> HAL setup: http://www.pastebin.ca/1581821
> Halscope grabs:
> http://www.atp.pwp.blueyonder.co.uk/G76.png
> http://www.atp.pwp.blueyonder.co.uk/g76b.png
> 
> It seems to be related to the index pulse rate. But there is no trace
> of the index pulse in the input to motion.spindle-revs
> 
> --
> atp

I have only read the original post and watched the video, so I may be
off base here. I had the same symptoms on my lathe. I believe the thread
pitch and spindle RPM are at a rate that is beyond the Z axis abilities
to accelerate. I slowed my spindle RPM down and allowed for a fair
amount of air cutting to allow Z to stabilize before reaching the real
threading. I also tried to optimize my acceleration settings. Too high
of an acceleration number created following errors, so it's a
compromise. Basically your Z cannot instantly accelerate to match the
spindle RPM. It's like trying to grab onto a moving carousel. It just
came to mind, I wonder if changing the spindle RPM would help -- slow at
first, fast in the middle or the tread, then slow again at the end?
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 Threading

[Andy Pugh]

2009/9/27 Andy Pugh :
> 2009/9/27 Andy Pugh :
>
>> http://www.youtube.com/watch?v=NDA48nLdbiI

More information.
G33 is exactly the same.
Smaller pitches are better, but even 1.25mm pitch (20 tpi)
occasionally gets the wobbles.

--
atp



-- 
atp

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G76 Threading

[Andy Pugh]

(I thought you were all ignoring my questions, but I suspect that I
was sending from an email address not registered with the listserver.
Brace yourselves for a flurry of posts)

I seem to be having a spot of bother with G76. I thought it was
working fine, then noticed that the z axis was running at max-speed
and cutting the wrong pitch. Slowing down the spindle and increasing
the z-axis accel limit produced the issue shown here:
http://www.youtube.com/watch?v=NDA48nLdbiI
It seems almost like a badly tuned PID controller.
It isn't a brilliant encoder, as can be seen on the velocity trace
(but note that velocity baseline is at the bottom of the screen), but
surely the position counts should update steadily enough?
Which encoder position is meant to be wired to the motion.spindle-revs
input, by the way? Stepconf uses encoder.0.position, but that seems to
be an integer, and I am wondering if it should be
encoder.position-interpolated. Watching the machine it is almost like
it is updating the carriage position once per rev...

--
atp



-- 
atp

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 Threading

[Andy Pugh]

-- Forwarded message --
From: Andy Pugh 
Date: 2009/9/27
Subject: Re: G76 Threading
To: "Enhanced Machine Controller (EMC)" 


2009/9/27 Andy Pugh :

> http://www.youtube.com/watch?v=NDA48nLdbiI

More data after a long discussion on the IRC channel:
HAL setup: http://www.pastebin.ca/1581821
Halscope grabs:
http://www.atp.pwp.blueyonder.co.uk/G76.png
http://www.atp.pwp.blueyonder.co.uk/g76b.png

It seems to be related to the index pulse rate. But there is no trace
of the index pulse in the input to motion.spindle-revs

--
atp



-- 
atp

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Steve Blackmore]

On Mon, 31 Aug 2009 08:48:03 -0500, you wrote:

>On Mon, Aug 31, 2009 at 11:35:43AM +0100, Steve Blackmore wrote:
>> 
>> Hi Chris - thanks found inches/mm in view menu. As Les said it would be
>> good if it changed with G20/G21 automatically.
>
>
>I disagree.
>
>I compare the numbers on the DRO to the numbers on my dial caliper,
>and the numbers on my dial caliper don't change when I load a
>different gcode program.

Don't you have both inch and metric dial calipers? Personally I never
use them these days, I prefer my digital metrinch Moore and Wright.

>Currently we can both have what we want.  It would be wrong to change
>that so only one of us has what we want, because then we'd have to
>argue about it!

??

Alex has the right idea - make it an option :)

Steve Blackmore
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Chris Radek]

On Mon, Aug 31, 2009 at 11:35:43AM +0100, Steve Blackmore wrote:
> 
> Hi Chris - thanks found inches/mm in view menu. As Les said it would be
> good if it changed with G20/G21 automatically.


I disagree.

I compare the numbers on the DRO to the numbers on my dial caliper,
and the numbers on my dial caliper don't change when I load a
different gcode program.

Currently we can both have what we want.  It would be wrong to change
that so only one of us has what we want, because then we'd have to
argue about it!

Chris


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Steve Blackmore]

On Sun, 30 Aug 2009 23:38:18 +0100, you wrote:



>> 
>> It would appear from the parameters that the G76 doesn't support taper
>> threads.
>
>No it doesn't. I had to do a taper thread today and the only way was 
>with G33.

I was writing two post processors for Dolphin and FeatureCam, but it's
not worth including G76 if it doesn't support taper threads. There is no
way of limiting the selection in CAM to parallel threads only.

Steve Blackmore
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Alex Joni]

I don't agree with that.
I like to have the user interface in mm only, doesn't matter if I load one 
of my programs, or something I received from across the pond :)

The real answer actually is: either way there will be a group of people that 
won't like the default behaviour (either switching or non-switching)
So maybe it could be defined in .axisrc somehow.

Regards,
Alex


> On Sun, 30 Aug 2009 20:17:09 -0500, you wrote:
>
>>>
>>> Additionally - difficult to tell what's going on, lathe is set up in mm,
>>> when running a G20 file, DRO's and feed still display in metric units :(
>>
>>You can pick whichever display units you want in the menu.
>>
>>With AXIS you can have any combination of units: inifile units,
>>gcode program units, dro displayed units.
>
> Hi Chris - thanks found inches/mm in view menu. As Les said it would be
> good if it changed with G20/G21 automatically.
>
> Steve Blackmore
> --
> 

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Steve Blackmore]

On Sun, 30 Aug 2009 20:17:09 -0500, you wrote:

>> 
>> Additionally - difficult to tell what's going on, lathe is set up in mm,
>> when running a G20 file, DRO's and feed still display in metric units :(
>
>You can pick whichever display units you want in the menu.
>
>With AXIS you can have any combination of units: inifile units,
>gcode program units, dro displayed units.

Hi Chris - thanks found inches/mm in view menu. As Les said it would be
good if it changed with G20/G21 automatically.

Steve Blackmore
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Leslie Newell]

Hi Chris,

Steve wants the display units to change with the G-code. If the code is 
metric, the display is metric. If the code is inch the display is in 
inches. Having inch code with metric DROs or vice-versa can be very 
confusing.

Les

> 
> You can pick whichever display units you want in the menu.
> 
> With AXIS you can have any combination of units: inifile units,
> gcode program units, dro displayed units.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Chris Radek]

> 
> Additionally - difficult to tell what's going on, lathe is set up in mm,
> when running a G20 file, DRO's and feed still display in metric units :(

You can pick whichever display units you want in the menu.

With AXIS you can have any combination of units: inifile units,
gcode program units, dro displayed units.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Leslie Newell]

Hi Steve,

Here's my take on G76:

> I don't understand the implementation method,  in particular the  "drive
> line" mentioned in the manual.

The drive line is the safe clearance outside the thread. It is the 
current X axis position when you call G76. I normally use thread peak + 
1mm.

I is the distance from the drive line to the thread peak
K is the distance from the thread peak to the thread root (cut depth)

> Was that program written for radius mode?

Undoubtedly. Diameter mode is pretty recent.

> 
> Wouldn't a XZ start point and an XZ end point and a return clearance
> distance have been more practical?  

And less confusing. G76 gets the job done for parallel threads but you 
do have to really think about it.

> 
> It would appear from the parameters that the G76 doesn't support taper
> threads.

No it doesn't. I had to do a taper thread today and the only way was 
with G33.

Les

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76

[Steve Blackmore]

On Sun, 30 Aug 2009 12:56:14 +0100, you wrote:

>Can somebody explain G76 please.
>
>I don't understand the implementation method,  in particular the  "drive
>line" mentioned in the manual.
>
>The docs say the sample program g76.ngc shows the method.
>
>The figures in that don't make sense for a 1/4x20 thread. The initial
>position is z.2 z.2 

Oops, should read z.2 x.2

>The major diameter of that thread is .2449 ??
>
>Manual says the "drive line" is a safe position outside the thread and
>also goes from the initial location to the value specified in the Z-
>value. If so how can that cut an external 1/4x20 thread? (I'm guessing
>the drive line is the thread major diameter + some arbitrary value set
>by the op, and is the same as the clearance distance)
>
>Was that program written for radius mode?
>
>Wouldn't a XZ start point and an XZ end point and a return clearance
>distance have been more practical?  
>
>It would appear from the parameters that the G76 doesn't support taper
>threads - defining the start/end positions make that possible.

Additionally - difficult to tell what's going on, lathe is set up in mm,
when running a G20 file, DRO's and feed still display in metric units :(

Steve Blackmore
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G76

[Steve Blackmore]

Can somebody explain G76 please.

I don't understand the implementation method,  in particular the  "drive
line" mentioned in the manual.

The docs say the sample program g76.ngc shows the method.

The figures in that don't make sense for a 1/4x20 thread. The initial
position is z.2 z.2 

The major diameter of that thread is .2449 ??

Manual says the "drive line" is a safe position outside the thread and
also goes from the initial location to the value specified in the Z-
value. If so how can that cut an external 1/4x20 thread? (I'm guessing
the drive line is the thread major diameter + some arbitrary value set
by the op, and is the same as the clearance distance)

Was that program written for radius mode?

Wouldn't a XZ start point and an XZ end point and a return clearance
distance have been more practical?  

It would appear from the parameters that the G76 doesn't support taper
threads - defining the start/end positions make that possible.

Steve Blackmore
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G76 inifinite loop

[Michał Geszkiewicz]

This is surely bug and will be fixed in emc 2.3.3
Thanks for bug report,

Michael

Frank Tkalcevic pisze:
> If I put in an invalid G76 threading command in some gcode, such as...
>
>
> G76 P1.6 Z0 I-1.6 J0 K1.6 R2 H0 E0 L0
>
>
> Where J, the initial depth of cut, is 0, axis gets stuck in an infinite
> loop.  Obviously this is wrong because the thread will never finish, but it
> took me an hour to track this down (bug in my script).  There's a similar
> result doing this in the MDI.  An error/warning would be nice.
>
> Frank
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>   


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

Re: [Emc-users] G76 inifinite loop

[Alex Joni]

Hi Frank,

thanks for the report.
The _best_ thing you can do, is report this issue as a new bug at:
http://sourceforge.net/tracker/?group_id=6744&atid=106744

That way it would surely not be forgotten.

Regards,
Alex

- Original Message - 
From: "Frank Tkalcevic" 
To: "'Enhanced Machine Controller (EMC)'" 
Sent: Monday, July 06, 2009 1:50 AM
Subject: [Emc-users] G76 inifinite loop


> If I put in an invalid G76 threading command in some gcode, such as...
>
>
> G76 P1.6 Z0 I-1.6 J0 K1.6 R2 H0 E0 L0
>
>
> Where J, the initial depth of cut, is 0, axis gets stuck in an infinite
> loop.  Obviously this is wrong because the thread will never finish, but 
> it
> took me an hour to track this down (bug in my script).  There's a similar
> result doing this in the MDI.  An error/warning would be nice.
>
> Frank
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 


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

[Emc-users] G76 inifinite loop

[Frank Tkalcevic]

If I put in an invalid G76 threading command in some gcode, such as...


G76 P1.6 Z0 I-1.6 J0 K1.6 R2 H0 E0 L0


Where J, the initial depth of cut, is 0, axis gets stuck in an infinite
loop.  Obviously this is wrong because the thread will never finish, but it
took me an hour to track this down (bug in my script).  There's a similar
result doing this in the MDI.  An error/warning would be nice.

Frank


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