I’ve just downloaded the latest LibreCAD (146MB installed), and loaded a box DXF from the web, that KiCad fails to load. (no errors, ‘loads-blank’)
LibreCAD has save-as choices of DXF-2007 back to DXF-R12
A9CAD(18MB installed) & KiCad both ‘load blank’ on original web, and both load OK, once LibreCad does a Load/Save as DXF-R12.
If you use freecad have a look at the kicad-stepup workbench.
It can export footprints directly. (You will get pads directly. No need to eyeball them from a dxf overlay)
Good point, but note there can be DXF files that load-blank into freecad.
The test case above needed a LibreCAD load/save as DXF-R12, to then load into KiCad/FreeCAD.
@PCB_Wiz, any chance you can post the link for that sample or attach it right away?
@aaltomikael, same for you, can you please attach a sample file for us?
Even if this doesn’t solve your problem right now, it might be some step-stone for a dev later down the road if he needs to troubleshoot things.
I’m sorry but I can’t publish the part I’m strugling with, because it’s my customers.
I’ll try to find a suitable variant behaving the same way.
Only this way we can pinpoint the problem… but as I said I can’t publish it sadly.
I even tried to export from freecad and import back again and it works, very strange.
Also as I should have done in the first place was to import the untouched original dxf-part into kicad in the begining:
IT WORKS !
-So as a conclusion, the problem is in freecad, it inserts something od into the dxf. But still the strnge thing is that other progs like pads, eagle etc. will import it correctly !?
Still I will comper the two dxf:es and check the diffs.
And a GREAT thanks to everyone’s help !!!
I will post the resolution as get it done.
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 ?
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,
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
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.