I may have missed it, but can't currently see any references pointing this particular behavior.
(v. 0.2)
The attached drawing has a single "draft" line.
The length of the line can be changed at 1mm increments for as long as the length is less than 1000mm long.
Once the length is 1000 mm and over, it cannot be changed in increments of 1mm.
Once the length is 1000 mm and over, increment jumps to 10mm chunks.
For example:
Length can be 997, 998, 999, 1000 mm.
However length cannot be 1001mm. It can be 1010. It cannot be, say 1005mm.
It jumps from say 1000, to 1010, 1020, ad infinitum.
Thanks for any suggestions.
This behavior occurs in the following version (v 0.2)
==============================================
OS: KDE neon User Edition 5.22 (KDE/plasma)
Word size of FreeCAD: 64-bit
Version: 0.20.25065 (Git) AppImage
Build type: Release
Branch: master
Hash: 4de2ad46b2b9c78ac2721a0dbea7c19306261095
Python version: 3.9.4
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2
Locale: English/United States (en_US)
==============================================
...but not in the following versions,
==============================================
OS: KDE neon User Edition 5.22 (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 2021.615.24301 +3584 (Git) AppImage
Build type: Release
Branch: LinkStage3
Hash: d1e4d1c5abdedda669e54d1a41b5c08077f7e561
Python version: 3.9.4
Qt version: 5.12.9
Coin version: 4.0.1
OCC version: 7.5.2
Locale: English/United States (en_US)
==============================================
OS: KDE neon User Edition 5.22 (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 2021.615.24301 +3747 (Git) AppImage
Build type: Release
Branch: LinkDaily
Hash: ecbfba008c481db4cb17bf8bd514b2d12690a8e5
Python version: 3.9.4
Qt version: 5.12.9
Coin version: 4.0.1
OCC version: 7.5.2
Locale: English/United States (en_US)
==============================================
OS: KDE neon User Edition 5.22 (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24291 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.19.2)
Hash: 7b5e18a0759de778b74d3a5c17eba9cb815035ac
Python version: 3.8.8
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)
==============================================
Length / Offset behavior in v. 0.2
Forum rules
and Helpful information
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help
Also, be nice to others! Read the FreeCAD code of conduct!
Also, be nice to others! Read the FreeCAD code of conduct!
Length / Offset behavior in v. 0.2
- Attachments
-
- Line-Example_01.FCStd
- (6.18 KiB) Downloaded 14 times
Re: Length / Offset behavior in v. 0.2
Confirmed. The problem is related to the number of decimals used for units and how FreeCAD interprets user input.
Apparently 1001mm is converted to 1.001m, and if the number of decimals is 2 this is converted to 1.00m. Weird behavior IMO.
Apparently 1001mm is converted to 1.001m, and if the number of decimals is 2 this is converted to 1.00m. Weird behavior IMO.
Code: Select all
OS: Windows 8.1 Version 6.3 (Build 9600)
Word size of FreeCAD: 64-bit
Version: 0.20.25065 (Git)
Build type: Release
Branch: master
Hash: 4de2ad46b2b9c78ac2721a0dbea7c19306261095
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.0
Locale: Dutch/Netherlands (nl_NL)
Re: Length / Offset behavior in v. 0.2
Thanks for checking this out.
I do think it's a show stopper kind of behavior.
I haven't studied how to start a bug confirmation process yet.
I hope more people can look into this, and offer their takes on the matter.
I do think it's a show stopper kind of behavior.
I haven't studied how to start a bug confirmation process yet.
I hope more people can look into this, and offer their takes on the matter.
- Shalmeneser
- Veteran
- Posts: 9560
- Joined: Wed Dec 23, 2020 12:04 am
- Location: Fr