[ Fixed ] [ Ticket #4108 ] - Draft: Coords not relative to current working plane?

[Roy_043]

I am confused by coordinate input relative to the current working plane.

Please open the attached file and do the following:

1. Switch to the Draft WB.
2. Align the current WP with Rectangle001.
3. Make sure only Center snap is on.
4. Start the Draft circle command and hover over Rectangle001. The Task panel shows the coordinates as 0,0,0.
5. Click the point and create the circle.
6. Now create another circle but instead of clicking a point for the center enter 0,0,0 in the Task panel.
7. Result: The center of the last circle is the global origin and not the origin of the working plane.

Code: Select all

OS: Windows 8.1
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16117 (Git)
Build type: Release
Branch: releases/FreeCAD-0-18
Hash: dbb4cc6415bac848a294f03b80f65e888d531742
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Dutch/Netherlands (nl_NL)

Code: Select all

OS: Windows 8.1 (6.3)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.17877 (Git)
Build type: Release
Branch: master
Hash: 1e19ef5be4735f4200eaf99ce9e487d2be6f4151
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Dutch/Netherlands (nl_NL)

[bejant]

Start the Draft circle command and hover over Rectangle001. The Task panel shows the coordinates as 0,0,0.

For me coordinate fields are named:
Center X
Global Y
Global Z

(related post: https://forum.freecadweb.org/viewtopic. ... 14#p329214)

I think "Center X" is an error and should read "Global X". But this naming is still inaccurate, because now we are Snapping on a Local Coordinate System, and the coordinate field names don't reflect that use. Maybe the coordinate field names should change to indicate that we are using a LCS:

Local X
Local Y
Local Z

And now I suppose there should be a way (maybe a tickbox) to key in Global coordinates instead. (There could already be a method for this and I am simply unaware of it.)

Off topic, but interestingly enough, when using only Endpoint Snap instead of Center in your step 3 I can only Snap to the Endpoints on the lower edge of the rectangle band not the other 3 edges.

OS: Ubuntu 18.04.3 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19. (dated 2019-08-21)
Build type: Release
Python version: 3.6.8
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

[Roy_043]

The problem is that with keyboard entry you cannot enter local coordinates. Even though in step 4 you get visual feedback that the coords are expressed in the LCS.

The snap problem you mention has already been fixed:
https://forum.freecadweb.org/viewtopic.php?f=23&t=38812

[bejant]

The problem is that with keyboard entry you cannot enter local coordinates.

Yes, I agreed; and am wondering what you might envision as a remedy.

The snap problem you mention has already been fixed:
https://forum.freecadweb.org/viewtopic.php?f=23&t=38812

Thanks!

[Roy_043]

Remedy:
By default coordinates should be expressed and entered in the LCS. Only then does the concept of a 'current working plane' make sense.
Having a toggle to switch to the GCS would be a useful feature. But for global coordinates the user can also switch to the XY plane.

To add to my confusion:
1.
If you align the WP to one of the faces of the Extrusion the field names for the center point read:
Center X
Local Y
Local Z
But keyboard entry still results in GCS coordinates. The plane of the circle is aligned with the WP though.
2.
If you choose YZ (Side) for the WP and create a draft line from LCS 0,0,0 to LCS 1,1,0 (keyboard entry for both points) the line is created from GCS 0,0,0 to GCS 0,1,1. Which is correct.

[bejant]

Would you like to check if there already is a ticket for this problem, and if there isn't a ticket, add one?

[Roy_043]

Bug reported:
https://www.freecadweb.org/tracker/view.php?id=4108

[Roy_043]

I have started to look into this issue myself.

One of the things I stumble upon is related to accuracy of input. But this has been discussed before.

If the user enters a coordinate value with more decimals than the 'Number of decimals' setting, then this higher accuracy is simply ignored *. You can argue that this makes sense: WYSIWYG.

But look at the inputs in the image:

Number of decimals setting: 1

For the second point of a Draft_Line starting at the global origin the user has entered:
Length: 100,0 mm
Angle: 45,0
The dialog displays:
X: 70,7 mm
Y: 70,7 mm
Z: 0,0 mm

What will be the result? Will the length of the line be 100,0000 mm (Length input has priority) or 99,9850 mm (Coordinates have priority)?
The latter is the case. IMO this is confusing. It would make more sense if the coordinates could have a higher accuracy 'under the hood'. This would then also allow the user to directly enter coordinates with a higher accuracy.

Is there a default way to allow the user to do that: to enter more decimals than the 'Number of decimals' setting?

'Number of decimals' setting:
Edit > preferences... > General > Units > Number of decimals
Or:
Tools > Edit parameters... > BaseApp > Preferences > Units > Decimals

*
As I understand it the valueChanged event is triggered when the user enters a number, f.e. 1,1234, which is then displayed as 1,1. But when the input box loses the focus the valueChanged event is again triggered and 1,1 is read back as the new input.

[Roy_043]

Moderators: Please move this topic to the Draft, Arch & BIM forum. Thanks.

[Kunda1]

Moderators: Please move this topic to the Draft, Arch & BIM forum. Thanks.

Done