Tips on working with imported Eagle boards…?

Layout
1

I’ve been trying to use the Eagle import in Kicad 5 nightlys. It seems to be working fine at first. I can actually import the boards and after some minor fixes, typically doing some connections where zone margins have missed some ground connections I can even make it pass DRC.

But then if I need to do some modifications, going back to schematic and change some footprints, hell breaks loose. I have a very concrete example:

I’m trying to take this open source board:

https://forum.gmsn.co.uk/t/about-the-pure-vcf/21 (Sorry, I actually linked the wrong project before)

and just exchange a dual 3906 to two 3906 in sot-23 because I don’t have the dual package in my drawers.

  • So I’ve imported the board to Kicad
  • Pulled some connections and made it pass DRC.

Looks something like this:

652×1610 71.4 KB

  • Then I just go back to the schematic and exchange that dual PNP to two 2N3906:
    From

1344×858 60.2 KB

to

1078×690 37.1 KB

  • Then I go into CvPcb to assign footprints. After annotation of the new Q’s, I get this question:

1000×544 119 KB

I’ve only answered Yes so far, but might actually try “No” next time. (No, that really cleared them)

  • I assign the new 3906’s footprints but leave everything else:

1264×1626 320 KB

  • Then I generate netlist.
  • Read netlist in pcbnew. If I do a test run I get:

No duplicate.
Missing:
COF_CV1 (S_JACK)
CV_AT1 (100K)
COF1 (100K)
IN1POT2 (100K)
Q1 (100k)
2POLE1 (S_JACK)
4POLE1 (S_JACK)
Q3 (2N3906)
Q2 (2N3906)
Not in Netlist:
@HOLE0 () @ 140.251 mm, 61.484 mm
@HOLE1 () @ 140.251 mm, 81.484 mm
@HOLE2 () @ 140.251 mm, 101.484 mm
@HOLE3 () @ 140.251 mm, 121.484 mm
@HOLE4 () @ 140.251 mm, 141.484 mm
2POLE (S_JACK) @ 140.251 mm, 121.484 mm
4POLE (S_JACK) @ 140.251 mm, 141.484 mm
COF (100K) @ 156.751 mm, 121.484 mm
COF_CV (S_JACK) @ 140.251 mm, 101.484 mm
CV_AT (100K) @ 156.751 mm, 101.484 mm
IN1POT (100K) @ 156.751 mm, 61.484 mm
Q (100k) @ 156.751 mm, 141.484 mm
T1 (TRANS_PAIR_PNP) @ 150.406 mm, 74.737 mm
U$1 () @ 140.087 mm, 72.991 mm
U$2 () @ 139.690 mm, 56.957 mm

If I do a dry-run I get:

Info: Reading netlist file “/Users/viktor/Dropbox/electronics/kicad/eagle/gmsn-pure-vcf-2.4/eagle/Pure_VCF_SMD_V2_4.net”.
Info: Using references to match components and footprints.
Info: Checking netlist symbol footprint “2POLE1:/206152FC5DCA2EEB:Pure_VCF_SMD_V2_4:S_JACK”.
Adding new symbol “2POLE1:/206152FC5DCA2EEB” footprint “Pure_VCF_SMD_V2_4:S_JACK”.
Info: Checking netlist symbol footprint “4POLE1:/C7D4C067AA23EF36:Pure_VCF_SMD_V2_4:S_JACK”.
Adding new symbol “4POLE1:/C7D4C067AA23EF36” footprint “Pure_VCF_SMD_V2_4:S_JACK”.
Info: Checking netlist symbol footprint “C1:/A03C925EB189466A:Pure_VCF_SMD_V2_4:153CLV-0505”.
Replacing symbol “C1:” footprint “153CLV-0505” with “Pure_VCF_SMD_V2_4:153CLV-0505”.
Info: Changing component path “C1:” to “/A03C925EB189466A”.

…

Info: Checking netlist symbol footprint “TR2:/D1499554A7E1DB2A:Pure_VCF_SMD_V2_4:TRIMMER_TH3”.
Replacing symbol “TR2:” footprint “TRIMMER_TH3” with “Pure_VCF_SMD_V2_4:TRIMMER_TH3”.
Info: Changing component path “TR2:” to “/D1499554A7E1DB2A”.
Info: Checking netlist symbol footprint “U$3:/F3C0F9832AECCF64:Pure_VCF_SMD_V2_4:SOIC-16_BLANK”.
Replacing symbol “U$3:” footprint “SOIC-16_BLANK” with “Pure_VCF_SMD_V2_4:SOIC-16_BLANK”.
Info: Changing component path “U$3:” to “/F3C0F9832AECCF64”.
Changing footprint “U$3:” pad “15” net name from “” to “Net-(U$3-Pad15)”.
Changing footprint “U$3:” pad “11” net name from “+12V” to “Net-(U$3-Pad11)”.
Changing footprint “U$3:” pad “9” net name from “N$16” to “Net-(U$3-Pad9)”.
Changing footprint “U$3:” pad “8” net name from “N$28” to “Net-(U$3-Pad8)”.
Changing footprint “U$3:” pad “6” net name from “-12V” to “Net-(U$3-Pad6)”.
Changing footprint “U$3:” pad “2” net name from “” to “Net-(U$3-Pad2)”.
Info: Checking netlist symbol footprint “U$4:/C4F885289A709B56:Pure_VCF_SMD_V2_4:SOIC-16_BLANK”.
Replacing symbol “U$4:” footprint “SOIC-16_BLANK” with “Pure_VCF_SMD_V2_4:SOIC-16_BLANK”.
Info: Changing component path “U$4:” to “/C4F885289A709B56”.
Changing footprint “U$4:” pad “15” net name from “” to “Net-(U$4-Pad15)”.
Changing footprint “U$4:” pad “8” net name from “N$44” to “Net-(U$4-Pad8)”.
Changing footprint “U$4:” pad “2” net name from “” to “Net-(U$4-Pad2)”.

If I do the netlist read with this setup:

1240×1090 402 KB

All pots and jacks loose their positions:

790×1170 51.5 KB

How can I import an Eagle PCB and make small changes to it? I get similar issues with all boards I’ve tried. This one was probably the one with the least problems.

2

You might want to report this over on the bugtracker.

1 Like
3

From my experience of converting Eagle files to KiCad, I expect the KiCad import to be quite buggy. There are a lot of differences between Eagle and KiCad which require careful handling.

For example, in KiCad references must end with a digit (unless it is a unit of a part), but in Eagle you don’t need to. Unless KiCad renames these refs in both schematic and pcb, you get errors when you regenerate the net list.

That explains why parts such as “2POLE” get lost and renamed “2POLE1”. A workaround is to rename the part in pcb to match what it will be in schematic, before you import the netlist.

Netnames will change after netlist re-generation, mostly that doesn’t matter except where the netname has been used in zones or vias.

5 Likes
4

A few ideas:

  1. rename the .brd and .sch files to have the same basename. like PURE_VCO.sch and PURE_VCO.brd.

  2. You’ll want to run ERC first on the schematic.

In this case, you are running into trouble because Eagle supports references that have “/” in them and that don’t end in numbers.

KiCad is interpreting this as having not completed annotation.

Next, you will need to rename the associated footprints in the board file. I know… PITA. Since they don’t have timestamps and you are changing the names, to update in the board, you will need some matching reference name.

1 Like
5

Thx all! I’ll try all the tips. Will try to work on scripting that makes all the steps I need to take repeatable and report back if I find a solution that works.

What I still don’t understand is how this is supposed to work and the underlying idea of the import: After import it looks like this:

1790×490 106 KB

There is no .net file but pcbnew still has ratsnet and can run DRC so obviously there is an an internal representation of a net graph inside the pcbnew file, right? Wouldn’t it make reasonable sense that the schematic file and pcb file would be consistent at least so that a .net file generated from schema would be the same as the one already in the pcb? Seems broken by design otherwise, not just buggy.

My first approach will be to try and rename stuff wit scripting:

  • replace all “/” in references.
  • add parts in pcbnew so they end in 1’s just like eeschema will do on annotation so they will match and can keep their position/orientation.

You’ll want to run ERC first on the schematic.

This seems hard too. There are quite a lot of issues turning up:

Many seems related to the fact that whatever thing they’ve use in Eagle to just name nets turns into global labels that doesn’t have a matching pair. And other conflicts, power net stuff. To fix all that seems like too much work…

Maybe I should just give up on using eeschema to make any mods? Should I just try to work straight in pcbnew for these small kinds of changes? For some reason I didn’t think about that yesterday but here I really just want to remove one component and replace it with two other. Maybe get DRC working first, then do my small edit and be fine with it?

6

@hedefalk,

Thank you for posting your findings. I have some fixes for Eagle import that I am going to merge today, I will try them out with your files soon. To get the timestamps right you need to import a whole Eagle project in KiCad launcher. It is the import preferred way, as this way KiCad can compare schematics and board and apply more fixes.

1 Like
7

Ok, it looks like I might be able to fix the issues I have with simple renaming actually. If I’m restrictive when reading .net file it seems to only issues I have are with the references that doesn’t end in numbers. One extra bug here though:

All of them have appended 1’s except this one:

IN1POT -> IN1POT2

Just because there is a 1 in the name. That check should probably be to just look at numbers in the end of the reference instead? Makes it harder to script renaming with that bug… :slight_smile:

8

@orsonmmz Could you tell me what this entails exactly? Do I need more files than the .brd and .sch? I have little to no Eagle experience, do you mean they have something similar to a .pro file that I need to?

9

After selecting the source project file you are “asked” to provide a target directory for the new project. (See the demo at fosdem Wayne's FOSDEM Talk up now)

Yes the netfile is only needed during the import step. As the eagle importer directly reads the eagle file and not some netlist the later is unnecessary.

Yes. But importing stuff from a different software that does things quite differently is error prone. Missing only one difference in handling would be enough to screw up the import program.

Extraordinary claims need extraordinary evidence! I would guess something has been missed by the developer. He for sure did not screw it up on purpose. (By the way doing things on accident is the modern definition of a bug. Only originally has it been an actual bug in the circuit and therefore out of the control of the programmer)

I ask again that you report this on the bugtracker. Otherwise you have no right to complain at all!

1 Like
10

There’s several other invalid chars you might find in Eagle such as " \ : * ?

Adding “1” may be insufficient, because there may be already a part with that name. e.g. you might have R, R1, R2 in which case R must be renamed to R3. In general, you need to add a numeric suffix that creates a unique name.

I’m puzzled by that one, in KiCad units are named like U1A (depending on preferences), but I can’t see why it added “2”.

In Eagle, all labels are effectively global. To make a nice conversion to KiCad a smart algorithm is required, but also the same scheme must be applied to pcb and eeschema, so it’s necessary to process both files at the same time, importing them separately will not be able to do so. In Eagle there is no project file.

The way I handle renaming is to keep a map of original symbol vs renamed symbol, that map is then used to fix up the schematic and pcb.

You are right, KiCad has an internal netlist, the netlist is embedded in the pcb file so it’s not necessary to generate one during conversion.

11

I ask again that you report this on the bugtracker. Otherwise you have no right to complain at all!

Sorry if I sounded whining, I realized that “broken by design” part might have been a bit bad. Wasn’t intentional, I’m really grateful for this piece of software and I will continue to try to be a good citizen in oss.

However, I’m not sure I have anything specific enough to report to the bugtracker - especially considering I don’t understand how this is supposed to work, maybe except from that 2 instead of 1 thing. But maybe you can help here, putting a name on what’s wrong? Or is my description here of things not working for me considered good enough you think?

What I meant about that part that came out bad is that I really don’t understand how it would be maintainable and ever work well if there are two separate conversion functions, one for schema and one for pcb that aren’t worked out in unison if it’s going to support the typical workflow of KiCad where one goes from schema to pcb via netlist. I mean, if the naming restrictions are only enforced in eeschema but not in the conversion to pcbnew… But now I just realized that this can probably “just be a bug” since it was actually eeschema that enforced it once I did the annotation+footprint, and not the conversion to eeschema. What I had in mind was that if there where two separate conversions and only one of them did some renaming, making the KiCad workflow impossible, that I would consider conceptually wrong more than just a bug.

12

To get the timestamps right you need to import a whole Eagle project in KiCad launcher.

Ok, I think this is what I’ve been doing all along:

13

Hi @hedefalk

I worked on the schematic import code, along with @orsonmmz and Wayne.

To start off thanks for testing this feature out, its real users and their use cases which push stuff like this forward.
As @orsonmmz has mentioned there are some fixes coming soon, so don’t give up just yet. These mainly deal with matching the net names created from the imported schematic to the “global” net names found on the PCB after its been imported.

Your best experience will come from importing both the Eagle schematic and board in one go as a project, from the import project menu item in the Kicad launcher. The first dialog is used to select the file, and then another the destination for the kicad project. It best to keep the new project well away from the eagle files, so filenames don’t conflict.

By importing both files as a project, the timestamps between symbols and footprint are synced by importing the netlist from the schematic before any annotation checking is performed, which allows matching by the reference. This process is done automatically as since eeschema enforces the Kicad annotation style before exporting the netlist.

Also as of version 5, the process of eeschema -> export netlist toa file -> pcbnew -> import netlist from said file, has been mainly eliminated. The netlist is now passed between the eeschema and pcbnew internely, using the “Update PCB from Schematic” button.

.

1 Like
14

@rustyoz

Thx for this functionality! Definitely haven’t given up, I’m actually really impressed!

I just posted at the same time as you that I was using the project importer from KiCad launcher all along. I just recently upgraded from 4 to 5 so still experimenting with the new stuff.

But I did try the “Update PCB from Schematic” button with the same result. Really nice feature though! I’ve been cursing the going-through-netlist-file thing a few times because I’ve sometimes needed to do it up to a hundred times when iterating footprint selection. And changes directly in pcbnew would otherwise get overwritten if not going through eeschema, next time one had to do just that.

15

@hedefalk Could you post urls to the boards you have tried and had problems with? Would be very useful for testing.

16

@hedefalk

I have just pushed a number of Eagle importer fixes, so they should be available in the next nightly build (or revisions 2af51ef2 and later if you build KiCad yourself). I have imported the project you mentioned in the first post and I think everything has been imported correctly, I would be grateful for your feedback. I am also interested in other issues you faced while importing other Eagle projects.

1 Like
17

[quote=“hedefalk, post:5, topic:9816”]
There is no .net file but pcbnew still has ratsnet and can run DRC so obviously there is an an internal representation of a net graph inside the pcbnew file, right? [/quote]
Yes, if you open the pcbnew file in a text editor, you can see netnames in various places.

Yes, and that does seem to be the target, the mention of new builds sounds very promising.

It also appears that combined (same time) translate is required, in order to provide enough collective data to sync-names as expected. Viz

That’s a little restrictive, as users may not always have both SCH & PCB at one instant.
If SCH and PCB are not both available, would it make sense to ask for a seed value, so separate imports can match ?

The best way to improve this, is to exercise as many Eagle files as possible.
I wonder how ‘almost matching’ Eagle SCH/PCBs import ? It’s common for there to be some creep SCH/PCB.

18

Sure! The ones I’ve tried so far are these:

https://www.befaco.org/en/dual-atenuverter/
and now this one from OP:
https://forum.gmsn.co.uk/t/about-the-pure-vcf/21

I had more problems with the Befaco atenuverter than the gmsn vcf but I don’t have the details on top of my head now. But I will revisit soon.

I’m also going to try this one which I accidentally first linked instead of the vcf:
https://forum.gmsn.co.uk/t/about-the-pure-vco/22

Also going to try this one which I want to do more extensive changes to:
http://www.befaco.org/img/Modulos/Mixer/v2/mixer_2_2.zip

I’ll report back here, promise :slight_smile:

19

@orsonmmz That sounds awesome! I’ll give it a shot tomorrow or the day after. Thanks a lot!

20

@orsonmmz @rustyoz :heart: :heart:

Thank you sooo much! I’ve been busy for a couple of days, but just retried with latest nightlys and everything worked flawlessly! I could import just fine, went to exchange the schematic symbols, assigned footprints and just pressed update pcb from schematic and everything just worked perfectly. Awesome work!

1 Like