Paths falsely marked as altered.

[freman]

due the topo instability and the implications for paths, I would probably be safer not build all your 35 paths in one FCStd file.

Do a Save As Copy and split the paths over several files. If you need to change model geometry you can reduce the fall-out and keep some of the paths in a safe working state, which seems to be want you trying for with your requests.

Not ideal but damage limitation strategy if you have such a complex job. I guess you can find some logical split of those 35 paths.

[MRx]

Practically seen from my side:
I really don't have a problem with having so many paths in a file. The stability itself is okay.
The main issues are all elsewhere (and as in this initial post) unnecessary recomputation is a big issue.

I think sliptonic maintains that part, so I'd really like to have some discussion about this part and the future of it.

[onekk]

When you make a Path Object there are many things that have to be taken in account to generate a "ToolPath" (the travel that the tool has to do to cut the object)

Pratically, the ToolPath is a completely different object from the original object, as it is calculated starting from some feature of the "generating object".

For this reason Path is very sensible to modifications of things, it is a "very complex object" and this involve a "lot of coding" behind the scene to make "apparently simple things".

Even a simple Profile is not "so simple", as it has to take in account many things, like the tool diameter, but also "stepdown" and maybe other "CAM data" like "tool lenght" and so on.

And a profile is simply a set of "enlarged profile of the original boundary" duplicated with different "Z height".

But If i change simply the "stepdown" I have to recalculate all the "Z heights" and check them against "Stock depth", and maybe "Clearance Height", or even "Safe Height" changes.

So skipping recomputing is really a nogo.

From my point of view Path needs "some love" in form of some developer to work on his internals, but it is not a "simple task". Many work is done "under the curtain" as there are efforts to clean sources and make them more maintainable as Path has evolved during years, mostly form the work of few developers, if you see Path sources, you could see (without any precise order of importance):

* Yorik van Havre
* sliptonic
* Schildkroet
* Kresimir Tusek
* Russell Johnson
* Dan Falck

And few others, but now is done mainly from the work of sliptonic, Russel Johnson and Schildkroet, as from a quick scan of the copyright lines contributions from other peoples are dated 2014, 2015, 2016, so some years ago.

But As I use Path in Scripting, i could say that it is not too bad, once accustomed of some quirks, and when I have had some problems, sliptonic and Russel Johnson have talked with me, and maybe have modified some of the code to solve some quirks.

To be more honest the first thing i was told was "Path is not intended to be scripted yet", but even with this "preamble" answer, they have helped me a lot.

Regards

Carlo D.

[onekk]

due the topo instability and the implications for paths, I would probably be safer not build all your 35 paths in one FCStd file.

Actually the most safe way to do some serious work on Path is scripting, it keep you safe from toponaming, and permit to recreate on the fly all the paths.

Some work is needed to make this approach more linear and "workaround free", but is perfectly doable for simple operations, like "Pockets" and "Profiles", with some work you could even code different Jobs, and create properly Tools.

I'm working on some "investigation work" on some aspect of ToolBit Scriptability and "Tool Libraries" manipulations.

For Job and operations it is not to difficult to operate on them, I've had some difficult about "DressUps" operations.

But for some "repetitive works" it is more ans hassle to copy and paste code than to create paths with scripting.

See:
https://forum.freecadweb.org/viewtopic.php?f=15&t=63862

https://forum.freecadweb.org/viewtopic.php?f=15&t=53849

Regards

Carlo D.

[MRx]

But If i change simply the "stepdown" I have to recalculate all the "Z heights" and check them against "Stock depth", and maybe "Clearance Height", or even "Safe Height" changes.

So skipping recomputing is really a nogo.

this is a different scenario, you are modifying the path operation directly - of course it has to be recomputed after that.

But I have mentioned multiple scenarios where a recomputation should not be triggered (few examples, adding endmills, opening the path property menu and simply closing it, ..).
I am working a lot with the Path Workbench and I'm also modifying the scripts there.

[sliptonic]

It's time (actually past time) to stop putting band-aid fixes on the problems and start refactoring the code so we can address these problems at a root level. This is another case of the same.

Yes. I agree that there are cases where the path is inappropriately marked as dirty but the solution isn't to 'lock' the toolpath or to skip recomputes entirely. Skipping recomputes is a necessary feature for long-running tool path calculation but FreeCAD has a 'skip recomputes feature' already. We don't need to reinvent that wheel.

As onekk "pointed out" the toolpath calculation is complicated. It's all handled at the operation level and it is a mess. Each time an operation is recomputed it goes through two phases: First the op base geometry is evaluated to interpret what the user selected and compute the target geometry. For example, the user selected a couple faces, but the target is the material above those faces. Computing the target geometry isn't easy and is getting harder as we add things like extensions.

Once we have a target shape (or multiple shapes), the toolpath for is computed. This means slicing and offsetting the target shape, or feeding it to the dropcutter.

You see the problem? If the user changes the step-over or some other aspect of the toolpath, we throw away the target shape and start over. This is silly. Once the user has identified the target shape, we should retain that and only recompute if the model itself changes.

The inverse is a similar problem. While the user is still tailoring the selection to identify the target geometry and configuring extensions, we're already trying to compute a path at the same time. We shouldn't try to compute the toolpath at all until the user is satisfied that he's targeting the correct part of the shape.

Bottom line: The operations are doing WAY too much work. We need to build and retain appropriate intermediate shapes and only recompute those objects (target or path) which actually changed.

[freman]

It would be nice to just have the dirty state marked correctly for now.

[sliptonic]

It would be nice to just have the dirty state marked correctly for now.

The dirty state of what?

As is, if the base model changes, the op is dirty. If the op parameters change, the op is dirty. If the job changes, the op is dirty because the op takes all those things into account. Thus the problem.

[freman]

The primary problem I reported in #1 was that cancelling out of the editor sets the dirty flag, when "skip recomputes" is active.

That is wrong because nothing has changed.

that happens even if you do not touch anything but Cancel

[onekk]

As told by #sliptonic, maybe a complete rewrite is needed.

I have used some other CAMS and they use a different ways of doing things, but they are simply CAMS.

So having a way to create a 3d model of the area you have to cut (and to store this model in the operation) maybe is more prone to errors.

But in this case you have to recalculate the "cut solid" on every "original model" modification.

You want to "plane" a face, simply create a "face model" and work on this not on the "original face", but you have to add a way to inspect "original model" to detect changes in the "part you are using".

This take in the game the toponaming problem.

But many CAMs simply split "machining Operations" using a simple tree Part > MOP, and use concepts as "styles" to assign some data as a whole thing like "tool number and so on" in a ore simple way, for each property there is a "three state" that indicate if the data is belonging to:

a general style
a Part Style
a user value valid only for this operation.

So the user could simply choose what predefined style to use or if this operation have to use a custom value.

Features like "Holding Tabs", "lead in", "lead out" or similar are per "operation", i.e for each operation you choose if you have to activate these features or not.

Said so it is only an approach used to another CAM and maybe (and probably) not the best.

So some discussion have to be done, (here is not the right place).

But as usual there are many ways to obtain things, and finding a "unique right way" is general an utopic things.

When coding, you will find that even "simple things" involve to calculate many data, store many data, or make some other difficult thigs, even to find a simle "step down", this involve a "Z starting point" that is not necessary the "Stock upper surface" and maybe you have to enter "in a more gentle way" a surface like plywood as the "upper fibers" that are the "finishing side" are easily teared apart, so maybe you have to use a 0.125mm stepdown till say -1.5mm and then use a more aggressive cuts, for the "inner support material" maybe 2.5 or 3mm.

But this is a way that maybe is not right for many people as maybe they have a better "material" or better "endmill".

Better to move the discussion to some other places, and start a "brainstorming" session.


Sorry for the OT.

Regards

Carlo D.