Scale error importing DXF with built-in importer

[fatbeard]

Hello.

When I import the file

TEK knob.dxf

(102.49 KiB) Downloaded 51 times

the drawing gets scaled down by a factor of 25.40000499 (while the scale factor is set at 1), making the import unusable. Deep analysis of the DXF file (made with QCAD 3.15.5.0) reveals that there is no unit set (no $INSUNITS entry in the header section), so I expected to get the drawing in the units set for FreeCAD (which are mm).
The 'standard' importer apparently assumes inches and introduces a rounding error...

Screenshot from 2020-10-22 17-15-41.png (3.89 KiB) Viewed 1557 times

The legacy importer luckily gets it right (the line in question is exactly 1.35000000 mm long), but the term 'legacy' implies that it will be obsolete at some point in the future...
Setting the scale factor in the importer preferences kinda works, but is limited to just 4 decimal places so it leaves a rounding error which I find a bit too large...

Did I do something wrong or is this a (un)known bug?


OS: Linux Mint 20
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.4.
Build type: Release
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.3.0
Locale: English/United States (en_US)

[Roy_043]

There is something wrong with the DXF. The MEASUREMENT is 0 (zero), which indicates imperial units. The legacy importer ignores this setting but the new importer does not. But obviously the new importer does not get it right. It uses a wrong factor (1/25.4 instead of 25.4)

PR:
https://github.com/FreeCAD/FreeCAD/pull/3992

[fatbeard]

Okeeejh....
I just manually changed the zero to a one in the DXF file and it works, sorta: I now get a line of 1.349493980407715 mm.
For something that is exactly 1.350000000000000 mm it's pretty close, but no cigar.
I know, i know, nobody will notice those missing few angstroms, but still...

It looks like the number in the DXF file is first converted to inches and then back to millimeters, thus introducing an unnecessary error.
It also looks like the numbers get rounded to the specified precision (preferences-unit-decimals) during the calculations, thus introducing even bigger errors: at 11 decimals the reported line length is 1.34999990463 mm.

A bit strange, though: one declares the measurement type imperial or metric, but does not specify the unit?
How the #@ are you supposed to know if it is in micro inches, mils, inches, feet, yards, miles, nano-, milli-, centi-, deci, deca-, hecto-, kilo- or gigameters, microns, angstroms, lightyears, astronomical units or even parsecs?
All of these units are supported by the DXF format you know...

Oh well, I'll stick with the legacy importer for now to get exact values (the colors are nice, too)...

[Roy_043]

This is complex.

For one thing the legacy importer obeys the Draft internal precision setting:
Edit > Preferences... > Draft > General settings > Internal precision level
You may want to crank that up from the default value of 6.

You are correct in saying that the line segment is exactly 1.35 drawing units long. But I doubt the level of accuracy you suggest. Keep in mind that computers calculate using binary floating point numbers instead of decimal numbers. Some decimal numbers cannot be exactly represented in the 'float' format. And calculations with floats always have a limited accuracy. Translated to the decimal format the accuracy is ca. 16 significant figures. This is one of the reasons why you should always try to create your model close to the global origin.

All of these units are supported by the DXF format you know

Yes, I know my way around the DWG/DXF format. The INSUNITS setting is ignored by both the old and the new importer. In the DXF this setting is 0 (=unspecified) anyway.

I have tried to import the DXF with the new importer after changing the MEASUREMENT to 1. And in my case the length of the line segment is more exact. Maybe there is something wrong with how you have tried to measure the segment? I have used the Draft_Dimension command and have of course also used Draft_Snap_Endpoint.

[fatbeard]

I have used the Draft_Dimension command and have of course also used Draft_Snap_Endpoint.

I just used the Measure Distance tool under the assumption that when the point changed color it was a snap. That will be the source of (at least some) of the discrepancies I observed...

I am still getting to grips with the whole UI, and learning how to create objects.
I did some 'simple' ones without much difficulty and decided to step up the game to a conical, ribbed knob with wings:

vlcsnap-00017.png (366.41 KiB) Viewed 1453 times

I got the main body and wings under control, but am struggling with the ribs: they just don't come out right yet. But I'll figure it out...

Thanks for the help and insights so far.