Introduced new toolbit and shape models for tapered ball nose tools,
including schema, summary, and integration into CMake and module
imports. Added corresponding SVG and FCStd files to resources.
Updated SVGs so end markers (arrows) render correctly in Qt by
converting markers to paths. Kept a source SVG with markers as
strokes (not paths) for future editing and updates.
Reworked the ToolBitEditor UI to display the toolbit to the right of the
toolbit properties, improving usability. Shrunk the overall height of
the editor window to better fit typical screen sizes.
src/Mod/CAM/CMakeLists.txt:
- Registered new taperedballnose toolbit and shape models and resources
- Added updated SVGs and source SVGs for marker compatibility
src/Mod/CAM/Path/Tool/shape/__init__.py:
- Imported ToolBitShapeTaperedBallNose and added to __all__
src/Mod/CAM/Path/Tool/shape/models/taperedballnose.py:
- Added ToolBitShapeTaperedBallNose class with schema and label
src/Mod/CAM/Path/Tool/toolbit/__init__.py:
- Imported ToolBitTaperedBallNose and added to __all__
src/Mod/CAM/Path/Tool/toolbit/models/taperedballnose.py:
- Added ToolBitTaperedBallNose class with summary and integration
Tools/Shape/taperedballnose.svg, Tools/Shape/taperedballnose.fcstd:
- Added new SVG and FCStd for tapered ball nose
- Updated SVGs for correct marker rendering in Qt
- Kept editable source SVGs with markers as strokes for future updates
This commit applies a simple fix to the V-bit tool definition, adding a
small offset (+0.05 um) to the tip diameter. This prevents the sketch
from generating invalid constraints due to a zero or near-zero tip size.
src/Mod/CAM/Path/Op/SurfaceSupport.py:
- Add +0.05 um to tip diameter calculation to avoid constraint errors in
sketches
CAM/App/PathSegmentWalker.cpp
- Add G74 to drill/tap/bore G-code recognition for tapping cycles
CAM/InitGui.py
- Move CAM_Tapping command behind experimental feature flag
- Only group drilling/tapping commands if both are enabled
CAM/Path/Base/Generator/tapping.py
- Add pitch and spindle_speed parameters to tapping.generate
- Output S (spindle speed) and F (pitch) in generated G-code
CAM/Path/Op/Tapping.py
- Require Pitch property for tap tools and SpindleSpeed for tool controllers
- Pass pitch and spindle speed to tapping.generate
- Use SpindleDirection to determine right/left hand tap
CAM/Path/Post/scripts/linuxcnc_post.py
- Handle G84/G74 tapping cycles: convert pitch and spindle speed to feed rate
- Remove F and S from output and recalculate F as needed
CAM/Path/Tool/shape/models/tap.py
- Add Pitch property to ToolBitShapeTap schema
- CAM/Path/Tool/toolbit/models/tap.py
- Show pitch and rotation in tap tool summary
- Use is_imperial_pitch to format pitch as TPI or mm
CAM/Path/Tool/toolbit/util.py
- Add is_imperial_pitch utility to classify pitch as imperial or metric
CAM/Tools/Bit/375-16_Tap.fctb
- Remove unused parameters (Coating, Rotation, TPI, Type)
- Keep only relevant tap parameters for new schema
Fix issue with toolshapes
Renamed fillet to radius
Added Tool Type Filter to library
Fix units so that they honor user preference
Remove the QToolBox widget from the Shape Selector page and combine into a single page.
Fix issue with PropertyBag so that CustomPropertyGroups as a string is converted to enum and enums are handled correctly.
Update TestPathPropertyBag test for enum changes.
Update TestPathToolBitListWidget
Update TestPathToolLibrarySerializer to match new LinuxCNC output
Fix LinuxCNC export too handle ALL tool types, use user preferences for units, and include all lcnc fields
* CAM: thread-mill Shape , more robust model
Purpose: prevent solver dumping arcane coding errors to report window if "crest" value is (legitimately) set to zero by user.
Single tooth thread-mill tools exist which have a sharp point, ie zero flat "crest " surface. Thus the user can reasonably expect to configure a zero dimension to the truncated end of the tool if it is not truncated. This should not provoke an error condition and certainly not crash the model and dump lots of arcane developer info on the machinist user.
The problem is that a zero dimension makes two points concurrent and removes an edge from the model. This leads to and ill-defined model which crashes the solver. The user should not be exposed to this kind of coding breakage when entering legitimate data for a tool shape. The solution (or workaround) here is to add a very small faction of the shaft diameter to the user supplied zero to prevent the solver crashing. Since this is proportional to the tool shaft it will scale to any use of the tool shape without disrupting path accuracy.
This is a drop in replacement for the existing file and caters for both types of this tool: truncated tip and pointed tip.
* threadmill Shape update
This thread-mill Shape file uses max() in the expression for crest.
This allows user setting zero crest by adding a small finite dimension to prevent the solver crashing, while not making any change to finite crest tools.
Best of both worlds.
Fixed a misspelling, added some commas, changed all occurrences of
PDN (PartDesignNext) or PD to PartDesign to improve readability.
(And update the text, since PartDesignNext was new in version
0.17 or so, and stable is now 0.21.2. )
