Ok – I have an Eagle design (may death come to to Autodesk, but I will get off my grand-stand now) that I am trying to import to KiCad 7. It -almost- works. I have followed the youtube video of contextual electronics, (although is import is for version 6)
The schematic seems to import OK, but the issue is with the board side of the import. I am KiCad 7.0 Import non KiCad project wizard. When I tell it to “Auto Match Layers” several important layers seem to have no sensible match. For example, Pads, Vias, and Drills all do not have a sensible Kicad layer to map to. This seems wrong to me. I am probably doing something dumb. But, I let it go…
I eventually end up with my PC board in the pcb editor, but my hand placed “Gnd” vias are missing. (This is a power supply board with some areas that are hand-stitched vias) Ok, I get it , its an import, so I willing to deal with that.
Then comes the next issue, when I try and cross probe from the schematic to the board, very few of the nets show up as cross-probe-able. For example, +5v seems to cross probe just fine, but SCL and SDA (I2c stuff) nets are not showing up in the cross probe to the copper layer.
Again, I am likely doing something very dumb, like maybe a minimum grid or something, so please help me become less stupid
I think the only thing you’re doing that might be considered “dumb” is assuming KiCad works the same way as Eagle. That’s a common mistake when switching from one product to another.
Unlike Eagle, KiCad doesn’t have separate layers for pads or drills; instead, these are components of footprints. Vias are usually added as part of routing, though you can add free-standing vias for plane stitching using the dedicated PCB editor tool.
If you really want to see what is a pad vs a track, you can hide/show or change the transparency of these objects on the Appearance → Objects tab.
That’s odd. I have an Eagle project for an RF board I built that included hand-placed via stitching to a ground plane. I just tried importing the Eagle project into Kicad v7 as an experiment and these all came across in the import. Maybe your missing vias weren’t identified as connecting to GND in Eagle?
That’s not to say the resulting KiCad layout was perfect: there are some anomalies. The most obvious may stem from improper mapping of an Eagle keep-out zone in a footprint provided by a vendor; I haven’t looked into it as I only did it as an experiment. But all the essentials are there, and it wouldn’t take a lot of work to clean up.
Comparing the behavior of an imported Eagle project and a native KiCad project, I agree that this seems to be a problem. I suggest you file a bug report on the KiCad Eagle importer.
I’ve done some more investigation into this problem with the Eagle importer. The problem appears to stem from a significant difference between Eagle and KiCad schematics.
KiCad schematics are hierarchical. If you want to break a schematic into multiple sheets, the sub-sheets appear as symbols in a higher level schematic such as the root sheet. Nets local to a sheet, whether unnamed or named with a local label, are not visible in other sheets. Connections between nets on different sheets can only be achieved using either hierarchical connections or global labels.
Eagle schematics have no concept of hierarchy. Multiple sheets are merely a convenience for the user. Every net has a name, either generated (N$n) or user-defined, and these net names are common across all sheets.
When importing an Eagle schematic, the importer has to map the Eagle flat net namespace onto the KiCad hierarchical net namespace. It appears to do this by mapping inter-sheet connection names to global labels and dropping all intra-sheet connection names, whether generated or user-defined.
When importing an Eagle board, the resulting tracks and airwires in the KiCad board are named using the Eagle net names. This is inconsistent with the behavior of the schematic importer. Since cross-probing between schematic and board in KiCad requires consistent net names, I believe this is why cross-probing only works with inter-sheet connections: those that the importer gave global labels.
A “simple” solution would be to change the Eagle importer to create KiCad global labels for all Eagle nets. This would be the most consistent with Eagle behavior, and solve the cross-probing issue. However, it would also clutter the KiCad schematics with global label tags on every connection. A slightly more complex solution would be to recognize the format of Eagle generated net names (N$n) and ignore them when generating the KiCad schematic and board, while preserving the user-assigned net names with KiCad global labels.
I’ve created Issue #14620 to track the net naming inconsistency.
