Tested using the development version, v0.21.0 rev 31391 (Git) on Windows 10 v2009 64-bit.
Set units to "Building US"
File >> New
Switch to Draft workbench
Set working plane to Top (XY) and switch to top view
Click the toolbar button to add a 2 point line
Hit RETURN 3 times to accept 0, 0, 0 for the first point
For the second point, hit RETURN to leave delta X == 0, for delta Y enter -17.5' to go down 17' 6", then hit return twice to finish the line
In the properties window for the new line, notice it shows the line as being 16' 6", not what was entered
If you repeat this but use a positive relative value for delta Y it works and gives the correct length. To be sure, I put both lines beside each other and verified the first line is shorter.
Did some more testing and then noticed if you type -17' 6" into the delta Y window and move to the next field it changes it to -16' 6". When you type -17.5' it doesn't change it there visibly but it gives you the shorter line when you create it.
Spent a bit more time with it, with quite a bit of frustration. Got to the point where I started thinking you can't trust what it's doing as it's continually screwing up the delta values.
Finally, I came up with the workaround that you just need to build everything from the lower left and go to the right and up with your deltas. Even if it means building something at a random location then moving it using the appropriate snapping, keeping your deltas positive at least gives you what you expect.
Probably problem arise because computers have some difficulties when dealing in something overcomplicated like anachronistic way of measuring things.
As they are "not numbers" and should be managed in special way.
Many if not any have no capabilities to deal with "fractional units" that are not linear I work sometimes during my modelling jobs with US measures, but it is nit even very readable to write.
to assign a variable value, let alone difficulties that arise when parsing an expression, you have to convert values in something manageable and the reconvert result in "desired units".
Regards.
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
onekk wrote: ↑Mon Jan 30, 2023 6:29 am
Probably problem arise because computers have some difficulties when dealing in something overcomplicated like anachronistic way of measuring things.
As they are "not numbers" and should be managed in special way.
Many if not any have no capabilities to deal with "fractional units" that are not linear I work sometimes during my modelling jobs with US measures, but it is nit even very readable to write.
to assign a variable value, let alone difficulties that arise when parsing an expression, you have to convert values in something manageable and the reconvert result in "desired units".
Regards.
Carlo D.
I was entering the value as -17.5' without any fractions. FreeCAD, with "Building US" units active converts that to the fractional representation in the window for you. But then when you complete the line, it doesn't get the right value, you end up with -16.5' instead.
Yes, dealing with fractional units can be complex. If you're working with "Buiding US" units, which is what my measurements are using, you're sort of stuck with that though
When dealing with US units, I convert all in mm when modelling, less hassles with conversion, I know that it is not the optimal solution, but at least it is numerically correct and spinbox work a expected
There are around even some technical discussions, sadly I could not find the relevant post, where thing were explained.
Maybe someone has noted some links and could point you to the discussion.
Regards
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
My attempts to work around this problem lead me to believe the underlying issue has to do with the way the entry is resolved during parsing, so it's a programming problem that should be easily solved. When you have more than one axis of entry, you enter a value and press enter, doing this for each axis before pressing Enter the final time, which submits all of your entries for final processing and rendering of the resulting line.
For entry of negative fractional distances on any given axis, the minus sign appears to only be applied to the first portion of the entry, not the entire entry. When the entry is for more than 12", the parser first converts it to feet and inches. When the entry is fractional, it places a + sign between the whole inches and the fractional portion. If the whole inches is 0, the 0 is not included and only the fractional inch is displayed without the + sign. This all happens after pressing Enter the first time.
My example entry of -12.25" gets converted to -11.75" in this way: It is first converted to -1' 1/4", and that is what is displayed after pressing Enter the first time. After pressing enter the final time, the line is rendered as -11 3/4". If you think of this mathematically, -1' + 1/4" is -11.75", but the negative should be applied to the entire value, so internally the correct equation should be -(12 + 0.25), not -12 + 0.25.
I was able to work around this by entering -12-.25", -12"-.25", -1'-.25", and -1' 0+.25".
When I tried -13 1/4", however, it acted correctly and resolved to -1' 1+.25".
Later I had better success where I had the orthogonal snap turned on, leaving only one axis to resolve.