G71.X Path Issue

[BSHoekstra]

I am learning to use the new G71.X command in Linuxcnc 2.9 on my CNC Lathe and found what may be a bug, or more likely pilot error.....not sure. The simple part profile code shown below should reproduce the issue by putting Axis into a non-responding "do-loop". Note, I added a comment to the code showing that by changing the 1st line of the part profile in the Sub Routine from G01 X10 Z0 to G01 X5 Z0 Axis works fine but this isn't the part profile I need.

Also, I would think that the G71X program would produce an error message that you can recover from versus putting Axis into a non-responsive "do-loop" when a part profile is entered that it cannot process.

G21 G18 G54 (G21 metric, G54 coordinate system 1, G18 ZX plane, G54 coordinate system) G49 (G49 cancel tool length offset) G90 G92.1 (G90 abs dist mode, G92.1 Reset coord sys offset) G94 G64 p0.001 (G94 Feed Mode=Units per Minute, G64p Best Possible Speed p=Motion Blend Tolerance) G8 (Diameter Mode = 7, Radius Mode = 8) G91.1 (G91.1 = Relative Arc Offset Distance)

O200 SUB ;Change the next line from G01 X10 Z0 to G01 X5 Z0 and Axis works fine but this isn't the part profile I need. G01 X10 Z0 G01 X10 Z-14 G01 X3 G01 X7 Z-22 O200 ENDSUB

F225 ;G71.1 Q200 X15.0 Z0 D0.04 I0.5 R1 G71.2 Q200 X15.0 Z0 D0.04 I0.5 R1 M2

Any help anyone can provide would be greatly appreciated.

Thank you, Barry

Information about my hardware and software:

I am using this Linux distribution and version: Buster 10
I am using this kernel version: 4.19.0-14-rt-amd64 #1 SMP preempt RT Debian 4.19.171-2
I am running ...
    [X ] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
I am using this LinuxCNC version : 2.9.0-pre0-3806.gfc8944ed0
I am using this user interface (GUI): AXIS
I am using this interface hardware vendor and chipset: parallel port, Dell 3020

[BSHoekstra]

After sleeping on this, I realized that this part profile works by using a Left to Right cutting direction instead of a Right to Left cutting direction and by doing this, it does not put Axis into a non-responsive "do-loop". However,

1) In some cases it would be nice to cut this part profile from Right to Left if possible using G71.X. Does anyone know how to do this? 2) Also, I would think that the G71X program would produce an error message that you can recover from versus putting Axis into a non-responsive "do-loop" when a part profile is entered that it cannot process.

Thank you in advance,

Barry

; This part profile works by using a Left to Right cutting direction G21 G18 G54 (G21 metric, G54 coordinate system 1, G18 ZX plane, G54 coordinate system) G49 (G49 cancel tool length offset) G90 G92.1 (G90 abs dist mode, G92.1 Reset coord sys offset) G94 G64 p0.001 (G94 Feed Mode=Units per Minute, G64p Best Possible Speed p=Motion Blend Tolerance) G8 (Diameter Mode = 7, Radius Mode = 8) G91.1 (G91.1 = Relative Arc Offset Distance)

O200 SUB
G01 X7 Z-22 G01 X3 Z-14 G01 X10 G01 Z0 O200 ENDSUB

F225 G71.1 Q200 X15.0 Z0 D0.04 I0.5 R1 G71.2 Q200 X15.0 Z-1 D0.04 I0.5 R1 M2

[andypugh]

If there is an endless loop then it needs to be fixed. It has been sat in my inbox waiting to find time.

[BSHoekstra]

No worries Andy. Thank you. Yes the information I provided does create an unresponsive endless loop and until you become proficient at using the G7X command there's a high likely hood that most users will find this bug at some point. So I hope it can be fixed. I'll gladly stay engaged to provide any information needed to help resolve it.

Also, BTW Andy, you helped me with Carousel for an ATT about 1 month ago. The ATT is up a running under Carousel and is working great on my lathe...and I mean working perfectly! Thank you very much! I am really enjoying not having to manually change tools. :)

Have a nice day,

Barry

[sundtek]

Barry, do you remember did it only turn out to an unresponsive endless loop or also eat up memory? Axis end up with 1.8 gb before I killed it. Unfortunately I don't remember what I've done wrong, but I think I forgot to retract X at the end of it.

[BSHoekstra]

Sorry for the delayed response. I'd be happy to simulate it again and let you know what I find, but I'm not sure how to check to see if the non-responsive loop also ate up memory. I'm pretty good with computers so if you don't mind providing a little direction on this I should be able to figure it out and get you an answer.

Thank you,

Barry

[sundtek]

Hi Barry,

I'm also still getting into this here, once I'm 100% firm with the G7x codes I'll have a closer look at faulty g71 g-code paths again.

I have another G71 issue here:

is there a way to slow down the part in the yellow box of following screenshot: https://i.snipboard.io/AyOfm6.jpg (I'm using 2x g71 cycles here)

When using the parting tool it quickly runs into the material - while the Z axis feed rate across the part would be okay the X feed rate seems to be just too quick (I made some special screws today and stumbled over that issue... with aluminium I did not notice that). Certainly I could set the global feed rate for the movement slower but that doesn't make much sense since only the part in the yellow box seems to be an issue.

[BSHoekstra]

Yes, I've run into the same issue. It would be nice to independently control the Z-Axis and X-Axis feed rates within the G7X code but so far I have not found a way to do that. Hopefully the LinuxCNC G7X code development team will please put that on the wish list. For now though I'm just grateful to have the G7X code built into LinuxCNC. :)

The issue is that for shapes requiring X-Axis gouging to start a cut prior to turning on the Z-Axis feed, the X-Axis gouging cut needs to be done at a slower feed rate than the Z-Axis feed rate for turning. Especially for materials harder than Aluminum. Albeit that this isn't an issue if the start of each G7X cut is past the Z+ end of the working stock next to the tail stock where there is no material to cut on the X-Axis move.

My work around solution for hard materials has been to start the cut by making a relief groove by using G01 and X, Z coordinates at a slower feed rate. Then once then there is a open space in the working stock for the cutting tool to fit into then use the G7X code at a higher global feed rate.

If someone has a better solution please let us know.

Good luck,

Barry

[sundtek]

Barry, are you an experienced machinist?

The 45° entering path should be eliminated and 90° should be used I would say The exit path would be okay as it is since there's nothing there.

so there would be 2 things that have to be done

• 90° / or it should be possible to define the angle for entering
• end entering feed rate

I had a look at the code it doesn't seem to be so difficult

[BSHoekstra]

LOL...No worries. Yes I am a very experienced and well aged CNC machinist. I think we got off track though. Let's go back to the 2 issues at hand that I hope can be addressed in LinuxCNC G7X G-code programming.

1) High Priority: LinuxCNC goes into an infinite Loop when running the G7X program shown in my 1st post. LinuxCNC should either run the program, or as a minimum kill itself automatically and display an error message.

2) A Nice to Have: It would be nice to have separate feed rates for the X and Z axis when using the G7X G Code.

Have a great day,

Barry

[sundtek]

Hi Barry,

I'm having a look at the code (and I'm going to test some modifications).

Can you also comment my previous post? Is this something that should be addressed that way or do you have any better suggestion? Regarding the nice to have, I think the separate feed rate might not be enough no?

Markus

[BSHoekstra]

I agree there are several ways to address cutting the profile defined in my simple G-Code example without putting LinuxCNC into an infinite loop so I'm not really concerned about finding the best approach. I'm really just trying to point out that I found a bug in the G7X programming that the development team may want to consider resolving before releasing this version of LinuxCNC as a stable version. So I provided an example of my finding trying to help.

Hope that helps.

Thank you,

Barry

[PatrikTegelberg]

Barry This g71 solution for LinuxCNC does left to right if you need it, and does a few other tricks. https://forum.linuxcnc.org/20-g-code/39400-sharing-g71-remap

[BSHoekstra]

Thank you for sharing this information because knowing this difference in functionality should be of help to the developers working on building the G71 code into Linuxcnc 2.9.

I used the G71 remap for about 4 months and agree it works really well. As for the G71 code built into Linuxcnc 2.9, I've been using it since April 2021 and it works really well too except for the 2 minor bugs that I pointed out in my post on May 3, but these 2 minor bugs are easy to work around once you know they are there. I certainly recommend Linuxcnc 2.9.

Have a great day,

Barry :)

[PatrikTegelberg]

Barry Nice to hear from you. I just missed you on the forum when you were looking for g71, I tried establishing a connection with your profile but it did not work.

When you say you used “the” remap it tells me you did not use my remap. It has nothing to do with “the” remap as I programmed mine from scratch. I also preferred to use something built in but it was not tool compensated so I must give up on that. And if you ever want to do rounded corners between radii or angled surfaces you can just type q3 and it will blend with radius 3 between any two surfaces. I sound like a salesman and I don’t like that so if you ever decide to try it out, I don’t want you to pay. I only want you to not miss out.

Best wishes Patrik

[BSHoekstra]

Hello Patrik. You have an awesome talent to successfully scratch build code for the complex G71 program. I went through the remap program that I used line by line to understand how it worked. So, I honestly appreciate the work you did. I can build code from scratch but have not done anything quite that mathematically complex. I envy your talent.

You are correct, I have not used your remap program. The G71 remap I used, I believe was programed by Andy Pugh. When I get free weekend, I'd like to check-out your remap program and compare it to 2.9. To be honest though, I'm not sure where to go to download it.

One comment you made, confused me. You mentioned that the G71 built in version to 2.9 was not tool compensated. Can you please provide more detail on that because I have been able to tool compensate for different length tools loaded in my lathe tool turret in all 3 directions, X, Y and Z? I am obviously am missing something here.

Thank you.

Have a nice evening,

Barry :)

[PatrikTegelberg]

Barry I am flattered, thanks. In the forum link I posted above (edited), first post has the download files attached. Regarding the tool compensation, I am not talking about tool length, I am talking about tool radius. Stock removal and roughing must be tool radius compensated or the finishing cut will have uneven cut depth. This is extra pronounced when turning a non-monotonically increasing profile. A modern CNC lathe has tool radius compensation for canned cycles. I wanted it so I built it in my g71. You have a nice evening. It's 05:17 AM here. Let me know if you test it.

[sundtek]

Yes, I've run into the same issue. It would be nice to independently control the Z-Axis and X-Axis feed rates within the G7X code but so far I have not found a way to do that. Hopefully the LinuxCNC G7X code development team will please put that on the wish list. For now though I'm just grateful to have the G7X code built into LinuxCNC. :)

The issue is that for shapes requiring X-Axis gouging to start a cut prior to turning on the Z-Axis feed, the X-Axis gouging cut needs to be done at a slower feed rate than the Z-Axis feed rate for turning. Especially for materials harder than Aluminum. Albeit that this isn't an issue if the start of each G7X cut is past the Z+ end of the working stock next to the tail stock where there is no material to cut on the X-Axis move.

My work around solution for hard materials has been to start the cut by making a relief groove by using G01 and X, Z coordinates at a slower feed rate. Then once then there is a open space in the working stock for the cutting tool to fit into then use the G7X code at a higher global feed rate.

If someone has a better solution please let us know.

Good luck,

Barry

I have turned some SS416 today and some S15C steel today, the SS416 steel looked a little bit better but the S15C was not good at the lead in part of G71 it looked more like a cone (also since the sticks are very small and easy to bend).

How about introducing some new flags to G71?

I'd say: J for dwelling (after the first lead-in / dive command) L for dive feed rate (first command that runs into the stock)

I have implemented both here and the commands just work fine for me.

As far as I've seen the dive in happens at rapid speed here (unless I did some mistake on my debugging); if it's really like that it's a serious bug. my debug output was:

-4 2.3 rapid move -4 2.12 rapid move -8.23 2.12 straight move

My X-Axis is slow luckily and I'm only diving a very small amount.

attached some code sample for dive_dwell... the L parameter should be changed to some double value. I did not use any swap feature yet

dive_dwell.diff.gz

[petterreinholdtsen]

I gave the G-code in https://github.com/LinuxCNC/linuxcnc/issues/1146#issue-875042977 a go in the axis_mm sim. I did not expect this, but just by opening the file linuxcnc started using a lot of memory. I did not get as far as trying to run it before my machine started trashing.

[petterreinholdtsen]

I discovered the rs274 generate an endless stream of commands from your G-code program, and wrote a test suite test to trigger the problem. Perhaps it can be the first step in finding a fix for it.

[BSHoekstra]

I made some interesting observations by changing the X value in the gcode posted originally in this topic string that may be helpful in resolving this issue but at the same time, I might have discovered another issue involving Graphic and / or program Resolution....not sure.

1st Observation (Ref. picture below)

1A) Linuxcnc works okay for values X5 and X7. In this case G71.2 “sees” a raised edge when looking down the Z-axis at the part being cut.

1B) However, when using X8 or X10 the G71.2 Linuxcnc goes into an “infinite do-loop.” In this case G71.2 DOES NOT “see” a raised edge when looking down the Z-axis at the part being cut.

1C) So I’m wondering to solve this problem if a few lines of code could be added that would check for a raised edge, and if no raised edge was found then the code would produce an error message stating that no defined raised edges (or rather "pockets") were found to cut.

2nd Observation (Ref. picture below) There appears to be graphic and/or progam resolution issue because X8 should have produced a shape very similar to X7. Instead the shape shown using X8 is identical to the shape produced with X10 with the exception that the edge of the part parallel to the Z Axis shows is moved out further in the graphic by 2mm.

Note: The graphics as shown below were produced by commenting out G71.2 and making G71.1 active.

Another way to explain my thought is that if G71.2 doesn't "recognize" any rasied edges / pockets given the part shape and direction of cut, then linuxcnc goes into an "infinite do loop". Given my limited knowledge of programing I would think that a few lines of code could be added as a 1st step to check for 0 raised edges / pockets and if none are found then have G71 generate a comment message stating that no defined raised edges (or rather "pockets") were found to cut. This is shown graphically below.

[andypugh]

I think this is now fixed.

[BSHoekstra]

Hello Andy. Thank you for working on this; however, I just updated to Linuxcnc version 2.10.0-pre0-2069-g9de3c86d, and the original issue still exits. The simple part profile code shown below puts Axis into a non-responsive "do-loop" and the only way to recover is to use "xkill."

G21 G18 G54 (G21 metric, G54 coordinate system 1, G18 ZX plane, G54 coordinate system) G49 (G49 cancel tool length offset) G90 G92.1 (G90 abs dist mode, G92.1 Reset coord sys offset) G94 G64 p0.001 (G94 Feed Mode=Units per Minute, G64p Best Possible Speed p=Motion Blend Tolerance) G8 (Diameter Mode = 7, Radius Mode = 8) G91.1 (G91.1 = Relative Arc Offset Distance)

O200 SUB ;Change the next line from G01 X10 Z0 to G01 X5 Z0 and Axis works fine but this isn't the part profile I need. G01 X10 Z0 G01 X10 Z-14 G01 X3 G01 X7 Z-22 O200 ENDSUB

F225 ;G71.1 Q200 X15.0 Z0 D0.04 I0.5 R1 G71.2 Q200 X15.0 Z0 D0.04 I0.5 R1 M2

Thank you,

Barry :)

[petterreinholdtsen]

[BSHoekstra]

Hello Andy. Thank you for working on this; however, I just updated to Linuxcnc version 2.10.0-pre0-2069-g9de3c86d, and the original issue still exits. The simple part profile code shown below puts Axis into a non-responsive "do-loop" and the only way to recover is to use "xkill."

Sad to hear the fix is not complete. I notice your new G-code fragment commented out the G71.1 call and only use the G71.2 call. Guess we will need to add another test case to our self testing collection. :)

-- Happy hacking Petter Reinholdtsen

[BSHoekstra]

No worries. I really appreciate everyone's time spent on resolving this issue.

I realized after some additional testing that there were actually 2 issues described in issue #1146. Unfortunately, my testing this morning surfaced a 3rd issue. If these 3 issues should be logged separately, please let me know and I'll gladly enter them. The 3 issues were as follows:

1) ISSUE 1 (The original issue): Axis goes into an infinite "Do Loop". The following simple code below produces this error.

G21 G18 G54 G49 G90 G92.1 G94 G64 p0.001 G8 G91.1

O200 SUB G01 X10 Z0 (Change this line to G01 X05 Z0 and Axis works fine but this isn't the part profile I need.) G01 X10 Z-14 G01 X3 G01 X7 Z-22 O200 ENDSUB

F225 G71.2 Q200 X15.0 Z0 D0.04 I0.5 R1 M2

I believe the issue might be that G71.2 does not "see" a rising edge on this part when cutting from Right to Left so can't deal this, whereas when cutting from Left to Right in does "see" a rising edge and the progam works okay as descibed in the graphic below.

2) ISSUE 2: Graphics Resolution Issue. When the X value is X8 (Ref. the comment line in simple code below), the graphic is not corrrect. The graphic shows a straight horizontal line parrallel to the Z-axis. Instead the graphic should show a sloped line similar when the X-value is X7 or X5.

G21 G18 G54 G49 G90 G92.1 G94 G64 p0.001 G8 G91.1 f500 O200 SUB G01 X10 Z0 (Change the X value to X5, then X7, then X8 and then X10) G01 X10 Z-14 G01 X3 G01 X7 Z-22 O200 ENDSUB

F225 G71.1 Q200 X15.0 Z0 D0.04 I0.5 R1 M2

**3) ISSUE 3: Graphic refresh issue. This issue can be reproduced by following the description in the comment line in the simple code below.

G21 G18 G54 G49 G90 G92.1 G94 G64 p0.001 G8 G91.1 f500 O200 SUB G01 X5 Z0 G01 X5 Z-14 (First, display the graphic using X-value X5. Now change the X-value to X7 and click the "Refresh" button. This works. Now change the X-value to X5, save the progam with the same name and click the "Refresh" button. The graphic will not refresh. Now click "File", "Recent File" and Click the file name. The graphic updates correctly. ) G01 X3 G01 X7 Z-22 O200 ENDSUB

F225 G71.1 Q200 X15.0 Z0 D0.04 I0.5 R1 M2

Thank you,

Barry :)

[sundtek]

The loop happens in

void g7x::pocket(int cycle, std::complex location, iterator p...

while(p!=end()) {

the end will never be reached, the memory grows quite a bit here (3gig) afterwards I killed it.

I'll have a further look at it tomorrow.

[sundtek]

I'm not into G71.x I mainly use G71 only here. Would adding "G01 X15" at the end of O200 solve the problem? Is that what would be expected?

[BSHoekstra]

Would adding "G01 X15" at the end of O200 solve the problem? The answer is both Yes and No.

Yes, that very well may be the easiest, best and only solution to this issue. It is certainly an acceptable and practical solution, especially since it is always good practice to pull the cutting tool off the surface of the work piece after the G71.2 cycle is completed, which that command line does. However....Is that what would be expected?

Yes, this particular shape would cut correctly and Yes the program would work.

However, the answer of No for both questions above is because it is not necessarily intuitive to know to add a line at end of O200 to pull the cutting tool back to a position greater than or equal to X10 (in this particular case). For example, the work piece was cut down to X7 in this program so maybe I know that good practice is to pull the cutting tool off the surface of the work piece after the G71.2 cycle is completed, but I only want to pull the cutting tool back to say X9. So, I would insert "G01 X9" at the end of O200 which unfortunately would cause the progam to go into an infinite do loop and I would not know why (i.e. Note that "G01 X10", "G01 X15", or "G01 X20", can all be used at the end of O200 without causing the progam to go into an infinite "do" loop, but anything less than X10 triggers the infinite do loop. Note in this case, X10 is the starting diameter of the 1st pocket when cutting from right to left and in this case, there is only one pocket, but if there were multiple pockets, then the last line in O200 has to be greater than or equal to the starting diameter of the 1st pocket when cutting from right to left.)

Also, even an experienced G-code programmer may forget to add the line of code at the end of O200 to pull the cutting tool off the work piece surface.

Please note that I am NOT suggesting that Linuxcnc be programed to automatically know to pull the cutting tool back at the end of the G71.2 cycle to a position greater than the starting diameter of the 1st pocket when cutting from right to left. The G-code programmer needs to know to add this line of code with correct paramaters to make the G71.2 cycle work if that is the solution.

So given this, if the issue cannot be solved, then I'm hoping that, maybe as a minimum, Linuxcnc could be programmed to produce an error message and/or display an error code with a helpful suggestion on how to resolve the issue versus just going into an infinite do loop.

I hope this was helpful.

Thank you,

Barry :)

[andypugh]

I am a bit confused by some of this. This test: https://github.com/LinuxCNC/linuxcnc/tree/2.9/tests/interp/g71-endless-loop is currently passing in LinuxCNC 2.9. And is your exact code, even including the comment.

How are you testing? Have you built the latest 2.9.1 from source?

[BSHoekstra]

How are you testing? Have you built the latest 2.9.1 from source?

To update Linuxcnc, I used sudo apt-get update and then sudo apt-get upgrade. The current version on my machine is 2.10.0-pre0-2069-g9de3c86d. The test code is correct in your link was correct, but this code goes into an infinite do loop on the version I'm running. Should I be using a different method to upgrade Linuxcnc?

Thank you,

Barry

[sundtek]

Do you expect it to operate until X7 or X15 with your g-code (without the X15 line at the end)? I'm also using linuxcnc 2.10 pre

The endless loop / memory growth is not acceptable as it is. I'm sure I had this too in the past but I got used to retract.

[andypugh]

The 2.10 deb 2069 was built on 1sth October, and the fix was put in after that. Unfortunately 2.10 is failing the tests step at the moment, so the buildbot is not publishing the debs. Which OS are you running?

[sundtek]

I just updated and rebuilt it - yes the loop and memory leak are gone but the result is not good either, now the entire procedure doesn't work properly anymore with that g-code

Linux linuxcnc 4.19.0-11-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux

[BSHoekstra]

Which OS are you running? Debian Buster Release 10 Do you expect it to operate until X7 or X15 with your g-code (without the X15 line at the end)? No. I will always have a tool retract line as the last line of the Sub-routine, but I have to admit, there are times that I forget to include it....just old age probably and then I get the endles do loop. Also, I really can't think of a plausible scenerio where I would not retract the tool greater than or equal to the starting diameter of the 1st pocket.

However, I would think this issue would trip up newbees just like it did me at first, and you'd expect to at least get an error message for some quick he;lp on what to do.

Thank you, Barry :)

[sundtek]

So we just assume that the stock size should be X15

[BSHoekstra]

So we just assume that the stock size should be X15? I'm not sure where you are going with the questioning so I hesitate to provide a definite yes or no answer. As you know the stock size can be any diameter. So, the X15 is just for this specific example.

It's really up to the machinist as to whether to start the cutter at either, 1) A greater diameter than the nominal stock size to true it round on the 1st pass, or 2) Make the 1st pass a "deep" cut. Therefore, in this specific case the actual stock size can be larger or smaller than X15. The example shown graphically below has the stock less than the starting point of the cutter. Again to avoid the do-loop, the cutter only has to be retracted far enough to clear the diameter of the 1st pocket which in this case is 10mm on the radius.

[sundtek]

I think it should be solved that way: G71 is issued with an initial X, layers should be removed step by step from that point on. If the machinist wants to get in deeper first (without taking off layers) he needs to issue a G0/1 to that position outside of G71.

In case the entire cycle is not closed (last segment doesn't go back to X-start) an error could be printed, or optionally close the cycle automatically.

The current existing fix is not good since it just produces a nonsense path (the contour and doesn't proceed with the actual slices)

[BSHoekstra]

G71 is issued with an initial X, layers should be removed step by step from that point on. If the machinist wants to get in deeper first (without taking off layers) he needs to issue a G0/1 to that position outside of G71. Agree.

In case the entire cycle is not closed (last segment doesn't go back to X-start) an error could be printed, or optionally close the cycle automatically. Agree. Either solution will work. The error message provides more control and flexibility, but the error message must be worded well to avoid being confusing. The automatic return to the starting X position, listed in the G71.2 command, to close the cycle should work well too, as long as the code DOES NOT also automatically return to the cutter to the starting Z position listed in the G71.2 command.

[andypugh]

I just updated and rebuilt it - yes the loop and memory leak are gone but the result is not good either, now the entire procedure doesn't work properly anymore with that g-code

Linux linuxcnc 4.19.0-11-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux

What tool path do you expect? The onscreen preview looks reasonable to me, but that is without a deep understanding of how the cycle is meant to work (I built a remapped version in Python, but that was many years ago)

[BSHoekstra]

Andy, I agree the cutting path looks good on the graphic. If you'd like, I'd be happy to test it on my CNC lathe and provide comments, but I'm not sure how in Debian Buster to update to the version of Linuxcnc that you are using. If you don't mind directing me a little, I'm sure I could figure it out though.

Thank you,

Barry

[andypugh]

The simplest way to get the exact LinuxCNC version that I am showing is to download this .deb: http://buildbot.linuxcnc.org/dists/buster/2.9-rtpreempt/binary-amd64/linuxcnc-uspace_2.9.1.3.g6684382de_amd64.deb

The install it with sudo apt-get install ~/Downloads/2.9-rtpreempt/binary-amd64/linuxcnc-uspace_2.9.1.3.g6684382de_amd64.deb

This will replace your installed version of LinuxCNC with the latest release (which hasn't actually been released yet). This shouldn't be a problem as I hope and expect that this release contains only improvements.

[BSHoekstra]

I rebuilt to version uspace_2.9 per your directions and the test case ran perfectly on my CNC Lathe. Having the tool retract automatically to the original X starting point at the end of the G71.2 cycle works just fine, and should not present any issues to machinists.

Thank you for resolving this bug!! :) Your time and talents spent on this, was very much appreciated.!

Thank you again!

Let's call this issue closed!!! :)

Have a good one,

Barry :)

[BSHoekstra]

Andy.....Okay I just realized after some more testing, that you actually hit a Grad Slam on this one! ! :) By fixing this bug, you also resolved the other 2 graphics issues described previously in this chain of conversation under this issue! WOW! Thank you! Thank you!!! :)

Give yourself a pat on the back!

So, let's call, all of these issues closed! :)

Have a good one,

Barry :)

[andypugh]

I can't claim the credit, the fix came from the orginal programmer, Mark Van Doesburg.

[BSHoekstra]

Thank you Mark and thank you to everyone else involved!

Have a nice day,

Barry :)