unit mismatch error for dimensions

Discussions about the development of the TechDraw workbench
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

unit mismatch error for dimensions

Post by uwestoehr »

I encountered a major bug in TechDraw: since the dimensions contain by default no unit one easily gets a unit mismatch leading to completely wrong dimensions.

Take for example the attached file:
TD-unit-bug.FCStd
testfile
(35.68 KiB) Downloaded 59 times
There I have the dimension 0.5 and 50.00:
FreeCAD_HSRzaf9Ctp.png
FreeCAD_HSRzaf9Ctp.png (17.43 KiB) Viewed 2275 times
50 > 0.5 but it is not 50 mm, but 50 um. As the unit is not shown, TD must not just take the number and cut off the unit but it has to transform in this case the value to mm before it cuts off the unit.

@aapo since you are at the moment fixing TD issues, maybe you can have a look? If not, I will put it on my Todo list.
aapo wrote: .
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23107 (Git)
Build type: Release
Branch: master
Hash: ca57b84e62e38f87d0c03fb8e2b2caf2a1d0af51
Python version: 3.6.8
Qt version: 5.12.6
Coin version: 4.0.0a
OCC version: 7.4.0.beta
Locale: German/Germany (de_DE)
chrisb
Veteran
Posts: 53285
Joined: Tue Mar 17, 2015 9:14 am

Re: unit mismatch error for dimensions

Post by chrisb »

Confirmed.
Attachments
SnipScreenshot-15b232.png
SnipScreenshot-15b232.png (11.57 KiB) Viewed 2249 times
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
andergrin
Posts: 67
Joined: Sun Oct 11, 2020 7:52 am

Re: unit mismatch error for dimensions

Post by andergrin »

Possible workaround: switch to Metric small parts in Units preferences.
aapo
Posts: 608
Joined: Mon Oct 29, 2018 6:41 pm

Re: unit mismatch error for dimensions

Post by aapo »

uwestoehr wrote: Wed Nov 25, 2020 1:18 am I encountered a major bug in TechDraw: since the dimensions contain by default no unit one easily gets a unit mismatch leading to completely wrong dimensions.
Indeed. This seems to be a known problem for the original TD coders, but unfortunately it is a bit difficult to fix. The problem seems to come from two causes:

(1st) There is a bit of code in std::string DrawViewDimension::getFormatedValue(int partial) of DrawViewDimension.cpp that builds the dimension value and unit from Base::Quantity, which seems to use a internal core function virtual QString schemaTranslate(const Base::Quantity& quant, double &factor, QString &unitString);. The comment in the TD code seems to rightfully complain, that there is no mechanism in Base::Quantity to get the UserString as a requested unit. Thus, without core changes I don't see an obvious way to fix this.

Code: Select all

    Base::Quantity asQuantity;
    ...
    QString qUserString = asQuantity.getUserString();      // this handles mm to inch/km/parsec etc
                                                       // and decimal positions but won't give more than
                                                       // Global_Decimals precision
                                                       // really should be able to ask units for value
                                                       // in appropriate UoM!!
I think the best way to fix this would be to add 4 or 5 more schemas into the Base unit systems in UnitsSchema.h, i.e. "Length_nm", "Length_mu", "Length_mm", "Length_m", "Length_km", from which TD user could choose from for a particular drawing.

Code: Select all

namespace Base {

/** Units systems */
enum class UnitSystem {
    SI1 = 0 , /** internal (mm,kg,s) SI system (http://en.wikipedia.org/wiki/International_System_of_Units) */
    SI2 = 1 , /** MKS (m,kg,s) SI system */
    Imperial1 = 2, /** the Imperial system (http://en.wikipedia.org/wiki/Imperial_units) */
    ImperialDecimal = 3, /** Imperial with length in inch only */
    Centimeters = 4, /** All lengths in centimeters, areas and volumes in square/cubic meters */
    ImperialBuilding = 5, /** All lengths in feet + inches + fractions */
    MmMin = 6, /** Lengths in mm, Speed in mm/min. Angle in degrees. Useful for small parts & CNC */
    ImperialCivil = 7, /** Lengths in ft, Speed in ft/sec. Used in Civil Eng in North America */
    FemMilliMeterNewton = 8, /** Lengths in mm, Mass in t, TimeSpan in s, thus force is in N */
    NumUnitSystemTypes // must be the last item!
};

(2nd) Even if getting the Base::Quantity values in a requested unit, what unit should that be? Default unit, for sure, should be mm, but people building houses or microchips would complain about mm, so it should definitely be changeable, perhaps per TechDraw-view. This per-view unit information should then be added to the relevant TD classes ad Property::ViewUnit, which would then be part of the FCStd file format.

It seems to me that both of these obstacles should be overcome in order to fully fix this bug. It is certainly doable, but it'd contain core changes and new Property:: stuff, so it's not simple. As a final note, the TD function is named getFormatedValue() with single 't' which I find rather irritating, as that word should only concern aircraft manouvers! :D
aapo
Posts: 608
Joined: Mon Oct 29, 2018 6:41 pm

Re: unit mismatch error for dimensions

Post by aapo »

andergrin wrote: Wed Nov 25, 2020 10:13 am Possible workaround: switch to Metric small parts in Units preferences.
Yes, this seems to do it nicely. It's units schema number 6, probably added just for this case. However, when interchanging files with other user using some other units schema, the dimensions will be displayed wrong in TD. I wonder if TD should always use a predefined constant unit schema for a drawing, as I suggested in one of the posts above.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: unit mismatch error for dimensions

Post by uwestoehr »

aapo wrote: Wed Nov 25, 2020 1:04 pm

Code: Select all

    Base::Quantity asQuantity;
    ...
    QString qUserString = asQuantity.getUserString();
OK, but then it should be doable. We have classes that store the value AND the unit. So one then simply needs to check what unit the user set in the preferences as base unit, then recalculate the dimensions into this unit. I remember of having done this recently. Unfortunately I cannot have a look right now but when you look to what class the values of the comboboxes in the dialogs are stored, you should find it. It has method to get the unit because one can already enter e.g. "5000 um" and you get automatically 5mm.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: unit mismatch error for dimensions

Post by uwestoehr »

uwestoehr wrote: Wed Nov 25, 2020 1:27 pm We have classes that store the value AND the unit.
Yes, for example Base::Quantity ;) :
https://www.freecadweb.org/api/d8/d18/c ... ntity.html

So we need to getUnit() then perform the recalculation to mm (or whatever the user set).
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: unit mismatch error for dimensions

Post by uwestoehr »

I had a look and my proposal won't work that simple. There is already a preferences option to show the units. So we must change this option to be toggleable. If on, the values are kept as they are and the unit is displayed, if off (default) the the unit is omitted and the values are recalculated to be in the base unit.
I'll try to make a PR this weekend.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: unit mismatch error for dimensions

Post by uwestoehr »

aapo wrote: Wed Nov 25, 2020 1:12 pm Yes, this seems to do it nicely. It's units schema number 6, probably added just for this case.
But what about larger parts where you have e.g. a 2 m long piece and on it a feature with just 4 mm?
aapo
Posts: 608
Joined: Mon Oct 29, 2018 6:41 pm

Re: unit mismatch error for dimensions

Post by aapo »

uwestoehr wrote: Thu Nov 26, 2020 6:15 pm But what about larger parts where you have e.g. a 2 m long piece and on it a feature with just 4 mm?
It was in my proposal in the post above, where I proposed to add a UnitsSchema property for every view (where the user would select his/her projection schema, or choose to use the one from General Preferences, whatever that happens to be):

me in a previous post wrote:I think the best way to fix this would be to add 4 or 5 more schemas into the Base unit systems in UnitsSchema.h, i.e. "Length_nm", "Length_mu", "Length_mm", "Length_m", "Length_km", from which TD user could choose from for a particular drawing.

The main advantage of this system would be that every view would have an easily selectable unit (or the default unit mix-mashup, if the user so wants). This would make the TD Drawings open correctly on every user regardless of their user preferences, but still make it possible to select the default unit schema for every view creation, and of course change the unit schema of a view. The only downside would be the addition of 5 more UnitSchema:s, which would probably be used only in TechDraw at least for a while, but I don't see that as too cluttering.

Note that using this system there would not be a need to touch the unit-printing logic of TD. If the user would want to have the literal unit printed after every dimension number, (s)he'd select the FC default UnitSchema for the view, in addition to the "print units" option, and there would be dimension labels sucha as "1.2 m", "50 µm", "2 mm", depending on how large actual differences there could be on the drawing. If the user would want everything in micrometers, (s)he'd choose no units and "Length_mu" UnitsSchema for the view, and every value would be automatically converted to microns without actually printing "µm" after the numbers. Neat, and FC core seems to fully support this! It'd be just a question of adding the UnitSchemas and the View Property:: :D
Last edited by aapo on Thu Nov 26, 2020 6:45 pm, edited 1 time in total.
Post Reply