3D Surface - DropCutter - Offset pattern, does it make sense? [Merged]

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

3D Surface - DropCutter - Offset pattern, does it make sense? [Merged]

Post by RatonLaveur »

EDIT 2020.04.20: Topic modified as "Merged" and not a question anymore.

Hi,

I've been playing around with 3D surface to machine gutters and I have found issues that apparently neither waterline nor dropcutter in their current form will solve:

In the screenshot , you will notice that the central area at the bottom of the gutter is left so to speak "unprocessed". In addition the sides technically show a much smaller effective stepover.
Sweep-Waterlin-BottomUnprocessed.png
Sweep-Waterlin-BottomUnprocessed.png (242.09 KiB) Viewed 1860 times
When using a ball end-mill that's probably ok. When using a laser, it is not. In that case the center will be completely unprocessed and the sides will be machined too much.

Circular pattern in drop-cutter mode does not solve the problem either, as it does circle projection on what is a rounded square shape.
Sweep-Dropcutter-Circular.png
Sweep-Dropcutter-Circular.png (497.44 KiB) Viewed 1860 times
The ideal behavior in that case would to have the option for an "offset" pattern in drop-cutter mode. Offset to generate paths that follow the profile. Drop-cutter to maintain constant step-over.

Now whether that makes sense or whether another approach is better to achieve the result, that's open to discussion and that's why I opened this thread.

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20276 (Git)
Build type: Release
Branch: master
Hash: 3a0d9e8c514c163be0b750dd75bb4f2afe4f94f1
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/Switzerland (en_CH)
Attachments
Test_SubtractiveSweep.FCStd
(166.21 KiB) Downloaded 37 times
Last edited by RatonLaveur on Tue Apr 21, 2020 10:17 am, edited 3 times in total.
herbk
Veteran
Posts: 2660
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by herbk »

Hi RatonLaveur,
RatonLaveur wrote: Sun Mar 29, 2020 12:02 am When using a ball end-mill that's probably ok. When using a laser, it is not.
is it the right way to think about milling and lasercutting at one OP? I'm not a friend of this "put all passibilitis at one Box" strategies, because the UI quickly becomes confusing...

Somebody already started a Lasercutting WB (i don't look at it, because i dont have a laser) but in my mind it would be better to separate this machine typs.
Gruß Herbert
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by RatonLaveur »

Well it's equivalent to using a small ball end-mill. The path that i produced was technically for a small end mill. The problem in that case is that waterline will not detect surfaces that are close to horizontal (i.e. center of a gutter). But waterline is the only approach that follows the contour (similar to offset).

This is not "laser cutting" in the industrial sense of the term. Laser cutting is used for 2D operations (sometimes with tilt options), similar to plasma, flame, water-jet, drag knife....etc and may warrant a special workbench. What I'm talking about is milling a 3D shape by following the contour (similar to waterline or offset) and locking a constant stepover (drop-cutter approach).
Russ4262
Posts: 953
Joined: Sat Jun 30, 2018 3:22 pm
Location: Oklahoma
Contact:

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by Russ4262 »

Evening,
The new 3D Surface/Waterline split PR that was merged has an `Experimental` algorithm added. The pre-existing `OCL Waterline` algorithm pulled out into this separate, independent operation is the default algorithm used.

The new `Experimental` algorithm available does not use OCL. It is based off the idea presented by @ChrisB in another topic in February 2019 at
chrisb wrote: Sat Feb 02, 2019 9:22 am This can be very well done in 0.18 as well:
- Use Part->Crossection to create the crosssections in an appropriate distance
- Part->SliceToCompound
- Switch to Path WB
- Create a job with the slice as base
- Create Profile paths, one for each slice, Cut side: outside, StartDepth=FinalDepth

The drawback is, of course, that you have to create a profile for each level. This could be the basis for a waterline algorithm as well.
Basically, a cross-section of the model is created at each step-down and converted to a path. This `Experimental` algorithm has ability to clear each layer and the ability to only clear the last layer. Cut patterns are the same as 3D Surface with an `Offset` pattern added.

As for the idea of a set offset and a set step-down, this only happens on planar surfaces. On the gutters you provided for examples, the offset is not constant at each step-down because the angle of engagement(angle of the model face) changes as the depth changes. In this case the angle of the gutter face is 90 degrees near the top, and progresses to 0 degrees at the bottom most point in the curve. You cannot have a constant stepover(offset) and constant step-down with such geometry.

One must be fixed. If we set the stepover(offset) as constant, then the step-down at the top of the face will be much greater than the step-down on the lower portion of the face. The volume of material the cutter engages is still not constant at each layer around the waterline. Please correct me if I am in error, but isn't the preferred CNC path one that has a constant volume of material engagement as it moves through a path?

I probably need to learn more about what a waterline operation should be and do.

I must note here that the new `Experimental` algorithm:
  • is not fully aware of overhangs, in contrast to the pre-existing OCL version that is aware of overhangs. I have some thoughts on how to solve this without OCL, but I have not had a chance to start down that feature improvement path. The current `Experimental` algorithm should serve some users' needs in its current form.
  • is much faster than the `OCL Dropcutter` algorithm
  • produces much cleaner paths, including G2/G3 commands (It makes use of Path.pathFromShape())
  • exposes some bugs in Path.Area() on occasion that will return faulty paths
  • is, well, `Experimental`, and not ready for main-stream.
  • is only accessible with OCL installed because it is within an OCL-dependent module, even though the experimental algorithm itself does not use OCL.


Another item to mention is the clearing of material between waterlines, where the difference in offsets between waterlines is greater than the cutter diameter. I think this new `Experimental` method will be a good host for identifying this and adding some minor clearing paths to these specific areas that need clearing - I'm not referring to clearing the entire step-down layer, just material greater than the cutter diameter between successive waterlines.

Please keep in mind that the paths being generated by the 3D Surface and Waterline (whether OCL or the new Experimental) are of an analogue-to-digital conversion type. Your gutter is a perfect curve (half circle?). But because we sample it at intervals(step-down), that is like a digital reproduction with jagged edges in the wave form. The best we can do is make those jagged steps as small as reasonably possible to an acceptable tolerance (which you are doing also with the aid of a ball-end mill type cutter). The good news is that FreeCAD is getting better at this, and you are a part of the reason it is getting better! This method reminds me of the machine used to polish the mirror for the Hubble space telescope. The step-down was set to micro, if not nano-millimeters and took many months to complete. I recall them saying the machine was so sensitive that too much traffic nearby could cause interference, and seismic activity was abhorred greatly and required the process to stop.

It is a pleasure and a learning experience working with you, Sir.

So, my follow-up question is what method or approach do you visualize or think would yield the paths you need for this model? Please articulate that process as best you are able.
As I understand the problem with this model is that the upper paths are too close together, and the bottom paths to far apart? So, the lateral shifts are what you want to be constant? Would it be okay then, if the depth varied as the cutter moved around the offset path? I'm just trying to both conceptualize and visualize what your desired paths would look like with the model at hand.

Russ
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by RatonLaveur »

Russ4262 wrote: Thu Apr 02, 2020 2:22 am As I understand the problem with this model is that the upper paths are too close together, and the bottom paths to far apart? So, the lateral shifts are what you want to be constant? Would it be okay then, if the depth varied as the cutter moved around the offset path? I'm just trying to both conceptualize and visualize what your desired paths would look like with the model at hand.
Hi Russ, thank you so much for taking that time to answer, and in such a considerate and detailed ways.

Regarding path distribution, Essentially you nailed it on the head, there are two mutually exclusive options:

-Constant height step: In that case the effect that I describe in OP is to be expected, as the angle varies the lateral engagement changes. Some X/Y areas are therefore less densely treated by the machining process. I can only think, as a remedy, of the same idea you presented, which is to add ad-hoc correcting toolpaths based on the ratio or difference between track separation vs. tool diameter. This can be done. Probably should be done, but this is not my wish. So if i had a say in the matter and since you "gave me the mic", I would say not that, but FreeCAD is a WE project.

- Constant lateral shift (can we talk of "step over" in 3D, this I am honestly not sure): In that case the "new" effect is that the effective height step will vary and that quite a bit. Indeed I can imagine (but I cannot guarantee due to lack of experience) that it is less desirable with a solid tool (end-mill). With a beam tool, this is actually the better option, the vertical "engagement" can be rather high with a beam and more importantly it can be variable, the laws of mechanics do not apply here and I can simply increase/decrease the Feedrate, Power, Pressure, Current, Combustible gas flow (depending on the actual process used) to adapt to generate a higher/lower depth, but if X/Y areas are less treated that is a huge problem.

I would say that adding the ability to choose "constant height-step" and "constant step-over" would suffice, and I actually suspect the two paths can be used "together" to obtain the perfect result for a ball-end mill too. Since the constant step-over would resolve the areas where the height step needs to be low, and the constant height-step will resolve the areas where the step-over needs to be low. Hence I imagine that the resulting 3D shape would be extremely well interpolated. Of course at the moment I'm "only" interested in constant lateral shift. But I'm sure both abilities independently or together will yield positive results for all. There will be no breakage of costly ball-end mills by too high depth-of-cut, and no breakage of costly ball-end mills by too high lateral engagement. I actually do not know how the surface algos deal with that in other 3D CAMs.

I am really looking forward to the new algorithm, it seems that the issues it will initially suffer from (no overhangs...) will be compensated in full by its elegance (quick calculation, smoother toolpaths...) though how "PathFromShape" handles splines I do not know, I admit that so far I mostly kept myself to simple spheres/circles in the original models.

Edit: now that I've had a whole day to think of it, i wonder if constant distance between tracks isn't the ideal. Distance in that case meaning the geometric average of XYZ as in sqrt(dx2+dy2+dz2)....or some variant of that. Thus ensuring constant volume engagement with a ball end-mill as a well as a laser. I may not have thought that through. In which case my input remains " "just" offer the option to keep lateral shift constant"
geant
Posts: 42
Joined: Mon Mar 30, 2015 11:54 pm

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by geant »

For symetrical paths like the gutter, it might be feasible to make the step-down a function of the face slope;
Most other irregular paths (like the ones i encounter) will be stuck using computationallly-exhaustive fractional-step-downs.
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by RatonLaveur »

Actually if you have access to both fixed height step or fixed lateral shift, you can probably mix an match with computationally less expensive rules.
Then again, i'm no wizard and what I suggest may be much more complicated than I think. Probably is.
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

Re: Question: 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by RatonLaveur »

Considering the responses in this thread and the questions raised, I did some more digging on how 3D milling behaves in other advanced CAM software.

From ncgraphics: "Waterline (Z-Level) Machining Using Surface Contact Angles
Waterline passes can be used for semi-finish and finish machining the more vertical areas of a part.

If a slope angle is specified, for example between 30° – 90°, the steeper areas are machined, leaving the shallower areas between 0° – 30° for more appropriate strategies. These passes can be constrained to a boundary or by the selected surfaces. Waterline machining also has the feed-rate optimisation option."


I also communicated with other people experienced in industrial level CAM packages and they explained also that there is no "one size fits all" OP.

For now I still believe that the ability to mix and match between fixed vertical or fixed lateral shift is one way to achieve something a little more robust. It seems that determining slope threshold to switch from one to the other is a way to do that. Although how computationally intensive that would be I cannot tell.
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

Re: [MERGED] 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by RatonLaveur »

ORIGINAL POST EDIT 2020.04.20: Topic modified as "Merged" and not a "Question" anymore.
Russ4262 wrote: Thu Apr 02, 2020 2:22 am
So I took the most recent version for a spin

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20634 (Git)
Build type: Release
Branch: master
Hash: ba34cc6a96c15d64224e8f0c8b5da874f1e03a07
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/Switzerland (en_CH)

Fantastic! We now have Offset pattern (constant step-over) I am giddy a porcupine on roller skates (and about half as graceful generally), but I am grateful.

Now I noticed a couple of things on my original file in OP. Note that my remarks below apply for the Offset and Circular patterns of the 3D Surface op based on dropcutter.

Curve management: It seems that depending on the tool applied (i tried both with a 2 mm end-mill and a 0.1 mm end-mill, inner and outer fillets will behave a bit wonky.
You will see that when using a rather large tool, the outer curves seem to behave. But the inner curve shows a really nice pattern of up and down "crenelation" (due, no doubt, to the vertical projection of the offset pattern on the workpiece.
2020-04-20 22_30_33-FreeCAD 0.19.png
2020-04-20 22_30_33-FreeCAD 0.19.png (49.12 KiB) Viewed 1486 times
.
This effect is a little more pronounced using smaller tools (obviously due sampling more toolpaths on the high slope areas).
2020-04-20 22_31_06-FreeCAD 0.19.png
2020-04-20 22_31_06-FreeCAD 0.19.png (81.87 KiB) Viewed 1486 times
This effect occurs at high or low degrees of mesh refinement as well as high (1 mm) to low (0.02 mm) sample intervals. It also occurs if one is trying using the Convert Coplanar Arcs options (obviously since these are not coplanar, but was worth a shot).
I wonder how one could smooth this out. Or perhaps this is too difficult.

EDIT: After carefully inspecing the G-code generated by this algorithm in the exact corner that I screecapped, I could offer the potential solution of "deciding" that some Z variations are ignored within a certain range based on a threshold (i.e. all variations less than StepDown...or something like that). I wonder how to do that properly so that limited loss in accuracy is incurred while still maintaining a rather stable tool-path and surface finish. Also bearing in mind that this model is only one use-case and that there are probably different use-cases in which such a variation may be preferred....puzzling nut to crack.

Code: Select all

G1 F0.000000 X30.403041 Y13.436875 Z-0.008197
G1 F0.000000 X30.394448 Y13.237081 Z-0.122832
G1 F0.000000 X30.375655 Y13.037988 Z-0.152799
G1 F0.000000 X30.346708 Y12.840116 Z-0.098019
G1 F0.000000 X30.307685 Y12.643982 Z0.000000
G1 F0.000000 X30.258687 Y12.450099 Z-0.082419
G1 F0.000000 X30.199843 Y12.258975 Z-0.145257
G1 F0.000000 X30.131305 Y12.071108 Z-0.123352
G1 F0.000000 X30.053254 Y11.886991 Z-0.016762
G1 F0.000000 X29.965893 Y11.707103 Z-0.032789
G1 F0.000000 X29.869451 Y11.531917 Z-0.128473
G1 F0.000000 X29.764180 Y11.361890 Z-0.139451
G1 F0.000000 X29.650356 Y11.197466 Z-0.065696
G1 F0.000000 X29.528275 Y11.039075 Z0.000000
G1 F0.000000 X29.398258 Y10.887132 Z-0.102575
G1 F0.000000 X29.260643 Y10.742034 Z-0.146432
G1 F0.000000 X29.115791 Y10.604159 Z-0.105541
G1 F0.000000 X28.964081 Y10.473870 Z0.000000
G1 F0.000000 X28.805909 Y10.351506 Z-0.067514
G1 F0.000000 X28.641690 Y10.237387 Z-0.144234
G1 F0.000000 X28.471851 Y10.131812 Z-0.136223
G1 F0.000000 X28.296838 Y10.035056 Z-0.043503
G1 F0.000000 X28.117107 Y9.947374 Z-0.023070
G1 F0.000000 X27.933130 Y9.868993 Z-0.132621
G1 F0.000000 X27.745386 Y9.800119 Z-0.157494
G1 F0.000000 X27.554367 Y9.740932 Z-0.097622
G1 F0.000000 X27.360572 Y9.691587 Z0.000000
G1 F0.000000 X27.164509 Y9.652213 Z-0.111195
G1 F0.000000 X26.966689 Y9.622912 Z-0.168941
G1 F0.000000 X26.767630 Y9.603762 Z-0.141941
G1 F0.000000 X26.567852 Y9.594812 Z-0.030267

Feature management: I was a bit surprised at first using the Offset pattern on my model, due to an interesting behavior for feature detection and handling.
Here you can see
2020-04-20 22_29_18-FreeCAD 0.19.png
2020-04-20 22_29_18-FreeCAD 0.19.png (68.49 KiB) Viewed 1486 times
the "Handle Features Individually" doing exactly what it is supposed to do. Followed by the "Handle Features Collectively"
2020-04-20 22_29_39-FreeCAD 0.19.png
2020-04-20 22_29_39-FreeCAD 0.19.png (65.89 KiB) Viewed 1486 times
being a little more creative. However, if one toggles "Boundary Enforcement" to False, then the world makes sense again. Probably a threshold somewhere playing with our eyes.
2020-04-20 22_29_55-FreeCAD 0.19.png
2020-04-20 22_29_55-FreeCAD 0.19.png (64.54 KiB) Viewed 1486 times
Overall I would say that I'm really excited with these new capabilities, and for my specific use-cases it will be immediately usable as soon as the "crenelation" in the curves is smoothed out somewhat.

The fact that these new patterns do not tesselate as much as the OCL based codes is also a big bonus, I wonder how this was achieved (the toolpaths are extremely smooth when following arcs, which is not the case with OCL). Such tesselations even small can be really detrimental to conventional milling bits as well as to the quality of the resulting surface in any machining process. I wonder how all could be smoothed out. I know that some advanced CNC can transform all these kind of segments into B-Splines. But I wonder how this could be achieved in FreeCAD (for the sake of completeness of the discourse, there was similar talk regarding the Adaptive OP, specifically to try and smooth out the paths into wide G2 and G3 arcs. I'm not sure where the development is on that front).

I'll report again when I have more hours on the different new functions. (currently quite busy in the FEM area of FC).
Russ4262
Posts: 953
Joined: Sat Jun 30, 2018 3:22 pm
Location: Oklahoma
Contact:

Re: [MERGED] 3D Surface - DropCutter - Offset pattern, does it make sense?

Post by Russ4262 »

RatonLaveur wrote: Mon Apr 20, 2020 9:00 pm ...
Curve management: It seems that depending on the tool applied (i tried both with a 2 mm end-mill and a 0.1 mm end-mill, inner and outer fillets will behave a bit wonky.
You will see that when using a rather large tool, the outer curves seem to behave. But the inner curve shows a really nice pattern of up and down "crenelation" (due, no doubt, to the vertical projection of the offset pattern on the workpiece. 2020-04-20 22_30_33-FreeCAD 0.19.png.
This effect is a little more pronounced using smaller tools (obviously due sampling more toolpaths on the high slope areas). 2020-04-20 22_31_06-FreeCAD 0.19.png

This effect occurs at high or low degrees of mesh refinement as well as high (1 mm) to low (0.02 mm) sample intervals. It also occurs if one is trying using the Convert Coplanar Arcs options (obviously since these are not coplanar, but was worth a shot).
I wonder how one could smooth this out. Or perhaps this is too difficult.
...
Okay. I found a part of the issue for this problem. It turns out that a the performance improvements by @etrombly relocated the solid-to-mesh conversion process to the C++ side. Consequently, the `AngularDeflection` and `LinearDeflection` properties now have no effect what so ever in the operation. I have no clue about the meshing process used now on the C++ side. The performance improvements that were merged did cut down significantly the operation compute time, but we lost some control over these two important components of the operation.

We need to research the meshing process that is now in effect on the C++ side and figure out if any settings are exposed to Python and go from there.

Sorry I don't have better news at the moment for this particular issue.
etrombly wrote:ping
sliptonic wrote:ping
Russ
Post Reply