One little issue with this VCF board linked above.
Just now in 3d view I noticed that there’s no drill hole on two of the jacks:
The footprint references are exactly the same “S_JACK” but they do look different in footprint editor, the two actually missing that drill hole:
With hole:
Without:
footprint assignment is the same:
That suggests two footprints. Are they exactly the same in the Eagle design ?
That suggests two footprints. Are they exactly the same in the Eagle design ?
I actually don’t know. I don’t understand Eagle at all so don’t know where to:
I can actually move the holes separately to the other stuff:
I really don’t understand much about Eagle I must confess 
About the missing drill hole in two of the jacks:
The footprint is called:
Pure_VCF_SMD_V2_4:S_JACK for both. If I tried to change the ones without hole to the same name, nothing happens:
However, I can mess up the working ones by doing just the same. Hitting apply here will remove the yellow drill mark:
So I guess during import the “good” footprint got overwritten by the bad one but the mods that was already made on the pcb still got the good one?
I could fix it by opening up the good one and save it as “GOOD ONE” in the footprint editor on the pcb lib and changed the bad ones to that:
Just wanted to report that there seems to be some kind of name clashing going on here on import.
Weirdest thing. Actually it seemed to work at first, but noticed that the holes wasn’t there on my panel. It’s there on my board now, but then I have a script than panelizes and it’s not on the panel:
Holes on board:
No holes after panelizing:
My script doesn’t copy over the edge cuts so I guess there’s something wrong there. It’s on edge cuts on both the working and not working ones though (since I made them the same):
I guess I’m just going to make that a proper drill hole instead. Just reporting import issues
I think you might be right, there are two version of “S_JACK” in the Eagle file. One is in a library called “GMSN” the other in a library called “INSTRUO”. It appears that the KiCad import mashes all the parts into one library, so there might be a conflict.
Looking at the Eagle file though, I’m not sure that explains the missing hole, both appear to have three pads.
Oh, I see what they have done, to create an unplated hole they’ve put a cutout on the outline layer, that won’t work well in KiCad 
One of the S_JACK footprints has that cutout, the other doesn’t.
To convert that to KiCad, it really needs to be a proper NPTH pad.
One thing to bear in mind is that an Eagle project may have bodges which need fixing before running the import, it’s hard to automatically convert some of the non-standard tricks used in Eagle.
Yes, I just did it a proper hole instead:
Now it works fine:
One thing to bear in mind is that an Eagle project may have bodges which need fixing before running the import, it’s hard to automatically convert some of the non-standard tricks used in Eagle.
Yeah I realize that, but my Eagle skills are beyond bad. I literally don’t understand where to click to do anything. Don’t really want to spend any time there if I can fix it in KiCad instead.
Thanks for all help!
One more tiny thing:
It seems all 0805’s courtyards have gotten on Dwgs.User (drawings?). I don’t know if this is an error on the Eagle source or import though.
I hope I don’t sound negative by reporting soo much, I’m really happy with the import now. Just want to contribute with real use case testing. Please let me know if you want me to shut up
No, such real-files testing are important to get the details ironed out. The more the better
The surprise is, it seems to have managed to render as a hole.
Has anyone tried to import footprints with slots from Eagle ? (plated and non plated ?)
Testing this some more, I find it almost works 100%, and is probably good enough to import.
From that, I’d say the Eagle import is working fine.
The ‘bodge’ bobc mentions, imports as the same bodge, and does make it to the gerbers, so I’d expect the gerbers KiCad <-> Eagle are close to matching.
KiCad does not yet have full routing visibility on the footprint keepout, so that’s a caveat, but I believe support of footprint cutout is on the road map (or certainly should be), so I’d say the translation is correct here.
KiCad ideally should also have DRC checking for traces across Edge.cuts
Now another question popped up. So I’ve started converting another board, this one:
https://www.befaco.org/en/even-vco/
Here I mostly got issues with tracks overlapping pads to probably due to the large amount of non-straight tracks. After fixing all of these, all I’m left with in DRC is unconnected power rails, that’s +12V, -12V and GND:
Is there some simple trick here on a multi-board design? They are connected together by pin’s together with a lot of other signals, however, those other signals are differentiated in schematic while the power net’s are not. Therefore these are giving me DRC errors. Is there any simple trick here without modding the schematic too much? Just love having DRC going through with 0 errors, that has saved me before…
There is not really a recomended method since having two boards in one design is not a recommended use. If just want to get rid of the DRC error, you could put a trace on an unused layer. IOW, set it to 4 layers, make a trace on one of the inner layers joining two through holes of the selected net. Generate gerbers for top and bottom as normal and they will be unaffected by the extra traces. Of course this method does not work if you submit KiCad project to fab house!
Having two boards in one Gerber may present issues with the fab, unless you are etching your own boards.
Having two boards in one Gerber may present issues with the fab, unless you are etching your own boards.
Do you mean anything technical or just the “just one design or you’ll pay panelizing fee” thing?
I’m going cheap here trying the 10*10 offerings from Chinese fab houses. I’m scripting panels but doing it without any panelizing things on the board (they reject that), but gonna do straight line cuts myself with this monster:
I’m just scripting an outline around the whole thing once setup:
Yes, there might be a “panelizing” charge, but cheap fabs I use are fairly lenient. Although I find the cost is so cheap it’s easier to have them cut the boards than do it myself, FR4 is quite abrasive on saw blades. I haven’t tried the monster guillotine though 
If you give them a single outline, that should be ok. I put cut lines for my use on silk screen.
Presumably in the schematic there are two circuits. Try changing the power symbols so each circuit has their own power symbols. Create a netlist from that and import it to the boards. That should separate the power nets.
(I haven’t experimented with the new Eagle imports, so I don’t know how useable (or not) the imported schematics are…)
After that he will also need to update the zones with the new netname for at least one board.
Currently, I think there is no simple trick, but there may be coming a means to tag DRC reports as ‘manually checked’
In cases like this, usually I just write on the panel a DRC count, eg DRC unCon : 3 (GND,-12V,+12V), and you could even add lines on a comments layer under the unrouted that are considered ok.
Or (as above) you can route them on unused layers, but that needs FAB care to avoid confusing suppliers
oooone more thing that I don’t know if it’s the import or just weird Eagle data, but there are have been these graphical things interpreted as components with no footprints:
So have to go from:
to
or
Seems like an oversight to me. In kicad one can mark symbols as “virtual” by adding a “#” in front of the reference text. (This is done when you set the “this is a power symbol” flag in the symbol properties dialog.)
So maybe try to open a bug report requesting the ‘#’ be added such that the netlist generation does ignore these symbols.
We use this feature for graphical symbols in the official lib.
