What I plan to do, is to start with a KiCad net list and make a schematic.
(For the moment, assume that I can expect at best an ugly but correct schematic… that is not an issue).
Now before you ask me where the egg came from, without the chicken laying it, let me explain the grand scheme I’m dreaming up…
I am thinking of using SkIDL to generate the net list and ‘import’ that it into KiCad. (By using hierarchical design, I hope to get hierarchically organized sheets and not-so-ugly, that is, readable, schematics).
But I am stuck with this question – how do I import a KiCad net-list into KiCad EEschema? Hacky methods are OK!
That seems a little strange.
If you start with text sources, why do you need a shambolic Schematic ?
I can see merit in a NET export from pcbnew, in order to take snapshots and verify you have correct versions, but that’s an ascii compare problem. I did a script that exports a Kicad netlist from PCB.
That said, PADS Logic did have a somewhat undocumented NET import feature, that was useful for small ECO changes. (additions especially)
It added new/unexpected parts onto a new sheet, with some arbitrary XY step to avoid total scramble, and then applied net-name connections to every pin. Not pretty, but functional, and editable.
Their XY step anti-collide was good enough, we used it to import whole libraries, as loads-ok proofs.
Schematics are painful to draw but useful as documentation. With a fairly readable schematic, someone else can understand and troubleshoot a proto board. When you work for a client, a schematic is one of the contracted deliverables. Also, a technically correct but badly laid-out schematic can be easily spruced up by a drafts-person (think interns! )
Assuming so, how do you then propose to import that schematic file into EEschema? EEschema (ver 5.0.x that I checked) is able to import only one type of schematic and that is Eagle XML format. KiCad’s own schematic format is not supported for import. (Think of that in the context of hierarchical sheets as well).
Just found out that “Append schematic sheet” to an existing sheet is possible.
(BTW, if you open a .sch file using eeSchema stand-alone (outside of KiCad suite), it tries to also open the project file (.pro). I’m not sure why but this behaviour is in apparent contradiction to the idea of a stand-alone eeSchema).
It seems there is no existing plugin or code that addresses the problem of getting a correct but possibly ugly schematic out of a KiCad netlist.
No, which is why I said that you (or someone!) would need to write some code to do it.
I have code to read netlists and write schematics, but getting it to generate even a dumb schematic is not trivial. For example, you also to need to read in the symbols used, find the location of the pins, allowing for the symbol may have been rotated or mirrored, and then place labels at each of the pins.
Trying to auto-arrange the components into a nice layout and connect them with wires would be an AI level thing. Doxygen generates diagrams from code, so may be that might be a better place to start from.
Just for fun, I quickly hacked some code together. Original schematic:
After converting to netlist then back to schematic:
Yup, plus you need to track placed symbols+labels, and avoid dropping other symbols on top of them.
I wonder how far away is Python Scripting inside EESCHEMA ?
A script that can operate inside EESCHEMA could more easily place a part, then just query the pin XY for the label.
That’s quite impressive. That’s looking largely equal to what PADS Logic achieves.
How does it cope with more complex symbols ?
I tried running the conversion on a small project, the converter doesn’t handle multi-unit parts. I can’t really see how it would be useful, I wouldn’t give the task of clean up to anyone, not even to an intern!
That actually looks quite good to me
(not pretty, sure, but the actual information is correct)
We found the PADS Logic NET import good, as it was part of their reverse ECO flow.
In their case, any parts /pin-nets not in the original SCHs add to a new sheet, and they look a lot like this. Usually, the changes are not huge, things like worms/beads/pinswaps.
Users have a choice to leave them there or copy/move to a better place.
The important detail is this SCH’s NETLIST & BOMLIST will check 100% against the PCB.
Can your code easily check this against an existing pin-list, and add only items not already in the list ?
That flow would allow late/manual changes to a PCB-side of flow for things like extra decoupling caps, or series R’s / ferrite beads /cuts/worms etc.
Catching a split net might be trickier ? - maybe emit warnings on conflicts like R3.1 is in both, but has different net names ?
This script may also allow better PCB BOM handling, for NON-SCH flows ?
One issue with pcbnew is the bom generate is limited, and not as comprehensive as the SCH-side BOM.
I suppose the internal net names are discernible (being some other type than Label/HLabel/GLabel, or by matching of name to regex for NET-net-id ). It got me thinking that, for a start, segments of unlabelled nets could be joined with straight lines instead of being labelled on both sides with those internal names. But I also realize that it would soon lead to a spaghetti diagram. On the other hand, clearing up that spaghetti (manual or AI) would lead to a better looking diagram (of course, easier said than done!).
but useful as documentation. With a fairly readable schematic, someone else can understand and troubleshoot a proto board. When you work for a client, a schematic is one of the contracted deliverables. Also, a technically correct but badly laid-out schematic can be easily spruced up by a drafts-person (think interns! 
)
