Hi.
Kicad Ver 5.1.10
Most of the coordinate values are normal.
However, some have a decimal 0.000001 error with a coordinate of 62.899999.
Is there no rounding at the decimal point 0.0000001?
There is nothing wrong with the coordinates in DXF.
Pcbnew uses 32 bit integers with a nanometer resolution.
Do you mean that in the DXF file your example coordinate is 62.9, and after import it turns into 62.899999 ?
Yes
Many of the X or Y coordinates change like that.
As if you canāt round off 0.0000001 seats and get thrown away when converting.
The basis of integer calculation is not rounding, but throwing away.
Donāt you calculate to avoid rounding errors?
Can you post the .DXF file?
Iād like to know if autocad is writing the wrong coordinates to the file, or KiCad is misinterpreting when reading the file.
A small sample file would be ideal, so if there is a lot of other stuff drawn around it, itās best deleted from the sample, as long as it still shows the problem.
I just had a look at one of my own .DXF files, (made with FreeCAD), and it has similar numbers with rounding errors in the .DXF file:
In my case however, there are enough digits in the .DXF file and KiCad appears to do the expected rounding when converting to the nanometer grid.
Hi.
Upload a partially left file.
If itās not a coordinate error,
Could there be an error when importing?
BlackWidow V3 US Layout - ė³µģ¬ė³ø.dxf (267.9 KB)
FWIW Qcad doesnāt mind it. i.e. no 8 or 10 decimal error.
Thank.
Does it mean that there are no errors in the DXF file?
Is there a way to ensure that the result of the import doesnāt have any coordinate errors?
I canāt say. Iām not knowledgeable about dxf files.
However just out of curiosity I looked at the dxf file with a text program.
I found this section:
I have little idea if its meaningful or just a fluke.
I also noticed that.
I also had a look at a .DXF file made by FreeCAD and LibreCAD.
All seem to use floating point numbers converted to text strings with their inherent rounding errors.
On import coordinates are truncated to KiCadās native resolution of 1nm.
In the .DXF file:
-9.999999999999122
In Pcbnew:
-9.999999
Those text strings derived from floating point numbers generally have a much higher resolution then what KiCad uses, and KiCad truncating them on import instead of rounding them feels wrong.
I made a āsmallā test file in LibreCAD with a single line, but LibreCAD adds about 15kB of crud to the file.
The definition of the line itself starts at line 2666
AcDbLine
10
-9.999999999999122
20
10
11
10
21
-20
0
Line_LibreCAD.dxf (15.6 KB)
I am thinking of making an issue for this on Gitlab, but am not sure if it is important enough.
1 Like
We actually donāt round the coordinates on import. We directly convert them to integers because thatās our internal coordinate format. The problem is the DXF specification is funky here. The DXF coordinates are in double precision format and are the true coordinates, meanwhile there is a $LUPREC variable that allows setting the display precision that causes it to round for the GUI. However internally at least in a real dxf program like AutoCAD, itās able to keep the two distinct coordinate sets. We canāt do that kind of thing in KiCad but we would need to respect $LUPREC. The problem is LUPREC is also optional and depending on how terrible the CAD tool is, it might not add the variable
Anyway, it can probably be improved a little but it is tricky. We need the double precision to process various DXF operations before we can even send it to the rest of pcbnew for translation to our objects. But we translate the double to integer format in pcbnew rather than the dxf importer so it doesnāt know what to do with precision at that point.
I understand that, and as I wrote before, I already noticed that the extra digits are truncated, and this is a very simple, but also sloppy solution.
The floating point numbers have about 3 to 6 or more extra digits of resolution, and rounding them to the closed integer that KiCad works with on import looks like a simple improvement for me. It will get rid of all those nines in coordinates, and the resulting integer would be much closer to what was in the DXF file.
Iām not very familiar with $LUPREC or with .DXF files in general, but something has to happen when converting floating point numbers to integers.
My personal preference would be an entry box to specifiy the resolution on import, and if a $LUPREC variable is available in the file, using that as a default (with ability to overrule) would be nice too.
I am looking at it, Iāll probably blow up SVG imports in the process though hah. The internal api is not ideal at the moment with the way its treating coordinates during import.
But o well, I wanted to start fumigating/removing wxPoint anyway~~
1 Like
I understood the explanation.
Coordinates in AutoCAD are 10, 10
coordinates Dxf 9.99999999999122, 10
The Kicad coordinates are 9.99999, 10.
I was surprised to see the coordinates go like that when they were changing to Dxf.
I was surprised that Kicad chose 0.0000009 instead of 0.0000001.
It not a matter of KiCad āchosingā a value. This is simply a rounding error and these sort of issues are very common. Try dividing 2 by 3 on a pocket calculator and then multiplying the result by 3. More info here https://floating-point-gui.de
This problem is not just a matter of floating-point computation.
The same causes apply to binary (Hex) calculations.
It seems to be the difference between determining how far to correct the error or how far to round it up.
Eh, the problem here is the graphics importer converts from import coordinates to kicad coordinates too late in the pipeline to apply the dxf specified rounding factor thatās defined in the file. Currently this part of the pipeline is shared with SVG import so itās a mess to untangle. Especially because I cannot just convert dxf coordinates immediately on first read to kicad coordinates. Thereās all kinds of transformations that have to be applied on the raw value first which requires parsing the entire file first.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.