* Fem: Remove pipeline from analysis highlighter - fixes#23466
* FEM: Clean up lint
---------
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
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
- Change missing property log in shape/doc.py from warning to debug
- Ensure SpindleDirection property exists and is set, defaulting to "Forward"
- Ensure Material property exists and is set, defaulting to "HSS"
- Update SpindleDirection and Material from toolbit file parameters if provided
* BIM: fix regression in DAE import, support for polylists
The support for non-triangular faces was remove in
commit 346c7581d4.
Now, the support for them is restored, by triangulating them
during the import (with a warning and changing the object name).
Signed-off-by: Gaël Écorchard <gael@km-robotics.cz>
* BIM: Remove translation calls console
Use raw strings for console messages, as they are usually not
translated.
---------
Signed-off-by: Gaël Écorchard <gael@km-robotics.cz>
Co-authored-by: Gaël Écorchard <gael@km-robotics.cz>
Rotating an ArchSectionPlane object caused its cutting effect to flip,
affecting both the live `CutView` and 2D projections. The
`_SectionPlane.execute()` method incorrectly tried to auto-correct the
orientation of a temporary plane before applying the object's final
placement. The fix refactors this to a "transform-then-verify" pattern:
the object's full `Placement` is now applied to the temporary plane
first, and only then is the resulting face's actual normal validated
against the intended normal from the `Placement`. This ensures the
`Shape` is always geometrically consistent with the `Placement`, making
the cut direction predictable at all angles.
* Draft: Update Draft example file
Fixes#23198
I have added osifont-lgpl3fe.ttf to the example folder. The ShapeString in draft_test_objects.FCStd references it using a
relative path. I am not sure if including the font here is allowed though.
Additionally: The example file showed up an error in view_wire.py. It is also used for fillets (which do not have a Points property).
* Updated
* Also use a relative path for the PAT file.
* Subfolder for the PAT and TTF files.
* Update CMakeLists.txt
* Update CMakeLists.txt
* Update CMakeLists.txt
* Update CMakeLists.txt
* Update CMakeLists.txt
* Update CMakeLists.txt
- Add shortcut setting for individual actions in PythonGroupCommand::createAction()
- Update PythonGroupCommand::languageChange() to include default command shortcut in group tooltip
- Fix variable redefinition error in languageChange() function
- Ensure shortcuts work and display in tooltips for grouped commands like Arch_Nest
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
