OS: Debian GNU/Linux 10 (buster) (KDE//usr/share/xsessions/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.19.1)
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.8
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United Kingdom (en_GB)
Hi
I'm having a problem here with Vcarve. The attached image shows the result of Vcarve vs Engrave. Engrave performs as expected an honours the depth settings. Vcarve stubbornly sits above the surface cutting air. Changing depth settings does not change the height of the path.
In order to use the generated path I would have to set the material surface to approximately 1mm on the cnc.
It looks like a bug, have I missed something simple?
Colin
Ticket #4602 - Vcarve Cutting Air
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Ticket #4602 - Vcarve Cutting Air
- Attachments
-
- vcarve-test.FCStd
- (101.68 KiB) Downloaded 40 times
Last edited by Kunda1 on Sat Mar 27, 2021 10:21 am, edited 1 time in total.
Reason: Added ticket number to thread title
Reason: Added ticket number to thread title
Re: Vcarve Cutting Air
confirmed, this is a bug - can you file an issue with the bug tracker?
Re: Ticket #4602 - Vcarve Cutting Air
Ticket wasn't assigned to Path. Now it is. Updated thread title to reflect ticket number.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Ticket #4602 - Vcarve Cutting Air
For me the change from this pull request fixed it: https://github.com/FreeCAD/FreeCAD/pull/4680
The path still starts in the air, but has the correct depth and thus goes into the material to the extend needed.
The start point above the part is due to the path calculation being based on a pointy tip of the tool, but the tool definition having a tip diameter given, resulting in a z height offset.
The path still starts in the air, but has the correct depth and thus goes into the material to the extend needed.
The start point above the part is due to the path calculation being based on a pointy tip of the tool, but the tool definition having a tip diameter given, resulting in a z height offset.
Re: Ticket #4602 - Vcarve Cutting Air
Neat thanks ! been guessing the offsets until now, much better results.
(Completed job image added to original Draft ShapString vcarve)
(Completed job image added to original Draft ShapString vcarve)
baum wrote: ↑Thu Apr 08, 2021 12:37 pm For me the change from this pull request fixed it: https://github.com/FreeCAD/FreeCAD/pull/4680
The path still starts in the air, but has the correct depth and thus goes into the material to the extend needed.
The start point above the part is due to the path calculation being based on a pointy tip of the tool, but the tool definition having a tip diameter given, resulting in a z height offset.
Re: Ticket #4602 - Vcarve Cutting Air
The mentioned fix is still missing in FreeCAD 0.19.2, but is included in the current weekly build of FreeCAD 0.20. I hope it will be included into a future FreeCAD 0.19.3 release, as V-Carve is currenty broken in 0.19.2.
I noticed another (maybe linked) bug, which is present in 0.20 (and also 0.19.2). When doing the carving, the tool moves up and down between the ideal carving path and the (I guess) safety hight a lot - making the carving much slower than it needs to be. I'm not entirely sure, as my used font size is pretty small, but I think this sometimes produces little carving artifacts. I've used a 20° V-bit and a small font size, which produced the attached path and carving. You may see those artifacts inside the "g"s of "Energienutzung". These are less visible after a cleanup, but still there.
I noticed another (maybe linked) bug, which is present in 0.20 (and also 0.19.2). When doing the carving, the tool moves up and down between the ideal carving path and the (I guess) safety hight a lot - making the carving much slower than it needs to be. I'm not entirely sure, as my used font size is pretty small, but I think this sometimes produces little carving artifacts. I've used a 20° V-bit and a small font size, which produced the attached path and carving. You may see those artifacts inside the "g"s of "Energienutzung". These are less visible after a cleanup, but still there.