subject:"Re\: \[Emc\-developers\] G71"

Re: [Emc-developers] G71 and friends

2020-03-18 Thread andy pugh

On Sat, 15 Feb 2020 at 10:03,  wrote:
>
> As far as I'm concerned it's finished. I have added one more feature
> which uses U and W for incremental coordinates. That's not documented yet.

Could you take a look at this?

https://github.com/LinuxCNC/linuxcnc/issues/699


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


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

Re: [Emc-developers] G71 and friends

2020-02-15 Thread mark . vandoesburg

As far as I'm concerned it's finished. I have added one more feature
which uses U and W for incremental coordinates. That's not documented yet.

I'll create a pull request tomorrow.

andy pugh  wrote:

On Thu, 9 Jan 2020 at 21:41,  wrote:

>
> I've added the documentation for the cycles. Apart from the inevitable
> bugfixes I'm done for now.
>
> I have been trying (and failing) to find the time to look at this.
What's the current status? Is there a mergeable pull request?


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


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

Re: [Emc-developers] G71 and friends

2020-02-14 Thread andy pugh

On Thu, 9 Jan 2020 at 21:41,  wrote:

>
> I've added the documentation for the cycles. Apart from the inevitable
> bugfixes I'm done for now.
>
> I have been trying (and failing) to find the time to look at this.
What's the current status? Is there a mergeable pull request?


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

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

Re: [Emc-developers] G71 and friends

2020-01-11 Thread John

I'm the same on my Hardinge CHNC 99% of the ops are done with ngcgui 
subroutines... one of these days I'll update the Ubuntu 10.04 to Debian 
10 and install my QtPyVCP GUI.


JT

On 1/8/20 7:02 PM, andy pugh wrote:

On Thu, 9 Jan 2020 at 00:53, Ben Potter  wrote:


I used to feel the same way, but I now use G71 for lathe work a lot more than I 
use CAM.

Typically I don't even use G71. I have my own GUI with turn / face /
bore / thread tabs and build parts op-by-op. I only ever make one of
anything typically, so this is like working a manual lathe (which I
enjoy) with super power feeds that know where to stop and then return
for the next pass.




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

Re: [Emc-developers] G71 and friends

2020-01-09 Thread mark . vandoesburg

andy pugh  wrote:

Typically I don't even use G71. I have my own GUI with turn / face /
bore / thread tabs and build parts op-by-op. I only ever make one of
anything typically, so this is like working a manual lathe (which I
enjoy) with super power feeds that know where to stop and then return
for the next pass.

That's what I did until now. But it really felt like I wasn't using the
machine as I should. And adding chamfers was a chore ;-)

I've added the documentation for the cycles. Apart from the inevitable
bugfixes I'm done for now.

regards,

Mark.


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

Re: [Emc-developers] G71 and friends

2020-01-08 Thread andy pugh

On Thu, 9 Jan 2020 at 00:53, Ben Potter  wrote:

> I used to feel the same way, but I now use G71 for lathe work a lot more than 
> I use CAM.

Typically I don't even use G71. I have my own GUI with turn / face /
bore / thread tabs and build parts op-by-op. I only ever make one of
anything typically, so this is like working a manual lathe (which I
enjoy) with super power feeds that know where to stop and then return
for the next pass.

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

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

Re: [Emc-developers] G71 and friends

2020-01-08 Thread Ben Potter

> From: andy pugh
> Sent: 07 January 2020 13:46
> To: mark.vandoesb...@hetnet.nl
> Cc: EMC developers 
> Subject: Re: [Emc-developers] G71 and friends
> 
> On Mon, 6 Jan 2020 at 20:42,  wrote:
> 
> > Why do it that way rather than specify a curve or line in the
> > sub that defines the fillet / chamfer?
> >
> > I don't have CAM software,
> 
> Well, I can't imagine using G71 if you did have CAM software.
> (Fusion360 is partly why I lost the incentive to convert my G71 remap to
> native code) But a chamfer is easy to hand-code, and R-format arcs are
> simple too.
> I think that the objection to R-format falls down in lathe code where they are
> typically exactly 90 degrees.
>

I used to feel the same way, but I now use G71 for lathe work a lot more than I 
use CAM.

For prototype work it isn't worth the time for me to mess around with 
transferring programs on a floppy! The only time I'll use CAM on the lathe is 
if I've got multiple backfacing ops. 

One of the reasons I abandoned my G71 code was that my linuxcnc lathe had a 
major control failure, I was offered a Haas TL-1 shortly afterwards at a price 
I couldn't refuse.
Since picking that up I've gotten far more used to entering programs on the 
control, with linuxcnc I always wrote the program on the computer and 
transferred when ready to run. 

I still use linuxcnc on the Bridgeport and the router, but don't have time to 
keep up with development any more.

Best Wishes
Ben

> 
> --
> 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, 1912
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers

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

Re: [Emc-developers] G71 and friends

2020-01-07 Thread andy pugh

On Mon, 6 Jan 2020 at 20:42,  wrote:

> Why do it that way rather than specify a curve or line in the
> sub that defines the fillet / chamfer?
>
> I don't have CAM software,

Well, I can't imagine using G71 if you did have CAM software.
(Fusion360 is partly why I lost the incentive to convert my G71 remap
to native code)
But a chamfer is easy to hand-code, and R-format arcs are simple too.
I think that the objection to R-format falls down in lathe code where
they are typically exactly 90 degrees.

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

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

Re: [Emc-developers] G71 and friends

2020-01-06 Thread mark . vandoesburg

I think that this seems unnecessary and means that you can't simply
run the sub as-is for a finish pass.

That's true, but you can do the finish pass with G70. If you do G70 Q100
it does the call with the chamfers and fillets.

Why do it that way rather than specify a curve or line in the
sub that defines the fillet / chamfer?

I don't have CAM software, yes I have FreeCAD but there's no lathe
functionality worth mentioning. So what I do is edit the g-code by
hand to generate the profile, if you do that adding a fillet is a lot
of work.  Which is also the reason why it is important for me to be able
to use variables/equations etc in the subroutines.

But anyway, it's not something you have to use, if you do these things in
the profile you don't use A and C and you can use CALL for finishing. If
you have a lathe with an A or C axis I don't think it is usefull to use
a subroutine using those axes with G71.

regards,

Mark.


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

Re: [Emc-developers] G71 and friends

2020-01-06 Thread andy pugh

On Fri, 3 Jan 2020 at 19:45,  wrote:

> Unfortunately I use different letters for almost everything :-(

My remap is built on top of a previous but unfinished experimental branch:
https://github.com/LinuxCNC/linuxcnc/tree/BenPotter/G71

I really want us to stop re-doing this. There have been several
attempts made, and none committed.

My Type-2 version was done in Python mainly because I thought of what
I believed to be a neat algorithm one night, and wanted to try it out.
I consider my only real contribution useful to LinuxCNC to be the manual pages.

> I've taken the Fanuc Series 0/00/0-Mate for Lathe operator's manual
> section 13.2.1 to 13.2.2 as a guide.

I just followed an existing implementation (the one above) and used
all the same letters. I had assumed that it was built on a standard
from a commercial control, possibly Okuma?

I guess that if the letters are different then the images from my
manual pages are not re-usable either.

> I don't do gouge detection, but linuxcnc does it when cutter compensation
> is used.

Does it use the front angle and back angle data? (I could check the
code, of course, but I have just got back from 2 weeks holiday and I
am working through a huge backlog of email and forum posts)

> My cycle only works in the G18 plane, it's for a lathe after all

True, but I chose to generalise my implementation as it is easier to
do that now than later. I can imagine that a multi-slide lathe might
want to use YZ and possibly UZ.

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

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

Re: [Emc-developers] G71 and friends

2020-01-06 Thread andy pugh

On Sun, 5 Jan 2020 at 16:23,  wrote:
>
> After just one part, I realized it was still incomplete. So I added the
> ability to specify if a corner should get a fillet or chamfer.

I think that this seems unnecessary and means that you can't simply
run the sub as-is for a finish pass.

Why do it that way rather than specify a curve or line in the sub that
defines the fillet / chamfer?

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


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

Re: [Emc-developers] G71 and friends

2020-01-05 Thread mark . vandoesburg

After just one part, I realized it was still incomplete. So I added the
ability to specify if a corner should get a fillet or chamfer. In the sub
you just have to add "A0.5" to get a 0.5mm radius fillet at that point.
If you want a chamfer you can do this using "C0.5". Other sizes are possible
of course :-)

regards,

Mark.


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

Re: [Emc-developers] G71 and friends

2020-01-03 Thread Gene Heskett

On Friday 03 January 2020 12:41:41 andy pugh wrote:

> On Thu, 2 Jan 2020 at 21:47,  wrote:
> > I've just pushed a new version. This one supports cutter
> > compensation for G70 and the use of O words (such as call/repeat) in
> > the subroutine used for the path.
>
> There have been a few attempts made to add these cycles. I did one
> myself as a remap as a test of a type-2 algorithm.
> https://github.com/LinuxCNC/linuxcnc/tree/andypugh/g71type2remap
>
> The hope was that someone else who was working on this at the time
> would combine the two to give a built-in version.
> The reason that I feel it should be built-in is so that cutter
> compensation is done in only one place. I am away from home at the
> moment so can't easily check if this is the case with your version.
>
> The main reason, though, that I mention my experimental branch is that
> I did document the cycles, with explanatory images. This might be
> re-usable, if your version of the G71 cycles behaves the same way.
>
> https://github.com/LinuxCNC/linuxcnc/blob/andypugh/g71type2remap/docs/
>src/gcode/g-code.txt#g71-lathe-roughing-cycle-turning

Two things about that Andy.

1. All the arrows need a definition of what they represent.

2. And down in the g76 section just below this, there is still no mention 
of using L and E to cut a long low angle taper for use in a compression 
locked shaft joint, both for the external thread, and conversely for the 
nut that fits that thread.

I am useing such a connection between the shaft for the motor drive and 
its being clamped to the ballscrew for X drive on my Sheldon.  Define L 
to put the big end at the left, and E as one "pitch" less than Z. By 
drilling into the end of that shaft to exactly fit the ball screw, then 
EDM sawing the walls of this socket into 4 petals, make a custom nut to 
fit threads at the small end, inserting the ball screw into that socket 
and tightening the nut 3 or 4 turns, many tons of gripping pressure can 
very effectively make it one piece. With needle cartridge bearings on 
that shaft, and roller thrust washers counter sunk so the outside washer 
exactly fits the countersink in the front of the old hand crank boss so 
no swarf can get in, my major src of X backlash is the nut, hovers at 
about 1.3 thou. Part of that is that the nut is mountless, so its 
mounted in a cage and has felt swarf wipers set into tapered holes in 
brass plates on each end face, driven by small bolts to squeeze the 
brass plates, and the nut, in turn squeezing the felt into the threads 
for wiping a fresh layer of oil on the screw.  With the bottom of the 
cage sealed up with go-2, an annual refill of vactra seems to be 
sufficient to keep it wet.

Its a piece of cake to do, but it does need to be properly explained. But 
with the current text, you have to think way outside the box to do it.

Thanks Andy.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

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

Re: [Emc-developers] G71 and friends

2020-01-03 Thread mark . vandoesburg

There have been a few attempts made to add these cycles. I did one
myself as a remap as a test of a type-2 algorithm.
https://github.com/LinuxCNC/linuxcnc/tree/andypugh/g71type2remap

Mine is in C++ and is integrated into linuxcnc.

The hope was that someone else who was working on this at the time
would combine the two to give a built-in version.
The reason that I feel it should be built-in is so that cutter
compensation is done in only one place. I am away from home at the
moment so can't easily check if this is the case with your version.

Yes it uses the cutter compensation already in linuxcnc. The other stuff
such as allowing the use of X[#+3] and Oxxx REPEAT and so on is
also re-use of the code already in linuxcnc.

What I do is to inject an "Oxxx CALL" line into the interpreter and then
take whatever it feeds me back until the subroutine is finished.

The main reason, though, that I mention my experimental branch is that
I did document the cycles, with explanatory images. This might be
re-usable, if your version of the G71 cycles behaves the same way.

https://github.com/LinuxCNC/linuxcnc/blob/andypugh/g71type2remap/docs/src/gcode/g-code.txt#g71-lathe-roughing-cycle-turning

It is at least very similar. I see you're using straight sections
to follow the final shape at a distance, while my method uses round
and straight sections as required to maintain a fixed distance.
Unfortunately I use different letters for almost everything :-(

I've taken the Fanuc Series 0/00/0-Mate for Lathe operator's manual
section 13.2.1 to 13.2.2 as a guide. There is however no limit (unless
you exhaust the memory of your computer) on the number of pockes. Pockets
may also be nested in other pockets. My cycle also does not have to start
beyond the end of the path. I do this to allow boring and finishing
the bottom of that bore using the same path.

A comparison of the parameters:

You Me
P Q The Q kind of looks like an O to me, and I wanted to
use P to give the number of passes for the G70 cycle
D I I used I for increment.
R R A perfect match :-) (but it is used)
J W It adds to the distance specified with D in my cycle
L U This is also added to D, U and W are simply an extra
displacement added to the resulting profile.
I/K Not implemented, the finishing pass starts at a distance D
from the final profile and ends at distance E. Each pass
the distance is decreased with (D-E)/P. Both numbers
E and D may be positive or negative. The distances can
be quite large until further extension of the distance
would make the curve non-monotonic (Currently I just
remove the non-monotonic parts, but maybe I should give
an error). This large distance allows G70 to be used
almost like a Fanuc G73 cycle.

F Specify this in advance, just like the T, S and G43. If
you want to use cutter compensation you also have to
specify the G41/G42 before starting G70. It is an error
to start G71/G72 when G41 or G42 is active.

D This is used to specify a distance to keep from the final
profile during G71/G72. This letter is used to specify the
initial distance in the G70 cycle
E The final distance during the G70 cycle, this is usually
0 but may be positive to make it oversized, or negative
to make it undersized.
P The number of passes used in the G70 cycle to go from the
initial distance to the final distance.
X used as an initial postition, a rapid is done to the location.
Z also initial position

My default method is also type 2. If you require type 1, you also need
to specify G71.1/G72.1. There is an additional G71.2/G72.2 which can
be used after the .1 cycle to finish the path. This for example allows
you to use a CCMT roughing tool and use VCMT for the pocketing/finishing.

I don't do gouge detection, but linuxcnc does it when cutter compensation
is used.

My cycle only works in the G18 plane, it's for a lathe after all. It also
doen't work if G91 is active, but I can fix that when necessary.

I've included 3 demo/test files:

lathe_g70_71_demo.ngc The lathe pawn, using G71.1/G71.2 and G70.

lathe_g7x_quadrants.ngc This shows the 8 ways in which the cycles can
be used.

lathe_g7x_face_boring.ngc Shows the use of variables and a "O REPEAT".

regards,

Mark.

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

Re: [Emc-developers] G71 and friends

2020-01-03 Thread andy pugh

On Thu, 2 Jan 2020 at 21:47,  wrote:
>
> I've just pushed a new version. This one supports cutter compensation for
> G70 and the use of O words (such as call/repeat) in the subroutine used
> for the path.

There have been a few attempts made to add these cycles. I did one
myself as a remap as a test of a type-2 algorithm.
https://github.com/LinuxCNC/linuxcnc/tree/andypugh/g71type2remap

The hope was that someone else who was working on this at the time
would combine the two to give a built-in version.
The reason that I feel it should be built-in is so that cutter
compensation is done in only one place. I am away from home at the
moment so can't easily check if this is the case with your version.

The main reason, though, that I mention my experimental branch is that
I did document the cycles, with explanatory images. This might be
re-usable, if your version of the G71 cycles behaves the same way.

https://github.com/LinuxCNC/linuxcnc/blob/andypugh/g71type2remap/docs/src/gcode/g-code.txt#g71-lathe-roughing-cycle-turning

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

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

Re: [Emc-developers] G71 and friends

2020-01-02 Thread mark . vandoesburg

I've just pushed a new version. This one supports cutter compensation for
G70 and the use of O words (such as call/repeat) in the subroutine used
for the path. It also allows the use of R type arcs, which was missing in
the previous version. The only thing I know which is missing is relative
(G91) path mode. I've never used it, so unless someone else wants it I'll
leave it this way.

I am considering adding G70.1 to allow the finishing cut to be taken in
the opposite direction from the roughing path. This might be usefull
after boring using G72.

regards,

Mark.


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

Re: [Emc-developers] G71 and friends

2019-12-29 Thread mark . vandoesburg

Is that all-new or based on one of the previous attempts? 

It's all new. I also forgot to mention that G70 has an E parameter whic
gives the end distance. I've updated the demo to reflect this.

The compare to Master seems to include a lot that isn???t related. 

Sorry for the noise, I've rebased and pushed a clean version.


regards,

Mark.


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

Re: [Emc-developers] G71 and friends

2019-12-29 Thread Andy Pugh



> On 29 Dec 2019, at 14:14, mark.vandoesb...@hetnet.nl wrote:
> 
> I've just created a branch on github 
> https://github.com/mark-v-d/linuxcnc/pull/new/g7x
> in which I implemented G70, G71 and G72.

Is that all-new or based on one of the previous attempts? 

The compare to Master seems to include a lot that isn’t related. 




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

60 matches

Mail list logo