Confusion about DXF import board outline, scaling

I have an (admittedly ancient) tool that I had some old PCB layouts in, the layouts themselves are NG but the board outlines are pretty close and just need some tweaking, the tool was all integer in mils, it can export the outlines in DXF which it does OK but even that’s necessarily an early version of that format because of the age of the tool. So I exported a test DXF, on my system I have the latest KiCAD and the free Layout Editor and LibreCAD (and suppose I could add FreeCAD too). Now both Layout Editor and LibreCAD can import the outline so I can at least see it but when I try it in Pcbnew I don’t even see the outline, it’s apparently way larger than the visible title block (the native one, not trying to import one). Now I guess any of these tools is capable of editing the outline but if I can’t get it into Pcbnew I’m probably in trouble. I’m new to KiCAD but I’ve sent out quite a few PCBs on the old tool and had pretty decent success. So I’ve got a few questions here, the first is are there settings in Pcbnew that I need to have correct that would allow my DXF import to work correctly? I want to continue to work in English units, I’m used to a tool that was integer units, I also need to be sure in this system (which obviously computes in floats) that I “get closure” so how do I now know that two lines meet at precisely the same point, do I try and get the start of a new line to “snap” to the end of the old one or just how does that work? And do I even need to worry about whether Pcbnew can understand the DXF since it seems like maybe the compatible autorouter is already integrated into Layout Editor so maybe I just use that exclusively? (I will be using net classes so it’s certain I also need that capability.) I’m sorry that I have to ask so many questions but my old tool is about two decades old, when you have to “jump that far” all at once it can get a little overwhelming.

I skimmed over your wall of text and found one thing that i can answer. A tip: format your text such that it is easier to read (At least insert empty lines at some logical points)

DRC in version 5.1.x should report where this is not the case.

You could try opening it with LibreCAD or some other tool and save it to a different dxf format version. LibreCAD can export R12. But tells me that “DXF coordinates are always without dimensions so that the reader or user needs to know the drawing unit or has to extract it from the textual comments in the sheets.” KiCad nightly builds (I don’t have v5.1 at hand) have “Import scale” in File->Import->Graphics dialog.

That’s after the fact, how do I draw so they at least SHOULD be meeting? (Given that I’ve been using a system that’s integer in mils you by definition are either exactly on or you’re off by a multiple of mils, in a system with much higher res you could be off by an amount you can’t even detect.)

Draw one line, start drawing another, press Alt or AltGr (right Alt in some keyboards?) and keep it press, keep drawing near an endpoint of the first line. The line you are drawing should snap.

Yes I see a parameter box for that but I don’t see any help discussion about what “import scale” even means. The previous tool was supposedly in inches from what I know. Maybe I need to “assume” it was in mils, do I then try importing with a scale of .001?

That’s great info, what about a line to an arc? I guess I have to draw the arc first and “snap” the line to it?

There was a bug, that changed mm into iches.“I think I can remember”.

This bug is still in all of the “Stable” versions; “I think I can rembmer”.

The recieving CAD tool should be able to scale 1 dimension such that it fixes all the other dimensions.

The only bug report i could find regarding wrongly scaled dxf is this one
But there it was discovered that the problem was with inkscape not with eagle.

I am also (rather slowly) moving from my old tool (from 1997) to KiCad.
I was also used to have everything in integer units, but I got with it into an error that I decided even in that old tool (I am still using) to get out of integers. The error was made by coincidention of few sources that were made that way just because we made that way since “always”.

  1. When designing footprint with 0.5mm raster I rounded pad positions to integers.
  2. I used pad width of 9 mils.
  3. I didn’t allow programm to define apertures from PCB but used our aperture list (agreed with PCB manufacturer 20 or more years ago).
  4. I used Gerber format 2.3 (when I got from someone else PCB designing I was just told to set that format and it always worked so I even didn’t know what that means - that really menas that everything was rounded to integer mils).

There were no 9 mils aperture so program tried to made pads using 8 mils aperture. So to make a pad at position 0 it wonted two passes with that aperture but at positions -0.5 and 0.5. But everything were rounded to integers (format 2.3). I don’t know why rounding was randomly but the effect was - some pads were 8 mils, some were 10 mils. Some 8 mils had a short lines at their ends makeing them to look like digit 1.
Since that moment I decided to stop keeping with old time decisions:

  1. Limited aperure set was important 20 years ago when they had to be installed in photoploter, but now it is only software.
  2. Format 2.3 was important when file sizes were important.
  3. 1 mils accuracy was enough were there were no footprints with 0,4 or 0,5mm rasters.

Moving to KiCad I decided to switch from mils to mm and suggest you to consider the same (I have even decided that 0402 will now be 1005 :slight_smile: )

I suppose KiCad (at least in what you are editing) is not in floats but in integers where 1 means probably 1E-6mm.
Small gaps at Edge.Cuts are accepted by KiCad. I was told here at forum how small is small but I don’t remember. I just remembered that it is bigger then I supposed so I don’t expect to get into that problem if I only don’t left visible gaps.

Yes, I believe the tool I was using came out around 1999, not sure (it could be the follow-on of what you’re using). I have 5 different boards I’m doing right now and they all have fairly complex outlines and the apparent inability to import DXFs without completely losing all accuracy has set me back enormously. I guess the old tool is “still usable” (I have it running under Windows 7 Professional in VirtualBox on my new system, by some miracle the virtual system is actually markedly FASTER than the old “real” system but Microsoft support is going away). I think you can guess what part of his anatomy I’d like to string up the guy who “forgot to fix” the DXF scaling problem!

For “field maintenance” purposes I still use almost exclusively through-hole parts (occasionally I’ll put an SMD on a socketed adapter). I haven’t completed a board layout under KiCAD yet but I haven’t found any of the parts I was using that there isn’t either an exact match footprint or something close enough to use anyway (the PIC controller #s supported are a little out of date but fortunately the outlines at exact pin count at the same “performance level” are identical, or so I’ve found so far anyway).

I have however over this small count of projects found a nearly endless list of hardware bugs in the PIC parts I’ve used (they mostly but not exclusively deal with A/D input range issues but in one case the ISR hardware did not restore context correctly) and their MPLAB X IDE “assemblers” are a complete joke and have a record of suddenly “forgetting” symbolic equates and using zeroes for some values mid-assembly!! (I’ve tried their XC8 “free C compiler” and the string handling routines have ABYSMAL performance compared to assembly.) In my opinion anyone who successfully completes ONE project with tools THIS challenged deserves some kind of medal of valor for service beyond the call of duty!!
And you report these issues to what they humorously refer to as “support”, do they ever find their way into the chip errata? Dream on my friend, if you find something wrong they appear to seriously believe YOU must be hallucinating!

Hey, @maui, is this scaling issue something that StepUP can help this guy with if he is willing to install YASP (Yet Another Software Package)?

I do not think stepup support scaling in of itself. It could however help for future projects as it is easy to design outlines directly in freecad. Kicad StepUp: a Seamless ECAD/MCAD PCB Data Integration

regarding the scaling issue:
I would suggest to open the dxf in for example libre cad and save it with it as we know that libre cad dxfs are well supported by kicad. But make sure it is scaled correctly when viewed in libre cad as it is possible that your tool saves dxf in such a strange way that kicad is not the only one having trouble with it.

Could you please simply post a test DXF outline exported from your CAD with a known dimension?
Then it could be much easier to help…

Hey thanks @Rene_Poschi, you nailed it!! I had tried importing into LibreCAD but I had some one or more of the drawing setup params in millimeters or something and I wasn’t seeing integers on the screen for the selected item so I bailed without thinking it all through. I fixed the setup and TADA!! integers again, and yes LibreCAD will “save as” (not export as, like I was thinking) a modern DXF quite easily.

See the tool was SO old I was just thinking the DXF format was SO obsolete a modern tool probably wouldn’t “get it” anyway, and in fact when I had tried to open the original DXF directly in KiCAD it did throw me some obscure error about an illegal character or something. It’s hardly surprising that there’s DXF incompatibility, the original developer of the format was AutoCAD so their customers could import older drawings into newer tools, and the main reason was because the actual drawing file .DWG format wasn’t compatible between the different product releases, but in fact the .DXF formats weren’t much more compatible anyway. Thanks you guys rock!!

Just for reference a “sample” board outline DXF that I was testing, it goes into LibreCAD as a tiny 10K byte file but comes out as 37K, hey this is anything but a “complaint” but I’m just saying it’s certainly not as if the only reason for “passing it through” the other program is to simply strip out an offending character or something, the difference is apparently pretty significant, I mean who knew?? (Don’t know whether it’s binary vs. ASCII or ints vs. floats nor do I care that much, all I have to know is this just took about 10-12 hours out of my workflow!!!)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.