# G71

23 May 2019 18:58 #134734 by andypugh
Replied by andypugh on topic G71
Being able to use the existing radius comp code (so that it is only done in one place, and consistently) is the only real reason to use C-code rather than the Python remap.

23 May 2019 20:55 #134742 by automata
Replied by automata on topic G71
Hi Patrik T,

1. How come you first rounded out there corners with Q word? Any reason for that?
2. Did you try the finish pass with very large value of the offset?
3. If you offset a semicircle with different values in X and Z does the offset curve still remain a part of a circle?
4. How did you calculate which of the offsetted curves in a valley that would result in a self intersecting offset curve. Would a self intersecting offset curve be allowed in your method? If not , how do you remove the self intersecting portions?
-automata

23 May 2019 20:59 #134743 by automata
Replied by automata on topic G71
Hi Andy,
Tool diameter compensation/ tool lathe radius compensation works with the assumption that the offset in both X and Z access is the same amount.

Will the same method hold of we offset by different values in X and Z axes?

Would the offset curve for a circle still be a circle?

-automata

23 May 2019 22:09 - 23 May 2019 22:40 #134745 by Patrik T
Replied by Patrik T on topic G71
1) Don't remember exactly, I think it was the most logical letter available. Or if you mean why I implemented a fillet radius function; It is a cool and useful thing to have. Programming a radius connecting tangentially between for example two other radii takes some math skills. Now it is as easy as typing q2.
2 and 4) Too large offsets can cause over cut. It can't handle a too small piece of contour with non tangential connections. The programmer will need to know not to program chamfers too small for the current tool radius.
3) Yes.
Last edit: 23 May 2019 22:40 by Patrik T.

24 May 2019 10:46 #134796 by automata
Replied by automata on topic G71
Hi Patrik T,
Thanks for the response. That clears my understanding of offsetting.
Would you care to share your G71 patch python code?
Regards,
-automata

24 May 2019 15:42 #134820 by smplc
Replied by smplc on topic G71
andypugh,

An O number is output either a main or sub-program. When a main program automation and cursor reaches G71 it retrieves file and source code. How does G71 file and source code collect main program start and end finish coordinates? Does G71 file read a character, leave the file momentarily, recover main program start and end finish coordinates and go back to it's file, continue and return to main program? Does G71 run simultaneously with main program interchangeably, read ahead and collect start and end finish coordinates, proceed and return to main program?

24 May 2019 15:47 #134821 by andypugh
Replied by andypugh on topic G71

Does G71 run simultaneously with main program interchangeably, read ahead and collect start and end finish coordinates, proceed and return to main program?

G71 is, in effect, a specialised version of a subroutine call. It goes to the subroutine in largely the normal way, but reads the G0/1/2/3 moves into an internal store rather than executing them as moves.

24 May 2019 16:23 - 24 May 2019 16:30 #134825 by smplc
Replied by smplc on topic G71
andypugh,

Such LinuxCNC o code remind me of a Fanuc M98. An instance useful for a M98 and output is a bar feeder program.

I understand Fanuc G71 purpose and essential algorithm to program output and used it many times with industrial and commercial CNC lathes.

I'd like to develop a G71 with C language source code for Mach4 interface. I can probably make own algorithm. However, I need to determine how to collect start and end finish coordinates of main O program. I could make my own main C program and executable G71 that doesn't transmit O program finish coordinates but my purpose is to share the O program and make a macro or module. Therefore. How does G71 source code receive start and end finish coordinates of main output program?
Last edit: 24 May 2019 16:30 by smplc.

24 May 2019 16:34 #134827 by andypugh
Replied by andypugh on topic G71
Have you looked at the G71 remap source?

github.com/LinuxCNC/linuxcnc/blob/andypu.../g71/python/remap.py

24 May 2019 17:51 #134834 by smplc
Replied by smplc on topic G71
andypugh,

Yes. I'm not fluent with Python but studied some of it's language and recognize some data types and functions. I recognize some of the algorithm too.

I still can't detect where the Python source code is recovering G71 ouput, start and end finish coordinates. Can you please identify a command line? It appears Python source code is using o-codes for start and end finish coordinates. These type of o-codes are output similar to filed sub-programs and not necessarily a main program.

I wouldn't use o-codes if not using LinuxCNC. Another starting and ending terminator would get used.