Not restoring return rapids in linuxcnc turning.cps

[arielnh56]

I just installed this to see if I could remove some tedium. It worked for the facing pass, but not the roughing pass using "linuxcnc turning.cps"

Here's the start of the roughing pass. The Z0.125 should be rapids - clear returns to base.

This is lathe stuff.

(PROFILE ROUGHING3) (RH CUTTER) N105 G54 N110 G97 S1500 M3 N115 G94 N120 G90 G0 X2.8 Z0.125 N125 G1 X1.96 F4.42913 N130 Z-1.792 N135 X2. N140 X2.08 Z-1.752 N145 Z0.125 N150 X1.92 N155 Z-1.792 N160 X1.96 N165 X2.04 Z-1.752 N170 Z0.125 N175 X1.88 N180 Z-1.0111

Thanks for doing this. I'll take a peek at the code and see if

[TimPaterson]

The G-code parsing just uses Python regular expressions and can't handle all combinations of valid input. Only one "G" operation is parsed per line and G, X, Y, Z, F must be in order. The algorithm for setting feed height (program line 1131) is a line with G0 or G1, Z move, no X or Y move. Line N120 is where the feed height should get set, but it violates two of those rules: the G90 hides the G0, and there is an X move along with the Z move.

You could consider making a custom modification to your post processor or to PostProcessAll. I don't see an easy way to fix this for you without risking breaking other scenarios.

[arielnh56]

That sounds to me like the assumption is 3-axis mill. On the lathe - at least on normal cutting passes - the feed is X, not Z, and clearly Fusion is doing something different with the initial placement with G90 and G0 on the same line.

I note that for the facing job it did before this, the utility did kick in. For those, Z is feed and x is cut. I'll take a poke at the code and see if I can get it going.Maybe one operation at a time with a checkbox to say if it is a facing or normal cut.

Thanks for doing this and thanks again for the explanation of how that bit works - it helps a lot.

Alastair Young @.*** 925-784-0812 Server herder, Dalek driver, Ariel rider, Arduino widget maker

On Thu, Sep 2, 2021 at 11:02 AM TimPaterson @.***> wrote:

The G-code parsing just uses Python regular expressions and can't handle all combinations of valid input. Only one "G" operation is parsed per line and G, X, Y, Z, F must be in order. The algorithm for setting feed height (program line 1131) is a line with G0 or G1, Z move, no X or Y move. Line N120 is where the feed height should get set, but it violates two of those rules: the G90 hides the G0, and there is an X move along with the Z move.

You could consider making a custom modification to your post processor or to PostProcessAll. I don't see an easy way to fix this for you without risking breaking other scenarios.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TimPaterson/Fusion360-Batch-Post/issues/23#issuecomment-911929675, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIY4QNFXDRTNBTKPZ257T3T7632VANCNFSM5DIJ6W2A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[TimPaterson]

I forgot to mention, but certainly you've figured out, that I know absolutely nothing about lathe operations. I wonder if there's a reliable way to tell up front if the operation is milling or turning, either through the Fusion 360 API or by the presence of specific G-code. Then it would be easier to tailor the movement optimization for each.

[arielnh56]

Based on the one face-turn-groove-part example I've been working on as my first CNC experiment, I came up with this:

https://github.com/arielnh56/Fusion360-Batch-Post

It gets a lot of the rapids back, though not all I'd like. It did put one in on a boring pass when I was going "both ways", and it added one at the start of the grooving setup that I didn't want, so the code still needs eyeballing before use, but it saves lots of time on the return-to-start for normal linear turning.

[alkabal]

I think we can check the G7 G8 presence for déterminâtes if this is a lathe or not.

[arielnh56]

Indeed. Check out my fork. It mostly works.

On Fri, Oct 8, 2021, 12:48 alkabal @.***> wrote:

I think we can check the G7 G8 presence for déterminâtes if this is a lathe or not.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/TimPaterson/Fusion360-Batch-Post/issues/23#issuecomment-939078608, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIY4QNLBVYJ3SW3A2MQJKDUF5DJTANCNFSM5DIJ6W2A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[alkabal]

Hi

I have try and it seem better for turning.

Can i ask you ti try with setting in your post pro for retract using G53 ?

Best regards