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...
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.
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:
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.
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.
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.