This job contains Legacy tools. Legacy tools are deprecated. They will be removed after version 0.20

[memfis]

Colleagues, I remember the "new tools" in their early days. I tried them, drew my own, "saw" them in the program, and went back to using the "old" ones.
At that time it was beautiful, but useless - the program did not take into account the sectional profile of the created tools.
Now in the console writes Sabj.
Switching the tool setting method used in the settings = no big deal.
Please clarify - does FC0.20 now take into account the "section profile" of the created tool?
Are there any other "peculiarities" that should be taken into account when making this switch?
For example, the tools created "then" - you can't see their picture, profile.

Code: Select all

{
  "version": 2,
  "name": "Радиусная d12.75 R6.35",
  "shape": "radius_vogn.FCStd",
  "attribute": {},
  "parameter": {
    "ds": "6.35 mm",
    "L": "50.000 mm",
    "Diameter": "12.75 mm",
    "hR": "5.35 mm",
    "Rv": "7,000 mm",
    "H": "10.02 mm"
  }
}

[sliptonic]

Please clarify - does FC0.20 now take into account the "section profile" of the created tool?

It's not easy to answer just yes/no. In the way you probably mean, the answer is no, it doesn't. I mean that purely custom tool shapes will not be used to detect collisions or affect the simulator. You can't, for example, create a roman ogee tool and simulate that complex curved edge.

However, some aspects of the tool shape are used and will be used more in the future. For example, a deburr tool with an angle can be used to help calculate the proper offset of a deburr operation. Mapping of toolbits to OpenCamLib tools is better. Integration with Camotics projects will be easier with toolbits.

More importantly, other attributes of the toobit that do not affect its shape are used already to affect Path behavior. For example, if a toolbit like a probe has the spindle off property set, Path will never turn on the spindle with that tool. These additional attributes can also be used to store user-specific information about toolbits.

Are there any other "peculiarities" that should be taken into account when making this switch?
For example, the tools created "then" - you can't see their picture, profile.

A copy of the toolshape and the toolbit information is stored in the document but the master information is stored as external files on your hard drive. The path to the file is stored in the document. These paths can be either absolute or relative. This makes it possible to back up your tool data and also to share toolbits/shapes between computers. Even if you don't have access to the original files, the document will still work but you won't be able to edit the toolbit or shape.

[bmsaus4ax]

It's not easy to answer just yes/no. In the way you probably mean, the answer is no, it doesn't. I mean that purely custom tool shapes will not be used to detect collisions or affect the simulator. You can't, for example, create a roman ogee tool and simulate that complex curved edge.

It's highly possible I am misunderstanding your intention here, so apologies if so.
The FreeCAD simulator will process complex cutting end faces, it will not however do anything other than vertical cutter edges. All the stock above the maximum diameter of the cutter is removed by default.
( I am trying to update my 1997 C++ knowledge , and learn some Opencascade , in the hope of getting around this, but will not be anytime soon!. Modern C++ is a whole new level. )

I have attached a crude minimalistic rework of memfis's tool shape and bit files. Just to get the Attributes registering.
Also a shape I tried when learning how to create tool bits.

The .FCStd file includes profile operations of both shapes.

The simulated Cut Material shows an apparent transparent area which I suspect is just a resolution issue as the profile is correct.
.

Code: Select all

OS: Ubuntu 20.04.4 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.28774 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 716213b)
Hash: 716213beacd25a907f2c164ad8ef8309b8a284b0
Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3
Locale: English/Australia (en_AU)
Installed mods: 
  * Curves 0.4.2
  * CurvedShapes 1.0.3

[memfis]

The .FCStd file includes profile operations of both shapes.

The simulated Cut Material shows an apparent transparent area which I suspect is just a resolution issue as the profile is correct.

Браво! Большое спасибо за конкретику, пример и проделанную работу!

Bravo! Thank you so much for the specifics, example, and work done!

Please clarify - "who stands on whom"? in the sense that creating your tool library should -
1. one file of shape description fcstd in the Shape directory should be created for each type of tool (many tools of different size of the same type) + one file fctb with individual dimensions for each instance
2. each instance of a tool has its own pair of fcstd + fctb?
In the sense of correct use, including for simulation?

Is there a library somewhere with sets of such templates (file pairs)? - so that there will be no conflicts of names and mutual understanding between the creator of the tool form and the program code when you try to create it yourself.

[bmsaus4ax]

Please clarify - "who stands on whom"? in the sense that creating your tool library should -
1. one file of shape description fcstd in the Shape directory should be created for each type of tool (many tools of different size of the same type)

One original .FCStd required.
The one .FCStd file does all sizes of the same tool by changing the attributes values in the dialog when a new tool is created.
.

+ one file fctb with individual dimensions for each instance

Only one original is required. This one file is the pattern from which new tools are created.

The one .fctb file has an initial size, more tools are created based on this. It provides the Attributes reference for the creation of a new .fctb file for the tool you are constructing .
For example a standard 3mm endmill.fctb is supplied in the installed tools. When a new toolbit is created a it is saved with a new name and the attributes edited (in the dialog) for the new toolbit. The result is a new unique toolbit, and the original still exists.
,

2. each instance of a tool has its own pair of fcstd + fctb?
In the sense of correct use, including for simulation?

Only the original pair for each toolbit type, all other instances are built from them in the creation dialog.
.

Is there a library somewhere with sets of such templates (file pairs)? - so that there will be no conflicts of names and mutual understanding between the creator of the tool form and the program code when you try to create it yourself.

To create a new type of toolbit, I open an existing .fctb file (from the Bit directory) and edit it and "Save As" a new definition for a new tool.

Sliptonic did a recent video at
https://www.youtube.com/watch?v=fgCPmCEnndo

A good step by step hard copy guide procedure here
https://forum.freecadweb.org/viewtopic. ... 65#p577865

[memfis]

Thanks again for such a detailed response. Very helpful.
But what is the list of attributes handled (variable names, values, naming convention)? Using the example of that tool of mine that you fixed - I used the names that were (it seems) in effect at the time of these experiments of mine (I don't think the "attributes" option was used then) and as a result the tool created "didn't work".

And maybe there's a downloadable kit, a library? - I looked at my "kit", from the first experiments (2019-12), and it is, there are no "attributes" involved.

[memfis]

The console reports that there is an error in the file my_radius_vogn.fctb - Error loading tool: my_radius_vogn.fctb : Expecting property name enclosed in double quotes: line 9 column 19 (char 205), extra comma after "Flutes": "2" before the bracket.
And it does not show the cutter profile

Code: Select all

<PropShape> PropertyTopoShape.cpp(414): Pending recompute for generating element map: my_radius_vogn#Body
<PropShape> PropertyTopoShape.cpp(414): Pending recompute for generating element map: my_radius_vogn#Sketch
<PropShape> PropertyTopoShape.cpp(414): Pending recompute for generating element map: my_radius_vogn#Revolution
<PropShape> PropertyTopoShape.cpp(414): Pending recompute for generating element map: my_radius_vogn#Revolution
PathUtil.WARNING: my_radius_vogn has no property Chipload (Chipload))
PathUtil.WARNING: my_radius_vogn has no property Flutes (Flutes))

[memfis]

if you remove two lines from the file -
"Flutes": "2"
"Chipload": "0.000 mm",

then the profile of the tool becomes visible.
So the question raised earlier about processed parameters (naming convention, etc.) remains relevant

[sliptonic]

Only one original is required. This one file is the pattern from which new tools are created.

The one .fctb file has an initial size, more tools are created based on this. It provides the Attributes reference for the creation of a new .fctb file for the tool you are constructing .
For example a standard 3mm endmill.fctb is supplied in the installed tools. When a new toolbit is created a it is saved with a new name and the attributes edited (in the dialog) for the new toolbit. The result is a new unique toolbit, and the original still exists.
,

Not really. Actually, the system is flexible here. If you want to create a toolbit that corresponds to a kind of tool, for example "Lakeshore Carbide part number 1234" and you use lots of those tools, that is fine.
However, you might also track wear data PER PHYSICAL TOOL. So a toolbit could correspond to " Lakershore Carbide Part number 1234 serial number 5678"

2. each instance of a tool has its own pair of fcstd + fctb?
In the sense of correct use, including for simulation?

Only the original pair for each toolbit type, all other instances are built from them in the creation dialog.

The FCStd is a FreeCAD project file. It is the shape of the part. The .fctb is the toolbit data. It references the shape.

[bmsaus4ax]

Thanks again for such a detailed response. Very helpful.
But what is the list of attributes handled (variable names, values, naming convention)? Using the example of that tool of mine that you fixed - I used the names that were (it seems) in effect at the time of these experiments of mine (I don't think the "attributes" option was used then) and as a result the tool created "didn't work".

And maybe there's a downloadable kit, a library? - I looked at my "kit", from the first experiments (2019-12), and it is, there are no "attributes" involved.

I looked at your toolbit again and used all of the named constraints in your original file.

It appears only English language text is accepted. Diameter had to be Diameter, your "H" would not be accepted but the constraint was accepted if named
"CuttingEdgeHeight" other names may also work ?? I only tried that.
I think Diameter is the only mandatory name, not sure though.
Using just your short names worked for the rest (English text) Could put your original language text in the Tool Tips box and they show up if moused over in the Data Tab Properties.

The Chipload and Flutes had to be included in the Property Bag with their GROUP name as Attribute. This is why my file did not work as I did not do this before.