Discussion for detanglement of rotatioal code from existing ops

[freman]

Like most design processes, a top-down strategy of what is required and how to get there would seem to be a good idea. Piecewise bold-on modifications inevitably end up producing unstructured and encumbered messy results which end up requiring a total restructuring which can be very, or even prohibitively, costly to do.

I would hope that at some stage FreeCAD will get to full blown 4th axis capability. That would presumably be an extension of current 3D tools to cater for shapes that cannot be machined with 3 orthogonal axes. The most common forth axes being an additional motorised rotational degree of freedom.

That may be motorised control of the inclination of the spindle axis or a motorised chuck which rotates the work piece.

Fixed indexation of the spindle applied to 2.5D operations, which Russ had made a pretty good initial implementation of is potentially useful and could be better than using the 3D tools for a lot of shapes. ( It actually fits my machine quite well too since I can incline the spindle but this d.o.f. is not motorised ).

I can understand the desire for "disentanglement" but what does this imply?

Russ' suggestions above about separating the UI elements of 4th axis does not seem solve the entanglement issue. Either the existing code gets duplicated to create a 4th axis aware version ( this clearly presents problems of keeping the two in sync ) or the same entanglement problem arises in the implementation of the features even if they are separate in the UI.

Is there a third option which I'm missing?

[mlampert]

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

Canadian - might not be worth as much but it looks better

[Russ4262]

... I can understand the desire for "disentanglement" but what does this imply? ...

We are physically needing to detangle the current rotational code from the base operation code. I did not know any better when I added rotation to the ops. So, the code for the rotation-capable ops is a mess compared to what it was prior to rotational integration for the same operations. At minimum, we need to pull the rotational code out and place it in organized functions, and/or classes. As the title suggests, this thread is for physical code changes, while maintaining current feature availability - even if the current rotational features are altered a little in the process to accommodate physical code separation (removal). Current ops affected will be Profile, PocketShape, Drilling, and MillFace.

Our goal with this thread is to identify the solution we want to use to physically remove the rotational code from ops in order to restore maintainability of base operations code. For example, in my working branch I have the Drilling op now cleaned of all rotational code and rotational features while maintaining all other commit changes after rotational integration occurred. In essence, I think I am manually reverting all rotational commits from current operations with rotational integration.

It is my hope that the solution identified here will also include some direction for version 2.0 of rotational integration, so we do not lose current rotational features/functionality.

For those interested or using current rotational features, the goal here is not to strip rotational features from the Path WB as they currently exist in 0.19, rather restore code simplicity to base operations possessing rotational capabilities while maintaining or improving rotational features.

The solution(s) discussed here will likely not be seen until version 0.20 (or whatever official version is assigned).

I feel like I answered your question, but with a little dust of doubt lingering in the air.

Russell

[RatonLaveur]

I would say that simple is better at the moment for path.

We've seen a lot of variables added to the data tab of various ops which is both great and overwhelming, also rather painstaking to use with a good flow.

What would an Indexed milling workflow be (in my opinion so that's obviously subjective):

1. Complete Path Setup including Workpiece Coordinate System setting.
2. Select a feature (profile/edge/face) in the XY plane and perform a normal OP.
3. Select a feature (profile/edge/face) in another plane and "Make working plane" (the new Indexing OP)
4. Select a feature (profile/edge/face) or keep previous selection, and perform normal OP.

The rotation in this is an individual OP both in terms of GUI operations (user input) and outputted parsed code. (probably with retract to a safe position then rotation).

So yeah I'd say an individual OP would be just fine.

One tricky aspect is that of the reference. Does it stay where it was (i.e. rotated LCS?) Does the new OP authorize setting of a new reference? Does the new OP create in effect a new rotated clone?...

This I'm not sure. But i would say that in the Setup tab, if the user intends to use indexing, then a rotational axis should be defined (as a datum?).

Many modern CNC would simple probe the part to determine workpiece coordinate system and then, knowing the machine's center of rotations, it would be able to interpolate any rotation correctly. PathWB however
Is geared towards hobbyists too (mainly). So...not sure how to approach that.

[Thorhian]

Like most design processes, a top-down strategy of what is required and how to get there would seem to be a good idea. Piecewise bold-on modifications inevitably end up producing unstructured and encumbered messy results which end up requiring a total restructuring which can be very, or even prohibitively, costly to do.

I would hope that at some stage FreeCAD will get to full blown 4th axis capability. That would presumably be an extension of current 3D tools to cater for shapes that cannot be machined with 3 orthogonal axes. The most common forth axes being an additional motorised rotational degree of freedom.

That may be motorised control of the inclination of the spindle axis or a motorised chuck which rotates the work piece.

Fixed indexation of the spindle applied to 2.5D operations, which Russ had made a pretty good initial implementation of is potentially useful and could be better than using the 3D tools for a lot of shapes. ( It actually fits my machine quite well too since I can incline the spindle but this d.o.f. is not motorised ).

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.

May I, a total newbie who lurks the path gitter and forums and scavenger of academic papers, make a suggestion when it comes to the higher-level view of what kind of capabilities we want the Path workbench to be capable of? I think it might be advantageous to focus on two things (amongst others): Lay the groundwork for true 5 axis support of operations and simulation. We may even want to think about Milling + Turning operations to ensure that lathes get the treatment they deserve too. I personally think that if we just focus on trying to retrofit everything to eventually work on 4 axes, it will only mean even more work trying to figure out making another leap to 5, but I am not really experienced with programming this stuff (yet), so please let me know why this would be a terrible idea. If Path is capable of creating both 3 + 2 along with simultaneous 5 axis operations, then 3 and 4 axis operations are just subsets of those two. If we think about targeting Mill + Turn from the beginning, then regular CNC lathes will be covered as well without having to work too much since it's a subset of Mill + Turn. We would need to try and keep the tool path algorithms as flexible as possible and keep the codebase modular (and testable), and this would allow us to move beyond 3 Axis Mills/Routers.

When it comes to the post-processors, I really should look into how LinuxCNC represents tool paths internally. Having some sort of "universal" data-structure(s) and "language" or grammar to represent them when generated would probably make it easier for post-processing? Maybe then you have some sort of grammar that interprets PathWB's internal data structures/objects into GCode. Do you think such a system would help with the post-processor situation sliptonic?

[freman]

Thanks Thorhian.

I think what you are saying is basically what I also wrote above about top down design as opposed to constantly bolting on tweaks to existing code which is inevitably a dead end approach. I think it is unlikely that you can evolve from simple 2.5D tools to 4 or 5 axis capabilities by piecewise, incremental changes without some overall game plan.

What you are saying is , take a step back and look at the bigger picture and see how smaller changes fit into that plan as subsets of the eventual target. That seems like a very good idea to me.

[RatonLaveur]

That may well be, but then what do we do about dubstar-04 effort with LibLathe to create functional turning operations. Are we to consider merging/discarding/duplicating the work? neither seem feasible in the FreeCAD ecosystem or even desirable.

Full 5 axis is another animal in terms of computation. I have not seen a software yet that uses a singular approach to do all types of operations. Even Siemens-NX (industry standard for aerospace) uses different modes. Some highly advanced CAM softwares even use virtually different versions for 3 axis or 5 axis, with a different license.

If we look at on-going development and capabilities:

- 3 axis ops including surfacing are at a release stage.
- turning ops are at a functional stage.
- axis mapping for 4th axis milling is functional.

what the hobbyist needs:

- 4th axis indexed milling

what the more industrious user/industry user needs:

- 5 axis, there is currently an effort to perform the inverse kinematics in https://forum.freecadweb.org/viewtopic. ... ge#p367639 but this is very early stage despite an impressive demo by AdamLange.

-----------------------------

With that in mind, and going back ON topic: I see the de-entanglement effort by Russ as a positive and very future oriented task. I also see adding Indexing as a separate thing as perfectly functional and safe for the future of PathWB.

If you have anything to add to my probably lackluster overview of Path OPs (mind that I am not talking about the PathWB as a whole, i consider the OPs only here).

Best,

[freman]

Thanks raton, I was not aware of either Adam or dub's work on these areas, which really is the point of my comment.

I'm a noob round here and just poking away at that limited corner which is relevant to my hardware and my needs. I suspect more voluntary contributions follow a similar motivational path. That's the whole point of taking a step back and looking at the larger picture. It's certainly very interesting looking at all the techniques being explored.

Insofar as the original disentanglement discussion goes, where does this lead? Marus suggested holding off on changing the code too much at this stage. Disentanglement of the 4th axis code seems to imply keeping the 2.5D code and introducing a duplication with 4th axis capabilities. Is that better than entanglement from a development POV ?

How does "adding Indexing as a separate thing" work? Is there a third way ?

[Thorhian]

Insofar as the original disentanglement discussion goes, where does this lead? Marus suggested holding off on changing the code too much at this stage. Disentanglement of the 4th axis code seems to imply keeping the 2.5D code and introducing a duplication with 4th axis capabilities. Is that better than entanglement from a development POV ?

How does "adding Indexing as a separate thing" work? Is there a third way ?

When it comes to the path operations that we have already, such as the 2.5D algorithms, the 4th axis code could be moved to a separate dressup operation. In that op, you would specify how the stock/part(s) would be rotated on a specified axis. Then, you would specify whatever operation you wanted as a child to that dressup and that operation doesn't need to be burdened with knowing that a 4th or 5th axis even exists. Such a dressup operation could easily be expanded to 5 axes since the actual toolpath operations don't know that they are working on a rotated model essentially. Of course, tool path algorithms that use 4 or eventually 5 axes simultaneously wouldn't be included in this kind of separation.

[freman]

The idea of a dressup is probably not a bad option for a fixed rotation of a fixed 2.5D operation in terms of coding. Though it's a little hard to see how this would work intuitively from the user's perspective.