Discussion for detanglement of rotatioal code from existing ops

[Russ4262]

I am to blame for the mess created within the code by the rotational features. As such, I will help fix it.

...
The existing operations code is already a tangle and we're seeing very few contributions from new developers.

Adding 4th axis rotations onto existing operations added great functionality but made the whole thing much more difficult to maintain. We probably should have created entirely new 4th axis operations with cleaner code.
...

Can we agree that the current rotational capability, apart from 3D Surface, is only an indexing rotation, not a full, simultaneous multi-axis rotational 3D path generation?

We need to figure out (or rather I am asking for ideas for) a plan to move forward with code-structure correction while addressing(attempting to maintain) the rotational features developed thus far. One option is to gut the rotational code from current ops in order to restore the original pre-rotational code base, while maintaining other improvements that occurred since. I had started another rotation implementation a long while back, but didn't keep it current. It takes the approach of applying rotation as a pre-process in the `execute()` method of PathOp, to be applied and then pass the re-oriented geometry to the primary operation as is done now.

I don't have hard facts as to what percentage of users are making use of the current rotational features. It is certain that there is a user base interested in the existing rotational features, and more. That said, I understand some will be against gutting the rotational code. I am not suggesting a gut-and-run, rather a gut with improved alternate implementation to follow (or simultaneous replacement).

I'm just looking to get some better perspective and more knowledge than the limited that I have.

Takeaways from this thread (2020-11-25):

• Base ops code should be as simple and maintainable as possible.
• Rotational indexing feature should be available to all base ops. (target goal)
• Solutions presented here will not be committed until next official release after 0.19.
• The rotational indexing code should be self-contained within a single class (target goal)

Pros and Cons of each type of rotational indexing[RI] integration:
Per-Op Integration (current method)

• Pro - RI is automatically included in path generation
• Pro - RI code analyzes Base Geometry (possibly extendable to simultaneous 4 axis simultaneous)
• Pro - Fewer inputs required from user when incorporating RI into the workflow
• Pro - No additional GUI load in Path toolbars
• Con - RI is not currently not editable.
• Con - RI code (or subset thereof for activation) must be added to each op

Independent Op

• Pro - RI is readily available to each operation
• Pro - RI code is independent from all other ops code
• Pro - RI would be manually adjustable, and/or auto set based on independent, selectable Base Geometry.
• Pro - Code can be drastically simplified from current implementation code, removing some of the complex geometrical analysis code
• Con - More inputs required from user when incorporating RI into the workflow
• Con - Additional GUI slot required in Path toolbar

Dressup

• **This option would likely be very similar to the Independent Op

Feature

• Pro - RI is automatically included in path generation
• Pro - RI is readily available to each operation
• Pro - RI code is independent from all other ops code
• Pro - RI code analyzes Base Geometry (possibly extendable to simultaneous 4 axis simultaneous)
• Pro - RI can be manually adjusted.
• Pro - Fewer inputs required from user when incorporating RI into the workflow
• Pro - No additional GUI load in Path toolbars
• Con - RI code (or subset thereof for activation) must be added to each op

Russell

[dubstar-04]

Hi Russ,

Thank you for all the effort you put in to FreeCAD, your attitude and drive is a benefit to us all and while the current 4th axis implementation might not be as good at the next one it is certainly better than what we had before.

I have barely looked at how 4th axis works but from a high level perspective would it be possible to implement it something like a Dressup?

Thanks,

Dan

[RatonLaveur]

Hi Russ,

I echo the praise by dubstar, definitely a stellar performance both from a personal attitude standpoint and technical ability and drive.

I support the de-entanglement for the following reasons:

1. The rotational code you implemented has definitely shown to be a good proof of concept, but as it is i find it adds too much complexity and finicky-ness to the common ops. ---> current implementation is difficult to use.

2. I don't see an easy pathway to improve it well in it's entangled state (i think also of the complexity for you, not breaking anything while making significant changes). --> de-entanglement will give you more freedom.

3. You aptly assert the difference between indexing and 4th axis cutting. For example sliptonic has already made a 4th axis mapping dressup. I think an independent "4th axis indexing" or "re-position" OP would be quite interesting.--> you could prototype to your hearts content and no one would complain about broken previous functionality.

I'm considering the following: Instead of producing e.g. a pocket, and then playing around with rotational options until it fits the bill, what if i had a specific intermediate OP telling what rotation i want based on a selected face or edge loop or two edges... for the normal vector and selected axis (datum axis?) for rotation, and that creates my new framework for the next base OPs. The new OP would only output the rotational pseudo g-code and de-facto reorient the clone or create an oriented clone. I think such an approach would in effect enable rotation for all ops (including 3D, adaptive...).

[mlampert]

I am to blame for the mess created within the code by the rotational features. As such, I will help fix it.

Blame? I think we're all in awe and quite excited about what you have accomplished! sliptonic's point about maintainability is very valid though - the code size of each op has gotten to the point where it becomes hard to comprehend and change, without breaking anything else.

One way of going about it could be to be to make selection of the xy-plane an explicit step. As a user, one selects the xy-plane (probably by selecting some features on the model, similar to how the "Setup" page in the Job task panel does the orientation) - and then the op functions as a plain 2.5d op, it just gets presented with a differently oriented version of the model. As a first step, to keep it simple, we could make this explicit, as a new page in each op's task panel - and then later, when we know what we're doing combine it again to the nice functionality you have spoilt us with

[sliptonic]

First things first. There's no blame to be had. This is part of the process. In fact, there's an entire school of thought built on the idea that you plan to throw the first one away. The point of the first attempt is to learn enough to do it right on the second (or third) attempt.

By the way, if you want to see a concrete example of a first attempt worthy of being thrown away, go look at some of the original Path code that I checked in.

As for a plan going forward, we should first assume that no major changes will occur before a 0.19 release. I really want to get toolbits into 0.19 so that we don't have another generation of new users building their libraries on legacy tools but beyond that our focus needs to be on crushing bugs, documentation, and code stability.

Going into the next development cycle, we have some big issues to address. This being one of them. Here's the informal list in my head now:

1) Operations need to be more modular and testable. The code needs to be easier to understand and it needs to be easy for users to switch between operation 'strategies' without losing the work they've already done.

2) We need a better approach to post-processors. There's too much code duplication between them and improvements don't get applied to all posts equally.

3) We need an overall job concept that can support machine tools beyond 3axis mills/routers. Specifically, lathe.

4) We should revisit some of our existing assumptions in light of other developments in FreeCAD. For example, does it still make sense to keep the job model as a clone now that with have Part::Link? Same thing with Toolbits. Since links can refer to other documents does it make sense for toolbit shapes to use them? I don't know the answers here so it's just a research question at this point.

[freman]

Wow, there's a lot to chew on there. Could I suggest that each of those merits it's own thread for any discussion and that this one remains a discussion of rotational code.

I'll refrain from chipping in on those four very valid points of discussion here.

I did have what seemed to be a great use for rotational code: a fixed 45 degree inclination of the spindle to cut a v groove with a straight endmill. I found it rather hard to get anything useful and ended up hand coding what I needed. IIRC I started a separate thread about that.

Despite that rather disappointed first encounter with using it , hats off and thanks to Russ for getting this off the ground.

[Russ4262]

I have begun to remove the rotational indexing code from the current 4th-axis operations. I have the Drilling op complete, but no testing yet. My process is

1. Travel back in git history to last commit prior to 4th-axis integration.
2. Copy that pre-4th-axis file version to working branch in my repository.
3. Work through all subsequent commits for that file, applying all non-rotational related changes.
4. Check to see that FreeCAD and Path WB open.
5. ** Later, the reconstructed code will need some testing.
6. ** Afterward, the 2.0 rotational indexing re-integration will begin - additional comments below.

I suggest we work toward a rotational indexing integration strategy within Path WB. Currently, I am thinking something like a feature, like the Base Geometry, Heights, or Depths. Something with a stand-alone tab like the aforementioned features. This would keep the new rotational indexing code isolated from the operations. In this type of integration, the EnableRotation flag in the Job settings can be read, and the feature's properties added to operations on the fly when a new operation is created within a Job with rotation enabled.

Or, should we pursue something more like a operation type of integration where the user explicitly adds an indexing operation to the Job, prior to adding the next regular operation?

Which way? Or, what other methods of integration should we consider?

I am working on removal of rotational code from PocketShape now, which is a little more complex. While doing so, I am thinking I might look at making the Extensions feature more independent, and thus available to other operations; but, that is secondary to my current task and a discussion for another thread.

Russell

[mlampert]

Hi Russell,

I would probably hold off on refactoring at this point. From what I hear the plan is to get 0.19 out this year which means we should leave the ops as they are and focus on bug fixes. The toolbits sliptonic is working on should probably be the last major change, at least to Path core ops.

My 2 cents,
Markus

[Russ4262]

Understood. I figured this much from Sliptonic's earlier post. Just trying to collaborate and communicate with the greater FreeCAD community.


Russell

[Russ4262]

... My 2 cents, ...

Are those Canadian cents or United States cents? I'm just asking so I have a better idea of how to value the comment.

Just messing with you, Sir. Honored to have a forum presence with you.

Russell