Proposed cut pattern updates: PR #4965

[Russ4262]

Evening Pathians,
My current project is ready for some testing if you would like to try it out. The current set of cut patterns have a number of bugs within the linking of paths. PR #4965, [Path] Implement new path generation class, makes a number of long over-due fixes to the current set of cut patterns for PocketShape, MillFace, and 3D Pocket(EDIT: Pocket, not Surface[yet...]). and adds a few new ones.

Here are details copied from the PR:

• Path: Numerous cut pattern fixes and upgrades
• Path: Fix cut direction fidelity for Line, ZigZag, ZigZagOffset, Offset, and Spiral
• Path: Fix cut patterns for Offset and Spiral
• Path: Add additional cut patterns: Circular, CircularZigZag, LineOffset, and Adaptive**. **Adaptive cut pattern is generated by a more condensed version of algorithm in current Adaptive operation, but is not implemented at this time due to additional requirements extraneous to this commit.
• Path: Apply updated patterns to three PathAreaOps: PocketShape, MillFace, and 3D Pocket
• Path: Current Grid and Triangle patterns will still be provided by Path.Area() and Path.fromShapes() combination similar to what is currently active. The other cut patterns, except Adaptive, are generated with a new PathGeometryGenerator class.
• Path: Two new cut strategy modules added: PathStrategyClearing and PathStrategyProfile. The latter is not implemented yet, but ready to be connected to the Profile operation. The former contains a new PathGeometryGenerator class that seeds, edits, and links the cut patterns.
• Path: Add 24 unit tests dedicated to testing cut patterns generated with new PathStrategyClearing module. Patterns tested are Line, LineOffset, ZigZag, Circular, Spiral, and Offset. Each pattern has four individual tests: 2 for cut direction and 2 for pattern reversal.
• Path: The new cut patterns have additional features available for customization, but are not implemented in this PR. Additional properties are necessary for access to these features. These features include selection of a pre-set pattern center, a custom pattern center point, and the capability of dynamic centers for 3D Pocket. Also, alternating patterns could be implemented, as well as pattern rotation with each layer.
• Path: Correct Dogbone unit test to use current Profile operation instead of current proxy of old ProfileFaces operation that was merged into current Profile op.
• Path: A new PathSelectionProcessing module is added. It contains numerous geometry manipulation functions, as well as: 2D target shape builder, 3D target shape builder, and open edge shape builder classes. This commit does not implement this module completely, rather is provided due to dependencies in this commit. This module and its contents are functional.

This PR also contains additional code improvements via new classes that are not implemented or utilized within this PR. This PR focuses on cut pattern correction and improvement. Additionally, this PR includes 24 individual unit tests to check many of the cut patterns.

The cons:

• The `MinTravel` feature is disabled.
• The `KeepToolDown` feature is disabled.

It is my intention to re-enable these, but I need some assistance to determine the intended behavior of each. I have some ideas about how they are intended to behave, but have not included any active coded related to them. I am asking you, the experienced community, for some feedback related to these two features so that I can re-implement them in this PR, or another successive PR.

I am attaching a simple script, with its intended target model file, to run on top of this PR that will generate the cut patterns on a grid of raised faces in the model file. You will need to create a default Job object based on the Fusion object in the model file, before running the script. A screenshot of the script result is attached.

Edit 2021-08-22: Update pattern test macro to reflect changes in PR today.
Edit 2021-09-15: Update testing macro script to version 3.0.

Thanks for your contributions to the development of this great software.

Russell

[memfis]

Great news, thank you!

I probably missed a lot and if it's possible - please post here Mod/Path archive for downloading and tucking any version (build) of FC (especially since git makes it hard to login for authorization, and how the intelligence of google and microsoft works is already appreciated by many).

Regarding the lifting of the tool - in each job I run into this and manually delete such codes in the editor.
Typical situation - processing Pocket, offset strategy - to the remaining small zones the transition is made with tool raising. I appreciated that FC different layers (processing levels) Z performs alternating order (not the same) when creating such jobs. Of course, in cases where the transition to a small zone does not touch edges and is performed over previously machined areas, there is no need to lift the tool and the move can be performed as G0. In cases where it does not touch an edge, but goes over an unworked area, it should go as G1. And in any case the combination can change when moving down from G0 Z[H_safe] + G1[Z_count] to G0[Z_count + Z_safe] + G1[Z_count]. Since the G1Z velocity is usually much lower than the working velocities on the XU.
However, a simple, quick and necessary correction is in cases where you set the tool approach and retraction without raising the tool - here you just need to replace G0 with G1.

[GeneFC]

The cons:

• The `MinTravel` feature is disabled.
• The `KeepToolDown` feature is disabled.

It is my intention to re-enable these, but I need some assistance to determine the intended behavior of each. I have some ideas about how they are intended to behave, but have not included any active coded related to them. I am asking you, the experienced community, for some feedback related to these two features so that I can re-implement them in this PR, or another successive PR.

I am away from my main processing and machining capabilities for a while, so I cannot perform a proper test right now. However, these two items caught my attention.

I have never used the "MinTravel" feature, and I am not quite sure just what it is supposed to do.

I use the "KeepToolDown" feature all the time. I understand that it can be dangerous in some cases, but it is very useful in others. Is this removal a coding issue, or just a safety issue? If the latter would making default "unchecked" be just as effective?

In any case this entire PR looks like a lot of really great cleanups!

Thank you.

Gene

[Russ4262]

... I have never used the "MinTravel" feature, and I am not quite sure just what it is supposed to do.

I use the "KeepToolDown" feature all the time. I understand that it can be dangerous in some cases, but it is very useful in others. Is this removal a coding issue, or just a safety issue? If the latter would making default "unchecked" be just as effective?
...

Overall, removal is just a coding issue, but not for inability per say, rather, a not knowing with certainty the intended behavors.

`MinTravel` suggest efficiency between clearning areas - a sorting of sorts related to the `Traveling Salesman` dilemma.

`KeepToolDown` is a little less clear for me. I do not know to what extend the tool should be forced to stay down. There are a number of transitions where this could be applied, for example:

• in ZigZag patterns, in the transition between zig and zag, keeping the tool at cut depth
• as raise only to previous cut depth when transitioning between regions in a single cut area
• as raise only to previous(or other depth beside clearance/safe) between cut areas in the same operation
• likely other transitions that I missed above

I just need some guidance as to the intended behavior so I can code accordingly.

Thanks to all for the feedback.

Russell

[memfis]

I believe, but because of the language barrier I can hardly describe it accurately, that a tool lift is necessary only when we risk touching the non-processed (in this operation) areas. And when we don't lift the tool, there are two options - G0 or G1. G0 can be used when the cutter goes over an already machined surface. And G1 can be used when the cutter goes over the virgin surface. In all cases MinTravel is very useful.
Excessive up and down passes (when raising and lowering the tool) can still leave unnecessary traces on the work pieces, even on perfectly rigid machines (in cases of woodworking it can even lead to burning of such places).

[GeneFC]

`KeepToolDown` is a little less clear for me.

I typically see the issue when clearing a pocket. I normally use the "offset" pattern. What happens without Keep Tool Down is that the cutter makes a single loop, then it rises to safe or clearance height, and then it comes right back down in the stepover location to start the next loop.

In this case there is no danger from much of anything. I would rather have the cutter move sideways into the new loop instead of rising and then plunging.

There are of course many more complex cases where Keep Tool Down may not be advisable. That is why I like the option. A default of "unchecked" is fine and should satisfy any safety concerns.

Gene

[Russ4262]

Evening Sir.

... There are of course many more complex cases where Keep Tool Down may not be advisable. That is why I like the option. A default of "unchecked" is fine and should satisfy any safety concerns. ...

Have started work on re-enabling `Keep Tool Down` functionality. Have preliminary work done for ZigZag, ZigZagOffset, Offset, and CircularOffset. I need to run some more tests to include path inspections, as well as look at other included cut patterns that need the functionality added. Once I am okay with preliminary results on my end, I will ask the community for additional testing. I am in agreement with the default being unchecked/disabled.

At the moment, I have not touched the `Min Travel` functionality, leaving it disabled. I will need some community input to better understand its purpose and behavior. My reading suggests the property/functionality and origin is related to RealThunder's implementation of `Path.fromShapes()`. It looks like it has to do with region/area sorting when dealing with mulit-region/area target shapes, or when a target shape decomposes into multiple independent regions as depths progress downward.

Thanks for the helpful explanations and feedback.

Russell

[GeneFC]

I will need some community input to better understand its purpose and behavior.

At one time in ancient history I believe the min travel controlled the starting location for subsequent depth layers. For example a pocket might start in the center for layer 1 and then at the outside for layer 2 and then back at the center for layer 3. The idea was to minimize non-cutting travel time.

This has not really functioned since realthunder totally reworked the PathArea module several years ago. The new module replaced the old HeeksCAD libarea module. There was some discussion on the forum at that time. He acknowledged the issue, but he became consumed with the topo naming problem and did not spend a lot of time on this relatively minor issue. The inside/outside start remains somewhat random.

I personally have no concern about the "time", but it would be nice to restore the consistent behavior of start inside vs. start outside. I suspect it is not simple to do.

Gene

[Russ4262]

... At one time in ancient history I believe the min travel controlled the starting location for subsequent depth layers. ...

Make sense. That sounds about like what I read in a forum post from around 2017-2018-ish. I think we can repeat that behavior if so desired. I also think there is additional efficiency to be coded that would minimize travel, such as clearing individual appendages off a core region instead of doing one pass in each appendage with rapids between just for the sake of following the order of the cut pattern, but I am not going to work on that yet.

... it would be nice to restore the consistent behavior of start inside vs. start outside. ...

I believe this is already taken care of. The current property is `Start At` and has `Edge` and `Center` as options.


Another feature that is not included in this PR is a true start point. Currently in this PR, when a `Use Start Point` is enabled, the machine moves to the start point provided, then to the first point of the first path wire, where ever it may be. However, I think it might be desirable to choose the point on the set of closed path wires (or endpoint of open path wire set) that is closest to the start point provided. So, put another way, the current start point is more of an approach point - the point where the machine approaches the first entry point in the path. I am not sure my explanation makes sense... Anyhow, I have the idea and it might be the intended behavior for the `Use Start Point` feature. If it is the intended behavior, it is not implemented in this PR.

Thanks and have a blessed night.

Russell

[GeneFC]

I believe this is already taken care of. The current property is `Start At` and has `Edge` and `Center` as options.

Yes, this works for the first layer, and it has worked for a long time. The problem with either the Edge/Center or Start At is that the selection is not honored after the first layer. Lower layer cutting patterns appear to follow the "min travel" stategy discussed above.

I just ran a very simple pocket test, with "Start at Center" set, and "Min Travel False". The alternating inside/outside behavior for successive depth layers is still present.

OS: Windows 7 Version 6.1 (Build 7601: SP 1)
Word size of FreeCAD: 64-bit
Version: 0.20.25391 (Git)
Build type: Release
Branch: master
Hash: eef30446aa32ae989d5025cabcd8c28093f6a801
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)

I appologize if I have missed a recent update. As I said above I am not currently in a position to provide a thorough test.

Gene