If you can atleast find out what is different (I suspect a header flag) it will be something the devs may be able to work with.
test.dxf (8.9 KB)
Here is one. It is exported from Onshape as a “release 11/12” file. It doesn’t seem to matter which release I choose. When importing to kicad, the result is 1/25.4 the correct size. The file is in inches. I don’t see anything obvious in the dxf giving the dimension or a scale factor.
header tag “$LUNITS” with value 2, on line 278
Its not clear, but it appears “2” is used as feet for the units in another program.
I suspect the lack of “$INSUNITS” tag is what is causing the issue, it seems to be an issue with a number of dxf imports / exports,
Try manually editing that LUNITS value, if it doesnt change, add a $INSUNITS tag value of 1 (Inches), I suspect without this tag kicad defaults to mm.
so
$INSUNITS
70
1
9
One of these should make clear the underlying issue.
Changing $LUNITS to 1 didn’t change the imported scale. Adding $INSUNITS gives the correct behavior.
I now see that SolidWorks exports dxf’s with the $INSUNITS variable, and those dxf’s work fine when imported into kicad without modification.
That solved it !
I added both:
$LUNITS
70
2
9
$INSUNITS
70
1
9
-Both where missing from the freecad export. And they need to be both in the file to work accordingly.
There must be some other vari’s other sw use to get the correct unit-base configured ?
1 Like
Is there any chance you could attach an effected freecad export. Even if you just grab the above posters file and re-export it.
Now that i know what is missing. We may aswell find a workaround for the devs,
2 Likes
My office uses AutoCad 2018 and FreeCad and LibreCad cannot open the DXF at all. It seems that every AutoCad release breaks the Opensource projects. Unfortunately DXF is not an open standard
1 Like
David, have an example file? If we are to make kicad work with all these sources, saying “Read this string and it will work” is going to be very quick for the devs to bake in,
To maui, Again, its not clear that they follow the same unit table, because feet would not make sense for an inch scaled file.
So digging more, the attached file is exported from Autocad R11/R12,
http://help.autodesk.com/view/ACD/2017/ENU/?guid=GUID-A85E8E67-27CD-4C59-BE61-4DC9FADBE74A
Equally it does appear autocad keeps its dxf format pretty open,
Ok for $LUNITS and $AUNITS, 1 is deg/min/sec format, 2 is decimal format.
And for all autocad files, it defaults to Inches if the $INSUNITS flag is not present.
So the patch for autocad files would be, (Psudo code)
IF($ACADVER exists & $INSUNITS does not)
m_DXF2mm = 25.4;
That should be a pretty simple patch to make autocad DXF units reliable.
I created the following thread on the FreeCAD forum:
https://forum.freecadweb.org/viewtopic.php?f=8&t=28925
@aaltomikael Can you access the thread above and tell us if you have that FreeCAD option enabled or not?
Looks like the exact patch would be:
void DXF2BRD_CONVERTER::addHeader( const DRW_Header* data )
{
std::map<std::string, DRW_Variant*>::const_iterator it;
m_DXF2mm = 1.0; // assume no scale factor
for( it = data->vars.begin(); it != data->vars.end(); ++it )
{
std::string key = ( (*it).first ).c_str();
if( key == "$DWGCODEPAGE" )
{
DRW_Variant* var = (*it).second;
m_codePage = ( *var->content.s );
}
else if( key == "$INSUNITS" )
{
DRW_Variant* var = (*it).second;
switch( var->content.i )
{
case 1: // inches
m_DXF2mm = 25.4;
break;
case 2: // feet
m_DXF2mm = 304.8;
break;
case 5: // centimeters
m_DXF2mm = 10.0;
break;
case 6: // meters
m_DXF2mm = 1000.0;
break;
case 8: // microinches
m_DXF2mm = 2.54e-5;
break;
case 9: // mils
m_DXF2mm = 0.0254;
break;
case 10: // yards
m_DXF2mm = 914.4;
break;
case 11: // Angstroms
m_DXF2mm = 1.0e-7;
break;
case 12: // nanometers
m_DXF2mm = 1.0e-6;
break;
case 13: // micrometers
m_DXF2mm = 1.0e-3;
break;
case 14: // decimeters
m_DXF2mm = 100.0;
break;
default:
// use the default of 1.0 for:
// 0: Unspecified Units
// 4: mm
// 3: miles
// 7: kilometers
// 15: decameters
// 16: hectometers
// 17: gigameters
// 18: AU
// 19: lightyears
// 20: parsecs
break;
}
}
else if( key == "$ACADVER" )
{
DRW_Variant* var = (*it).second;
m_DXF2mm = 25.4;
}
}
}
Not yet on launchpad, but may make an account tommorow if nothing new comes up.
No it’s not enabled. Please don’t say this was the solution… I can’t test unitil tomorrow,
but I’ll suppose this solves it. I’ll get back asap after test.
->I noticed the “legacy”-thing, but really thought it was something old and obsolete ?
We’ll see. Latest post on FreeCAD forum indicates the mentioned option may not affect export at all
Humm I think this patch would force inches instead of millimeter, opposite to what is now… so it wouldn’t solve the issue, but just will add a different behavior from before…
The best is to fix FreeCAD exporter, adding units info to DXF file.
The fun you find while digging into obscure specifications
$INSUNITS was introduced in the “Autocad 2000” specification for DXF.
This means any export methods set to AC1006 = R10, AC1009 = R11 and R12, AC1012 = R13 or AC1014 = R14. Will not have that tag present if the tool is respecting the export option,
Freecads export is for AC1009 / R12, so it will never include that tag so long as they are following the specification, and to include it would involve them remaking the exporter to support whatever the Autocad 2000 version is.
Before this, It was simply that DXF files where unitless, Most tools like solidworks and Autocad assumed this to be in inches if not specified on import,
So my psuodocode would then become
When ACDVER = AC1006 or AC1009 or AC1012 or AC1014,
Import as inches,
Now with new info, It would imply the need to add a units dropdown box to kicad to resolve this correctly. as not every tool will export as inches.
5 Likes
+1 
from my side … (I reached 20 chars 
)
Now would be the time to create a bug report. The devs do not really follow this forum.
More info see: I found a bug. What now?