Waterline machining proposals

Here's the place for discussion related to CAM/CNC and the development of the Path module.
chrisb
Posts: 25155
Joined: Tue Mar 17, 2015 9:14 am

Re: Waterline machining proposals

Postby chrisb » Thu Nov 01, 2018 11:02 pm

You are right. My desire to get clean GCode comes probably from the beginnings of Path workbench, when it was only an aid to generate GCode, but not a fully integrated environment. If the complete toolchain was just a black box where I can input a FreeCAD model and get machine movements out, I could not care less about some intermediate GCode.
herbk
Posts: 1814
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Waterline machining proposals

Postby herbk » Fri Nov 02, 2018 7:22 am

Hi all,
if we are talking about accuracy of gcode against calculating time... about what number of digits behind the decimal we are talking...? ;)

@ Chris: What do you have in mind with "clear gcode"?

@ Markus: only 2 kB at the machine controller? I have a obselet hp with LinuxCNC here, you can have it.
Gruß Herbert
chrisb
Posts: 25155
Joined: Tue Mar 17, 2015 9:14 am

Re: Waterline machining proposals

Postby chrisb » Fri Nov 02, 2018 10:00 am

herbk wrote:
Fri Nov 02, 2018 7:22 am
@ Chris: What do you have in mind with "clear gcode"?
mainly what I said above: no tesselation in the GCode. All circles remain as such, lines are not composed of multiple lines of same orientation, arcs are not composed of multiple arcs of same center and diameter.
Furthermore usage of special cycles for drilling, pocketing, ... would improve things further.
GeneFC
Posts: 1205
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Waterline machining proposals

Postby GeneFC » Fri Nov 02, 2018 1:56 pm

I think there are two somewhat separate concerns.

* Economy of G-code

Some controllers are limited in storage space, so G-code for an arc is best as G2/G3 rather than a series of short G1 moves. This is mostly independent from the final accuracy and precision of the path. My linuxcnc setup runs on a general purpose computer with "infinite" memory, so that is of no concern for me. I do understand the limitations some controllers may impose.

* Precision and accuracy of the final path

I disagree with the suggestion that the final control of accuracy and precision can be equally divided between the code and the physical capability of the machines. In the metrology world there is a working standard called the "Gaugemaker's Rule" that says the accuracy and/or precision of the measurement instrument should be 10X better than the required limits of the object being measured. In that case the measurement can be trusted, with effectively no "sharing" of the errors.

In the same manner I believe the G-code should be 10X more accurate/precise than the required limits on the final object. In my case I try to achieve 0.001 inch (0.025 mm) control as a goal (not always successful :( ), so I want the G-code to be good to 0.0001 inch (0.0025 mm). For very expensive commercial quality tools those limits might be ten times smaller.

Clearly, few people would want the Path WB calculation to take many minutes or hours for simple shapes. At the same time most people do not want visible tessellation artifacts or dimensional errors in their finished products.

Gene
JulianTodd
Posts: 57
Joined: Tue Oct 23, 2018 3:35 pm

Re: Waterline machining proposals

Postby JulianTodd » Wed Nov 07, 2018 8:03 pm

I've moved the discussion of how to make a generic NEWOP operation that can be used as a template for any further machining operation
https://forum.freecadweb.org/viewtopic.php?f=15&t=32103

That means I can finish making the point about tolerance and using triangles for all machining operations vs the so-called perfect accuracy of running against the parametric surfaces.

Here's a more pragmatic explanation of why it is so.

Out in the real world of commercial CAM systems we first write all the algorithms in terms of the approximate triangulated surfaces (approximate to whatever tolerance you want), because the basic functions of toolshapes colliding with flat triangles can be written in a short amount of time. And then we ship those algorithms. And they work for every shape.

Now, suppose someone says they want the machining to happen on the "real" surfaces, instead of these crappy triangles. Well, a CAD system has dozens of different parametric surfaces. Which one do you want us to start with? You've got your conics, spheres, cubic splines, offset surfaces, bezier patches, NURBS surfaces -- any one of which can be trimmed along intersection curves. The mathematics for each of these gets progressively desperate.

One manager had the simple-minded idea that, since NURBS surfaces could fit any known CAD shape (except offset surfaces) with perfect accuracy, we should convert everything into NURBS surfaces, and then we'd only need to write the toolshape colliding with the surface function for only one type of surface!

Have you ever tried to find the intersection between a toolshape and an arbitrary NURBS surface of the 9th non-uniform rational order with an indeterminate number of folds? Can't be done. You need to run approximation/iterative methods.

But, hey, we've already solved this problem for a toolshape and a triangle, and we can instead convert everything into triangles (to an approximation). Will this do for now?

Turns out it's good enough for anyone if they don't want to wait five years for us to write it. It's an obscure enough thing that even if a CAM system did successfully work to the "true" surfaces, you'd hardly be able to tell. So all of this works against this feature ever becoming a priority in the real world.
mlampert
Posts: 1463
Joined: Fri Sep 16, 2016 9:28 pm

Re: Waterline machining proposals

Postby mlampert » Thu Nov 08, 2018 1:32 am

JulianTodd wrote:
Wed Nov 07, 2018 8:03 pm
And then we ship those algorithms. And they work for every shape.
I cannot tell you how much I am looking forward to this change. For a while now I had the feeling our current approach has reached its potential and the number of edge cases, special cases, do's and don't's doesn't seem to quiet down. I'm sure there's gonna be pain, but I'm also sure it'll lead to a better, robuster and extensible Path workbench.
User avatar
sliptonic
Posts: 1782
Joined: Tue Oct 25, 2011 10:46 pm

Re: Waterline machining proposals

Postby sliptonic » Thu Nov 08, 2018 4:07 am

mlampert wrote:
Thu Nov 08, 2018 1:32 am
JulianTodd wrote:
Wed Nov 07, 2018 8:03 pm
And then we ship those algorithms. And they work for every shape.
I cannot tell you how much I am looking forward to this change. For a while now I had the feeling our current approach has reached its potential and the number of edge cases, special cases, do's and don't's doesn't seem to quiet down. I'm sure there's gonna be pain, but I'm also sure it'll lead to a better, robuster and extensible Path workbench.
+1
User avatar
JoshM
Posts: 420
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline machining proposals

Postby JoshM » Fri Nov 16, 2018 2:26 am

Hey Julian,
Thrilled to see your post. I've looked at this for about a year now and have just recently given up.
Now, suppose someone says they want the machining to happen on the "real" surfaces, instead of these crappy triangles. Well, a CAD system has dozens of different parametric surfaces. Which one do you want us to start with? You've got your conics, spheres, cubic splines, offset surfaces, bezier patches, NURBS surfaces -- any one of which can be trimmed along intersection curves. The mathematics for each of these gets progressively desperate.
Illustrating your point:

Simplest case the sphere. The top hemisphere is able to be milled, the bottom isn't. A Square-Endmill "finish" surface toolpath is simply radially offset by the tool radius. For a BallEndMill, the center of the ball is the tangential offset of input geometry. For a CornerRoundMill, it's a mix of the two--use the corner-radius to for the ball, then offset by the flat-radius. For a ChamferMill--not that it makes much sense--the CuttingEdge Angle defines the angle to the x-axis, that is the maximum point, before the tool violates the surface. For a Cylinder, the same applies relative to the arc around the surface-axis.

Real-world, three limitations occur to me as significant: Collet Clearance, Shank-Clearance(Shank radius greater than cut radius ), and Length-Of-Cut Limitation. For the first two, there's measurable radius, but I would suggest adding a clearance envelope. I zero my tool-tip but the insertion depth into the Collet may vary. Similarly, the top shank clearance may enjoy a small margin.
Sphere0.png
Sphere0.png (186.08 KiB) Viewed 516 times
Above image is a typical example of why I say that. It''s a 15mm radius Sphere. The collet is modeled as a 14mm radius which is about what I use on a "desktop" cnc. The tool is a 3.175mm Ballnose tool with a 6.35mm shank. Here, the entire sphere can be milled with a reasonable collet clearance. But, with a 25mm radius, the result is:
Sphere1.png
Sphere1.png (182.79 KiB) Viewed 516 times
The calculation to avoid by a specified distance is trivial.
Sphere2.png
Sphere2.png (232.51 KiB) Viewed 516 times
By specifying a 3mm collet clearance--the radius line from surface center to collet corner, the path depth is limited.

That all holds for a cylinder surface that is horizontal. Where the result is a revolved surface on a sphere, its's a a loft between two arcs for cylinder and more generally cones. Once the cylinder/cone is rotated, the tool surface is again a radial/tangential offset, but the Collet/Shank interference calculation is the same as sphere PLUS the interference calculation for a Plane-Surface. Plane-Surface is itself trivial.

Toroids are theoretically the same as cylinder, but swept around the major radius--while keeping the arc tool response aligned to the z-axis. It makes FreeCAD unhappy with the result shape. This isn't a trivial issue because fillet surfaces are a very typical thing to mill.

As you said--far more succinctly--that is just the beginning of the complexities. Each case is straightforward, but it's overwhelming in its totality...

I know your post with pic is early pass, but I notice that there are red paths shown in the bottom arc carve out, which for 3-axis would violate the model. Is there a 2nd pass that constrains that, or was that for 5th-axis project?

Current Tool definitions don't adequately define a tool 3d tool. I suspect most people use Diameter across the board. I would assume Flat-Radius should be used for tool cutting tip, diameter should be the shank. For a ball, Corner Radius for the ball, Diameter for shank. The tool-definition/manager definition GUI doesn't work that way. Also, it doesn't allow angle input on chamfer. There are a couple of other little issues I ran across.

The suggestions I have for PathWB are:
1) Use "typical" tool definitions for inputs. Length Of Cut, love it or hate it, is a common term. Radius is great for calculations, but tools are bought and referenced to by diameter. I went through McMaster-Carr, MSCDirect, Harvey Tools, and a few other distributers to try look for common terms. I apologize if this differs for other countries--my sampling wasn't exhaustive. I want to avoid confusion about what parameter relates to what from real world tool to PathWB Job.
2) The one relatively trivial thing that I have done is a first pass at constructing a 3d model from the Job-->ToolController->Tool definitions. Where the definitions don't exist, I've "hard coded" which is why a gap is exhibited between the shank and transition to cutting edge displayed in above images.
3) What is important to me about having a 3d model of the tool definition is that it can show incorrect inputs in a very obvious way if the script builds doesn't collapse from errors for missing inputs, but doesn't "cover" for them by best-guessing to cover. My preference is be able to check tool model definitions visually within the contexts of the ToolManager->Add/Edit, or ToolController->ToolInstanceDefinition.
4) It seems like the more practical approach you are defining using meshes often are applied across the entire Job Model. I think it is important to define the 3d space that a tool is allowed to interfere (cut), but the strategies of how to cut that space are a modularly separate task. Roughing, finish, avoidance are all significant. I investigated where a ChamferMill begins to violate a sphere not because I have any interest in milling a sphere with a Chamfer, but because it's reasonable to assume I might want to mill a mold with a shape that transitions from a chamfer to a fillet, etc...
5) I enjoy the atomic aspect of the way that PathWB works, and hope that improvements retain that. Similar to above, I like the ability to select/deselect faces/edges for operations. The complaint I've had with OCL is that left unconstrained, it is indiscriminate about roughing/finish/tool/fixturing/etc... At work, we use PathWB, and appreciate that the entire job isn't attempted unbounded. The learning curve in my experience is less steep with the existing PathWB approach--in terms of the user retaining responsibility to define the job inputs, tools, and operations. I like the ability to order the operations. In an ideal world, I should look at my post-processor to check/notify if I'm tool-changing back/forth to same tool. Occasionally it's necessary, more often, I've messed up my operation order.

One last observation. PathWB Job contains ToolControllers, which include a ToolDefinition. The specific definition might be the default or added when the Job is created, or added later from the ToolManager. It is common for multiple Operations to share a common ToolController. It is also common for multiple ToolControllers to share a common Tool. This is because of roughing/finish, Feeds & Speeds in TC inputs. It wouldn't make sense to process same model twice if finish and roughing are performed with same Tool.

I apologize if I've hijacked. I realize that these are things you've clearly thought through and already figured out. Where I've stated preferences or made suggestions, I don't mean to sound demanding. I'll take anything that gets more 3d model to GCode workflow and say thank you very much. Just thought I'd try to throw what I hope are a constructive 2-cents :) ... BTW, if you haven't already, scroll through Path-Forum topics and a couple common themes crop up. Ability to do a non-closed loop single edge. Inability to over-cut a partially open pocket.

Best Regards,
Josh
user1234
Posts: 238
Joined: Mon Jul 11, 2016 5:08 pm

Re: Waterline machining proposals

Postby user1234 » Sun Nov 18, 2018 12:51 am

Hello!
JulianTodd wrote:
Wed Nov 07, 2018 8:03 pm
But, hey, we've already solved this problem for a toolshape and a triangle, and we can instead convert everything into triangles (to an approximation). Will this do for now?
As far as i know quite every CAM programm makes in the NC program only small lines (G01). And if the mill tool drives a "perfect" contour, you have theet, a feed rate and a rotating tool --> makes also small lines. The only thing to attend: the coordinates should 10 times more precise than the coordinate system on the machine (or expected result). Like GeneFC said before. So i would say, it will absolutly do this!

Sorry for bad english.

Greetings
user
GeneFC
Posts: 1205
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Waterline machining proposals

Postby GeneFC » Sun Nov 18, 2018 3:37 pm

user1234 wrote:
Sun Nov 18, 2018 12:51 am
As far as i know quite every CAM programm makes in the NC program only small lines (G01).
That is not correct. Arcs made with G02/G03 are very common. The machine controller has a bit more work to do for trajectory planning, but that code is much more economical for program memory space.

Gene