CNC Lathe and 4th-axis milling...

[JoshM]

It's a cleaner copy, and I'll attach as an OpenOffice .odt file in a subsequent Post, as it's easier viewing, and then, I'll add the .FSTD files used for this thought experiment... I'll


Thoughts on 4th-Axis Milling Development:
I started this in a PM with Sliptonic, somehow lost it trying to post it before, and am gonna try to put some notes together here toward future development. This is in response to Brad's post to Realthunder, about lathe and 4th-axis implementation, where he linked to a video. He got me thinking, so don't blame me ...

I'm gonna try to re-write this as directly as possible. That said, it's not a super simple discussion, so forgive the length.

I'm not an expert in either lathe or 4th-axis milling, but have some direct experience with each on desktop Taig CNC machines, hand-coding Jobs. I've been interested in harnessing the power of FreeCAD Path workbench to bear on these tasks as hand-coding is cumbersome. I hope this can provide a place for others with interest and expertise to chime in so we can develop a vision for the functions.

I am not fluent in Python, but I do program (8051 assembly, PIC C), and one good path to functional code is job definition. My goal is to define some concepts, to make sure we're on the same page, then lay out some ideas, and hopefully get others input and feedback, then Flowchart what 4th-axis and lathe program(s) should do.

To Start:
A 4-Axis mill has the addition of a rotary 4th A-axis, in addition to the X, Y, and Z axes, often parallel to the X-axis, and driven by a stepper motor through reduction gearing. This provides accuracy, resolution, and torque, but limits speed. In theory, any job that can be done on a lathe can be done with a 4-axis mill, though practically, the torque introduces practical demands on fixtures, cutting strategies, and Feed rates and cut depths. The limited speed of the A-axis limits true "Turning" to very light cuts--at peril of dislodging stock from chuck-jaws.

Following, I will differentiate between how 4th-axis mills and lathes, axes nomenclature typically differs. So, where discussing a 4th-axis mill, X,Y,Z, and A have one meaning, and when discussing a CNC lathe, the X, Z, and A axes labels have another.

Necessary 4th-axis Milling Considerations:
The speed and torque of 4th-axis milling, along with the possibilities for chuck interference, requires developing job dependent strategies. Following is a list—by no means complete—of questions that might likely be used to develop job strategies:
Does the job use both a Head-Stock and a Tail-Stock?
If no Tail-Stock, which end is unconstrained? This impacts:
Cuts that reduce mid-stock may limit further cuts further from the Head-Stock by weakening the stock.
This often means making multiple passes, adding milling time.
The ability to cut below Z-origin at the unconstrained end.
Cuts are typically axial, towards the Head-Stock, to avoid dislodging the stock from the chuck.
This adds milling time, but doesn't require a full Y-axis face cut for each rotation as that would be counter productive by:
Cutting materially indiscriminately.
Cutting over space already milled at other angles. Consider make four cuts, at 0, 90, 180, and 270-degrees, but over the entire Y-axis of the stock. That would cut away most of a cylindrical shape, but it isn't efficient to do as a general strategy.
Some cuts require a radial cut for finish or other reasons, but it might require judicious consideration to achieve success.
Is the A-Axis Feed-rate adequate to use turning tools, or is it limited to milling using the Spindle?
This limits threading options.
This limits boring options.
This limits end drilling.





CNC Lathe Turning Considerations:
Typical lathe operations are fundamentally 2-axis machines. The axes label are usually differently.
X-axis now called Z-axis.
Y-Axis now called X-axis.
Z-Axis is generally not used, and the A-axis provides rotational motion, typically parallel to the Z-axis. Ideally, it provides angular feedback to the CNC Controller, allowing threading to start at the same location for multiple passes.
If the conceptual lathe stock is modeled as a 3D Cylinder, centered concentrically along the Z-axis, held in a chuck at one end, presenting a flat circular end:
Tools are held at a fixed height and angle, and are moved along the Z and X axes.
Movement is performed, along the Z and X axes, toward or away from the Head-Stock, allowing Profiling interpolations of arcs, fillets, chamfers, etc...
Tools may also be brought to bear against the end of the cylindrical stock, using Z-axis motion, to allow operations such as:
Center Drilling
Boring
Other lathe operations load a fly-cutter in the rotating spindle, and move a fixed stock against it. This, and other more advanced techniques—such as milling on the lathe—are not address further in this post, but I encourage anyone with expertise to please comment.
Cuts

Provided is a picture, from MechanicalEngineeringBlog, which is linked. This depicts a typical lathe configuration, including the axes nomenclature.

Path Work Bench Capabilities:
Currently, 4th-Axis milling is essentially unimplemented. Brad/Sliptonic mentioned thinking it might require OCL, and truth told, I had the same impulse, so the other day, I tested that out in a limited way as follows, and am attaching an image of the result.

I generated a 3D model targeting a lathe job—with exception of the square base—and saved it.
I modified a copy of this model, targeting a 4th-axis-example job, by adding an axial projection, and chamfered though-holes in Part Design WB.
I made nine simple copies in Part WB and rotated them at 5-degree intervals around 0-degrees, then offset the copies along the Y-axis to allow multiple rotational cuts to be viewed side by side.
The Parts are centered on the Z-origin.

About 30-45 minutes after I hit Apply on 3DSurface Apply, I had results for nine rotational cuts, +/-20 degree cuts around 0-degrees, albeit with excessive actual local Y-axis activity. That is, cutting all the way to the Z origin on each rotational pass.

This is non-ideal—especially considering the rest of the cuts, and finer resolution—but, it illustrates some of the challenges, and certain aspects of the Job. Hopefully it illustrates that for the shop including both CNC lathe and 4th-axis milling, there are jobs better suited to each, and considerations on how to differentiate between them.

The implications of Realthunder's post about FeatureArea, are still beyond me, but I hope to someday understand it.

One thing I've thought I noticed, and I wondered if it applied here, is that PathFromShape doesn't always appear to curve-fit edges, as other Operations (Contour, Profile(s), MillFace, Pocket, 3DPocket, etc...) do, and the G-Code it generates doesn't often issue G2 or G3 arc commands, rather all G1 linear interpolations of arcs, which bloats the code size, and adds processing and postprocessing overhead.

FreeCAD is agnostic about axes, and functions, so there should be no inherent reason that it can't. In looking at it, I'm confused though, because using it on an XY example gave me all G1 codes, but I did the same test on an XZ oriented shape, and perhaps I've misunderstood, because it used curves appropriately. I used the Inspect-GCode tool to view the PathShape3D G-Code.

Suggestions On How To Proceed:
So, I've outlined the issues, and now I'm going to make some suggestions. Keep in mind I have limited FreeCAD experience, and am not a DEV, but I'm trying to demonstrate a few concepts.

A couple of things:
The Stock diameter suggests the extent of the maximum possible Y-axis motion envelope if this brute force method of calculation is used.
This also defines the maximum Y-axis excursion envelope that can be used where it is beneficial to the job.
My instinct is that there is a relatively quick pathway to develop this for someone fluent in Python, and familiar with the Path workbench algorithms, once the details are ironed out.
Lathe cuts are a subset of 4th-axis, because of their symmetry, and


Take the 3D model I used as an example to play with 4th-axis milling. It's essentially a modified chess pawn, with an rotational projection, at 0-degrees, and a chamfered through-hole at 90-degrees out. Here's what I did:
Made a simple copy in Part WB.
Performed a Cross-sections operation with 1 Section, of XZ-plane, with no offset Position. This completes in appropriately 3 seconds.
Performed a Cross-sections operation with 30 Sections, on Both Sides, of XZ-plane, with no offset Position, generating symmetrical 2.5mm slices across the entire Y-Axis. This completes in about 30 Seconds.
This generates a Body—actually, for some reason, two identical Bodies. I think this happens for each Apply, plus another on OK.
These resultant Bodies can be used in Path WB PathFromShape tool, to generate G-Code that is correct with these exceptions if not others:
There is extraneous info in the Section created Body due to what is below the top Z-axis envelope—ie, the circle for the through-hole drill operations in profile, and the bottom half of that Section.
There is no Tool-Controller associated with the Operation.
There is no Tool geometry compensation.
There are a lot of B-Spline approximations—at least in the bottom half, because they are gone once I manually edit the Sketch to remove the bottom half, then add a line across the bottom to close it, and make a Path WB Job, and realize I made a mistake.
To further this test, I:
Shifted to Draft WB:
Performed a Draft2Sketch.
Manually edited the Sketch to remove the lower section., Added a closing wire across the bottom.
Upgraded the Sketch to Wire.
Switched to Path Job, added a tool, and used the PathFromShape tool. The result was even closer, though the bottom wire should have been removed, and somehow Rapids would have to be added.
So, to better the result, I:
I redid the test, by redoing the model, removing the bottom line, and adding lines going up and across where Rapids should occur, to close the Sketch.
Upgraded it from the Draft WB.
Made the same Path WB Project, from the new WIRE, and it's even closer.
The takeaway:
In theory, what I have so clumsily illustrated should be able to be done behind the scenes in Python, generating Axial code at 1-degree, or even 0.1-degree resolution, then adding other Operations to complete contours around Radial projections, etc...
Each single-Section operation performed in the Part WB actually captures 0-degree and 180-degree, etc... If it's possible to salve the two split halves and remove extraneous interior information.
Each single-Section operation performed in the Part WB if it doesn't significantly change from the previous version could be stored as a canned cycle performed at a different A-axis angle.
If a Cross-section changes significantly from that captured at the previous angle, then it may merit increasing Cross-section number for certain spots.
If the model can store what has been removed when calculating what remains to be done, that would increase milling efficiency.
Storing all possible 4th-axis information for maximum Y-axis envelope increases GCode geometrically, and same with calculation time required.
Tool geometry, not simply tool tip compensation is necessary. However, what Path WB currently does is generally useful, because if I rotated that example 90-degrees, making a PathPocket Operation, with radial tool compensation, that would be what's needed for the end of a BallEndCutter, and only for the top contour. However, other tool geometries would require further development—which is true of Path WB now anyway.

I'm going to attach this Document and also grab content to post in this thread.

Best Regards,
Josh

[JoshM]

Attached here are some of image files used above.
-Josh

[JoshM]

Attached.

[chrisb]

Pheeww, that's a lot of stuff, probably the longest post ever. So I start with rather formal stuff.
First question: Is there any additional information in the attached document? I could not detect any, but if so you wouldn't have it attached .

Others may have better capabilities, but for me there is too much different stuff in this post. It is about turning, 4th axis milling, unexpected G-Codes, clamping, OCL and more. Perhaps it is better to split all this into several topics.

Now to some of the contents:
You talk about the sequence of milling operations, e.g. when a part of the milled object becomes too thin to hold it for the rest of the milling procedure. This is of course interesting but I see this in the far future to be done automatically. Now it is the person creating the FreeCAD Job who is responsible.

As for OCL: If we want to go that way I think it is more interesting in the near future to intregate different tools than to go for 4th axis milling now. As far as I have seen in the OCL documentation it should be possible to calculate paths respecting the shape of the tools, so an end mill will produce a slightly different path than a ball head mill or a chamfered mill.

[JoshM]

Pheeww, that's a lot of stuff, probably the longest post ever. So I start with rather formal stuff.
First question: Is there any additional information in the attached document? I could not detect any, but if so you wouldn't have it attached .

Othqers may have better capabilities, but for me there is too much different stuff in this post. It is about turning, 4th axis milling, unexpected G-Codes, clamping, OCL and more. Perhaps it is better to split all this into several topics.

Now to some of the contents:
You talk about the sequence of milling operations, e.g. when a part of the milled object becomes too thin to hold it for the rest of the milling procedure. This is of course interesting but I see this in the far future to be done automatically. Now it is the person creating the FreeCAD Job who is responsible.

As for OCL: If we want to go that way I think it is more interesting in the near future to intregate different tools than to go for 4th axis milling now. As far as I have seen in the OCL documentation it should be possible to calculate paths respecting the shape of the tools, so an end mill will produce a slightly different path than a ball head mill or a chamfered mill.

Hey Chrisb,
No, same info, just that formatting makes it easier to read.

And, yes, sorry, it’s a lot. My goal is to highlight a future roadway, by indicating the practical inputs required to generate usable output. I also wanted to demonstrate that FreeCAD already contains the tools needed to generate the GCode for the Job, it just needs patching together.

Unfortunately, my takeaway is that OCL is problematic for this job type.

Timing isn’t ideal I know, but I think it’s a worthy goal because of the value added by the ability to tackle complex 3d shapes. If this does nothing short term, but someone finds it helpful in six months or more, better to have it written.

Best,
Josh

[sliptonic]

I've been through this a couple times too and there are still a few things I'm not clear on. As you noted, a 4th axis operation can get complicated for a lot of reasons so let's focus this discussion on a the simplest true 4th axis case for now.

The model you're showing is a good example. It's mostly cylindrical, requiring work from a continuous set of angles. But it has features that make it unacceptable for a lathe operation.

In my mind, the simplest 4th axis operation has to do two things;

The cutter is going to move in the XZ plane so first the operation has to rotate the part incrementally through that plane.

snapshot-1.png (43.8 KiB) Viewed 8477 times

At each incremental step, the operation has to find the wire along the part perimeter which the cutter is going to travel in order to produce the resulting profile. (Of course the operation will have to produce multiple wires for the step-downs but we're keeping things simple here). An infinitely small tool would simply follow the part profile like below but since the real tool has a diameter, the actual wire will be offset from the profile and this offsetting is the whole game.

snapshot-2.png (7.01 KiB) Viewed 8477 times

Once those wires are found, turning them into Path commands and gcode is trivial.

The big snag is finding that wire. If I read your original post correctly, you're using the 3DSurface operation to do this. 3DSurface is using OpenCamLib's dropcutter algorithm. This will work and can be optimized a LONG way by limiting how much of the part you surface. OpenCamLib has the disadvantage of license incompatibility (discussed many times here) but otherwise a good choice

If you're suggesting something other than OpenCamLib as a solution, I'd like to hear it. PathArea won't work for this purpose and I don't think there's anything in OCC either.

[JoshM]

I've been through this a couple times too and there are still a few things I'm not clear on. As you noted, a 4th axis operation can get complicated for a lot of reasons so let's focus this discussion on a the simplest true 4th axis case for now.

The model you're showing is a good example. It's mostly cylindrical, requiring work from a continuous set of angles. But it has features that make it unacceptable for a lathe operation.

In my mind, the simplest 4th axis operation has to do two things;

The cutter is going to move in the XZ plane so first the operation has to rotate the part incrementally through that plane.
snapshot-1.png

At each incremental step, the operation has to find the wire along the part perimeter which the cutter is going to travel in order to produce the resulting profile. (Of course the operation will have to produce multiple wires for the step-downs but we're keeping things simple here). An infinitely small tool would simply follow the part profile like below but since the real tool has a diameter, the actual wire will be offset from the profile and this offsetting is the whole game.
snapshot-2.png

Once those wires are found, turning them into Path commands and gcode is trivial.

The big snag is finding that wire. If I read your original post correctly, you're using the 3DSurface operation to do this. 3DSurface is using OpenCamLib's dropcutter algorithm. This will work and can be optimized a LONG way by limiting how much of the part you surface. OpenCamLib has the disadvantage of license incompatibility (discussed many times here) but otherwise a good choice

If you're suggesting something other than OpenCamLib as a solution, I'd like to hear it. PathArea won't work for this purpose and I don't think there's anything in OCC either.

Sorry--it's not a tidy post for sure...

I only mention OCL to show that I think it is not a great option--and because both you and I had that initial impulse. Unless the interface between PathWB and OCL can be tuned to look at as narrow a Y-envelope as needed to achieve a full X-axis axial tool-path, it will be too computationally intensive. So, the Y-envelope would be => than the tool-diameter, for all rotational angles on that 3D model, but only where the radial projection makes it a non-lathe operation does is it > than the tool-diameter. It would still issue a series of G1 polygon approximations of arcs.

My take was that Part WB cross section appears to provide the necessary wires, in excess, but with manipulation already existent in FreeCAD, it's relatively trivial to arrive at the PathWB GCode output.

Where I started with this a couple of weeks ago--in conception, is that the existing Pocket3D can already do most of what is needed, but it can't be applied to a 3D model like I provided as typical for the job. If you rotated the model, and were able to take slices including the Y-envelope, but limited to a factor of >= 1 Tool diameter, it could be adapted.

To illustrate that, I took the same 3D model, and on the top where the radial projection exists, I made a 11mm wide symmetrical slice, allowing an 1/8" diameter tool to pass around the 5mm wide radial projection on either side. I then cut the bottom half off. there's a small error with the bottom through-hole, but as you can see, the existing Pocket3D can then do a reasonable job of processing the most challenging part of the Job. Most of the rest would be identical passes, except where the through-hole exists, and the transitions into and out of the angle I am showing... Note, I added a -1.5875mm Pass-Extension to cut to the edges of the slice.

4th_Axis_Example_Sliced_Pocket3D.png (137.08 KiB) Viewed 8470 times

This is still not following the axial contour, but is interesting to me because it leverages existing Path WB function that you developed.

Also, my goal isn't to make an Operation like Surface3D, but more like the other Path Ops, where the User can achieve a goal, but may be required to guide the strategy though multiple operations to achieve desired results. For example, I would suggest on this Job to use a Drill operation to do the through-hole. The game played here with axial slices can be done with radial slices too, and my guess is the combination would give clean results. One thing about this, is you really don't want to attach the step down linearly for finish passes. The image shows that my step-down will produce rough results with this pass, but you want fine step down at the sphere and, and along the details, but after roughing passes remove the bulk material that needs multiple bigger step-downs for torque limits, not cutting resolution...

Is that any help visualizing this?

Josh

[sliptonic]

I only mention OCL to show that I think it is not a great option--and because both you and I had that initial impulse.

So far, it's the only option I'm aware of.

Unless the interface between PathWB and OCL can be tuned to look at as narrow a Y-envelope as needed to achieve a full X-axis axial tool-path, it will be too computationally intensive.

I believe it can easily do exactly this.

My take was that Part WB cross section appears to provide the necessary wires, ...

This I don't see....yet. But I'm listening.

Where I started with this a couple of weeks ago--in conception, is that the existing Pocket3D can already do most of what is needed, but it can't be applied to a 3D model like I provided as typical for the job. If you rotated the model, and were able to take slices including the Y-envelope, but limited to a factor of >= 1 Tool diameter, it could be adapted.

To illustrate that, I took the same 3D model, and on the top where the radial projection exists, I made a 11mm wide symmetrical slice, allowing an 1/8" diameter tool to pass around the 5mm wide radial projection on either side. I then cut the bottom half off. there's a small error with the bottom through-hole, but as you can see, the existing Pocket3D can then do a reasonable job of processing the most challenging part of the Job. Most of the rest would be identical passes, except where the through-hole exists, and the transitions into and out of the angle I am showing... Note, I added a -1.5875mm Pass-Extension to cut to the edges of the slice.

4th_Axis_Example_Sliced_Pocket3D.png

This is still not following the axial contour, but is interesting to me because it leverages existing Path WB function that you developed.

Also, my goal isn't to make an Operation like Surface3D, but more like the other Path Ops, where the User can achieve a goal, but may be required to guide the strategy though multiple operations to achieve desired results. For example, I would suggest on this Job to use a Drill operation to do the through-hole. The game played here with axial slices can be done with radial slices too, and my guess is the combination would give clean results. One thing about this, is you really don't want to attach the step down linearly for finish passes. The image shows that my step-down will produce rough results with this pass, but you want fine step down at the sphere and, and along the details, but after roughing passes remove the bulk material that needs multiple bigger step-downs for torque limits, not cutting resolution...

Is that any help visualizing this?

Ok, I think I'm getting my head around your idea and yes, the this description helps. I think this could work as a roughing operation but I believe it will leave material behind that the tool could, in theory, remove. I don't think you can ever actually profile the part with the tool this way which means we still need an operation based on OpenCamLib (or similar) to get that functionality and if we had such an operation, it could do roughing as well.

I'd love to see you do a proof-of-concept on this.

[JoshM]

I only mention OCL to show that I think it is not a great option--and because both you and I had that initial impulse.

So far, it's the only option I'm aware of.

Unless the interface between PathWB and OCL can be tuned to look at as narrow a Y-envelope as needed to achieve a full X-axis axial tool-path, it will be too computationally intensive.

I believe it can easily do exactly this.

My take was that Part WB cross section appears to provide the necessary wires, ...

This I don't see....yet. But I'm listening.

Where I started with this a couple of weeks ago--in conception, is that the existing Pocket3D can already do most of what is needed, but it can't be applied to a 3D model like I provided as typical for the job. If you rotated the model, and were able to take slices including the Y-envelope, but limited to a factor of >= 1 Tool diameter, it could be adapted.

To illustrate that, I took the same 3D model, and on the top where the radial projection exists, I made a 11mm wide symmetrical slice, allowing an 1/8" diameter tool to pass around the 5mm wide radial projection on either side. I then cut the bottom half off. there's a small error with the bottom through-hole, but as you can see, the existing Pocket3D can then do a reasonable job of processing the most challenging part of the Job. Most of the rest would be identical passes, except where the through-hole exists, and the transitions into and out of the angle I am showing... Note, I added a -1.5875mm Pass-Extension to cut to the edges of the slice.

4th_Axis_Example_Sliced_Pocket3D.png

This is still not following the axial contour, but is interesting to me because it leverages existing Path WB function that you developed.

Also, my goal isn't to make an Operation like Surface3D, but more like the other Path Ops, where the User can achieve a goal, but may be required to guide the strategy though multiple operations to achieve desired results. For example, I would suggest on this Job to use a Drill operation to do the through-hole. The game played here with axial slices can be done with radial slices too, and my guess is the combination would give clean results. One thing about this, is you really don't want to attach the step down linearly for finish passes. The image shows that my step-down will produce rough results with this pass, but you want fine step down at the sphere and, and along the details, but after roughing passes remove the bulk material that needs multiple bigger step-downs for torque limits, not cutting resolution...

Is that any help visualizing this?

Ok, I think I'm getting my head around your idea and yes, the this description helps. I think this could work as a roughing operation but I believe it will leave material behind that the tool could, in theory, remove. I don't think you can ever actually profile the part with the tool this way which means we still need an operation based on OpenCamLib (or similar) to get that functionality and if we had such an operation, it could do roughing as well.

I'd love to see you do a proof-of-concept on this.

OK, so we're gaining common focus it seems. When you say "proof of concept on this", do you mean in Python, or using existing FreeCAD tools with images/files, as we've been doing here so far?

One thing I'm still unclear about is determining the offset.

If I rotate that same example to the XY-plane, then I can do a Contour, and the code for the "top" side where cuts need to be made are correct, but the GCode is in the Y-plane for the Z...

4th_Axis_Example_Sliced_Pocket3D_RotatedToXY_Plane.png (135.48 KiB) Viewed 8450 times

I do still think the Part Work Bench Cross Sections is worth exploring, but I'll come back at that in a bit--gotta run out for a couple of hours.

[sliptonic]

When you say "proof of concept on this", do you mean in Python, or using existing FreeCAD tools with images/files, as we've been doing here so far?

If it were me, the next step would be a macro script that does the basic algorithm. Don't worry about all the options or even generating gcode. Just generate wires. I would proceed like this:
Enable the experimental features so you can play with 'feature area' Feature area is a swiss-army tool for manipulating PathArea. Everything that feature area can do in the gui can be done with PathArea dircetly in a macro.

Next, hand-model a solid that will correspond to your slice volume.
Create a 'feature area' from the original model and the slice volume and play with the settings until you understand how PathArea is doing its magic.

Once you have that, it should be pretty easy to write a macro that iterates through the rotation steps and generates the slice volume automatically and drives PathArea to do the same thing your were doing manually with the feature area in the gui.

One thing I'm still unclear about is determining the offset.

If I rotate that same example to the XY-plane, then I can do a Contour, and the code for the "top" side where cuts need to be made are correct, but the GCode is in the Y-plane for the Z...

I don't think this will work at all. Translating a contour in XY to a XZ won't work because you're not translating the cutter as well. Generating a contour offset correctly in this orientation. I mean you can easily generate the offset and then rotate the wires but the offset will now include collisions. This should be clear but if not, let me know and I'll do a graphic.

PathArea has two modes; offset and pocketing. What I understood is that you intended to build a pocket of each slice. If I'm wrong in my assumption, we need to back the horse up.