OS: "Arch Linux"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9666 (Git)
Build type: Unknown
Branch: master
Hash: 987630700d21f71f9c793d106add2106dbb14d84
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.9.1
The second day after updating all the trouble. That's how he sees the operation of milling groove.
I have previously tried to show that the program has problems with math. A specific example - end mill d6, size 300.5 Y, the program draws 25*2 lines, ie 25*2*6=300mm, lost 0.5 mm.
A snippet of the Central part -
(Pocket001 :TC)
G00 Z25.000000
G00 X142.500000 Y141.500000
G00 Z45.000000
G01 F500.000000 Z21.000000
G01 F600.000000 X250.000000 Y141.500000
G01 F600.000000 X250.000000 Y153.000000
G01 F600.000000 X142.500000 Y153.000000
G01 F600.000000 X142.500000 Y141.500000
Meanwhile Y153.000000-Y141.500000=11.5 mm, and should not be more than 6mm.
And groove makes miracles - see screenshot.
The program has problems with arithmetic.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
The program has problems with arithmetic.
- Attachments
-
- hren.fcstd
- (23.52 KiB) Downloaded 48 times
-
- Снимок экрана от 2017-01-17 19-48-10.png (200.83 KiB) Viewed 1410 times
-
- Снимок экрана от 2017-01-17 19-42-15.png (115.77 KiB) Viewed 1410 times
- sliptonic
- Veteran
- Posts: 3457
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: The program has problems with arithmetic.
There are two different problems happening here.
The problem with the pocket appears to be related to the problem described in this thread: viewtopic.php?f=15&t=19912
Prior to commit: 6e7c4915a3a11c32b1c82c128b6b6c0d8799c744 it didn't occur.
The uncut area in the center of the main pocket is an older problem. As best I understand it, it's deep in libarea. If you switch to zigzag pattern, it doesn't occur and you can avoid it or minimize it by tweaking the step over percent. The bug needs deeper debugging and should probably be reported with a good test case in Mantis.
The problem with the pocket appears to be related to the problem described in this thread: viewtopic.php?f=15&t=19912
Prior to commit: 6e7c4915a3a11c32b1c82c128b6b6c0d8799c744 it didn't occur.
The uncut area in the center of the main pocket is an older problem. As best I understand it, it's deep in libarea. If you switch to zigzag pattern, it doesn't occur and you can avoid it or minimize it by tweaking the step over percent. The bug needs deeper debugging and should probably be reported with a good test case in Mantis.
Re: The program has problems with arithmetic.
Yesterday was bug fixes (https://github.com/FreeCAD/FreeCAD/pull/456), which I reported a couple of months ago - thank you. And I would tell you about others, except arithmetic. What is on the screen - appeared around the end of the previous week, i.e. quite recently there were changes which broke the program. For comparison even put it on another computer, Ubuntu, freecad-daily FreeCAD 0.17, Libs: 0.17R9184 (Git), where this operation works fine.
OS: "Arch Linux"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9684 (Git)
Build type: Unknown
Branch: master
Hash: 0f4a5b4f958f960575570ff2a76e4138b1b4247f
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.9.1
In this case, the menu we can choose the method of execution of works OCCN
OS: "Arch Linux"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9684 (Git)
Build type: Unknown
Branch: master
Hash: 0f4a5b4f958f960575570ff2a76e4138b1b4247f
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.9.1
In this case, the menu we can choose the method of execution of works OCCN
- Attachments
-
- Снимок экрана от 2017-01-20 10-29-24.png (126.66 KiB) Viewed 1348 times
-
- 2.fcstd
- (26.04 KiB) Downloaded 46 times
Re: The program has problems with arithmetic.
I can confirm some strange behaviour which might rather be PartDesign related, but there are some issues with the provided model too:
- You use Pad as base for the job. I would rather expect body or Pad001, because Pad itself does not even have the selected Face15 which defines the path in question. This made me realize that I haven't really yet understood the concept of the job's base object, please can someone enlighten me? If I change it to body the path isn't generated at all
- The drilling object doesn't do anything. However, removing didn't improve things.
- I fully constrained your sketch. After that nothing worked with the path in question, I couldn't even repeat your problem.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.