[Feature] CAM: An easy way for users to add standard endmills and tool bits

[knipknap]

Is there an existing issue for this?

• [X] I have searched the existing issues

Version

0.21 (Development)

Full version info

[code]
OS: Ubuntu 22.04.2 LTS (ubuntu:GNOME/ubuntu-xorg)
Word size of FreeCAD: 64-bit
Version: 0.21.0.33260 +4 (Git)
Build type: Unknown
Branch: toolbit-library-9466
Hash: 8a6847116ae8dc0e4569e76c8d2bc3847db30e9f
Python 3.10.6, Qt 5.15.3, Coin 4.0.0, Vtk 7.1.1, OCC 7.5.1
Locale: English/United States (en_US)
Installed mods: 
  * DynamicData 2.46.0
  * WebTools
  * toSketch
  * fasteners 0.3.50
  * FreeCAD_assembly3 0.11.0
  * lattice2 1.0.0
  * fcgear 1.0.0
  * Assembly4 0.12.3
[/code]

Subproject(s) affected?

Path

Problem description

As a user, it is slow and tedious to select a shape when adding a new toolbit. While FreeCAD does ship some example shapes, they are not easily found. In fact, when running FreeCAD from Snap I didn't find them at all and had to pull them from the Github repository. But in any case, even if they were on my local HD in some example folder, they are not presented to the user in a friendly manner.

Anything else?

I encountered this issue while working on #9466, but decided to split it into a separate issue.

Solution proposal: Create a custom "select shape" dialog.

Challenges:

• This requires that FreeCAD differentiates between "built-in standard shapes" and "custom shapes", which may impact the toolbit file format. But it can be implemented in a backward-compatible manner.
• Quite a bit of artwork is needed.

I am willing to implement the changes.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[sliptonic]

Yes! The current workflow was put in place because it was the simplest one given the data model but it can (and should) be improved. Ideally, pressing the 'create toolbit' button would present a new dialog. There would be a field to enter the name. There would be a combobox populated with the the .fcstd files from the user's Tool Shape directory.

When the tool shape is selected, the dialog can automatically update itself with the attributes from the shape.

When both the shape and name are populated, the ok button becomes enabled.
Please feel free to mock up a panel and we can discuss whethe the propsed flow works and any improvements before you implement.
Thanks!

[luzpaz]

Looking forward to seeing the mockup, this proposal looks great so far

[knipknap]

Hmm, I was not planning on changing the "tool edit" dialog as part of this feature - this feature would simply replace the "open file" dialog by the mockup shown in the original posting. Once a tool was chosen, the tool editor dialog would open the same as before.

You could also still get to the "open file" dialog by choosing "custom" in the dialog.

Maybe updating/extending the "edit tool" dialog to add support for changing the tool type also makes sense, but I think this would be a separate feature.

[sliptonic]

The toolshapes automatically generate their thumbnails. I'd prefer to use them rather than custom artwork since it will work with custom shapes as well.

[knipknap]

The problem is: That is too slow to show them all at once. I think it makes sense to show the shape in the editor, but before opening it isn't scalable.

Another problem is that the rendered view isn't very insightful; it doesn't show visually you which dimensions a tool has - best you can do is a list of parameters.

[sliptonic]

I don't know why it would be slow. We show the thumbnails for all the recent files in the startpage and it is fast

[knipknap]

Ok, but it still doesn't provide the mentioned information that way.

[sliptonic]

Ok, but it still doesn't provide the mentioned information that way.

Noted. It's still better to use automatically generated images rather than rely on separate artwork. Among other considerations, the artwork as shown isn't translatable.

Maybe in the future, we can find a way to make the thumbnail be extracted from a TechDraw page.

[knipknap]

Ah, a shame. I understand your preference from a programmer perspective, but honestly would feel the result isn't something I would love as a user.

Compare this:

To this:

I can respect your preference, but the "auto rendered" approach is not something I would be interested in working on.

[sliptonic]

I understand. I'm going to give a little more context here for the sake of others who might want to pick up the baton and run with it. My preference isn't coming from a programmer's perspective. It's driven by experience and seeing the issue in context.

First, as I mentioned, is the issue of translation. In your second image, you cropped off the text 'Endmill' but still left the indicators S,H,D for Shank, Height, and Diameter. These are arabic characters and will make no sense in non-arabic languages. The use of text in images makes them impossible to translate.

Second, the artistically generated images look beautiful. But they'll never exist for a user's custom designed tool. With the automatically generated images, a user can design any kind of tool and get an image that works exactly like the defaults. There's only a handful of tools that are used widely in milling. Not true when it comes to woodworking where there is a never ending catalog of router bits.

Going beyond custom bits, lathe work isn't too far in the future. Lathe cutters also come in a huge range of shapes. There's simply no way to both create and maintain a catalog of images for them, especially with a small team of mostly volunteers.

Third, the big beautiful images look great in a tiled layout where you have room to show them. The same images, however, are used in the icons in tree. Those big images won't scale down to icon size and remain attractive. That means we have to maintain TWO sets of images or use both drawn and generated images. That sucks and is confusing for the user because the image for the same thing looks different in context. Now instead of helping the user instantly recognize a 'thing' in the tree, they have to think about it.

Fourth, the generated images can look better than they do now. In fact, they have the possibility to blow the drawn images out of the water. They currently look very plain because they're modeled with only the attributes needed to calculate tool paths. That doesn't have to be. If someone wanted to improve the Endmill.FCStd file and model the flutes, it would generate a better image. It doesn't have to stop there. In the toolbit creation dialog, we could update the image in realtime to reflect the parameters as entered by the user. The toolshapes are FreeCAD models and we're literally IN FreeCAD! I'm looking at the current state as one step along a road that leads to something the user loves. I agree it is unattractive and can be (much) better. But don't throw the baby out with the bath water.

[knipknap]

I agree with almost everything you said and I think this is a good goal in the future. But isn't this a pragmatic first step anyway?

If that dialog were to exist, it would be easier to fetch the images/icons from elsewhere later. It could later fall back to auto-generated images if an icon doesn't exist, or extract the image from an image plane in the shape file, or auto-render dimensions, or a combination of the above. Today, none of the features exist anyway - e.g. parameters are named as they are written in the shape file and not translated, the rendered tool image wouldn't be very useful for most lathe tools either, and for now users have no visual shape indication, regardless of tool type.

I am just advocating for the pragmatic and iterative in favor of waiting for something perfect that may never come. Plus, defining built-in types would allow me to progress on #9466 - as it stands, there is no source of icons for the tool list, as the auto-rendered are simply not useful.

[sliptonic]

I am just advocating for the pragmatic and iterative in favor of waiting for something perfect that may never come. Plus, defining built-in types would allow me to progress on #9466 - as it stands, there is no source of icons for the tool list, as the auto-rendered are simply not useful.

I'm all in favor of pragmatic and iterative progress as long as it's in the right general direction.
I'm solidly opposed to adding any non-translatable GUI elements. No images with text.
If you remove the various labels, the drawn images are scarcely any better than the generated ones.
The generated images can be easily improved by just changing the viewport and background color. This won't help with the flute rendering but is loads better than the stock blue gradiant.

[knipknap]

I am confused, one of my comments disappeared. There I made the point: SVGs are translatable.

[knipknap]

Just a heads up for anyone looking into it: Since this was not accepted for FreeCAD mainline, I implemented all features as an Addon. So possibly this issue could be closed, or left open for anyone trying to implement it differently.

[luzpaz]

@sliptonic please advise