I’ve just done my first symbol edit in KiCAD - about the smallest and most trivial possible -
the 555 - because I found the existing pin organization to be… unconventional. So I open
up the editor and find that it’s rather nice - the “which side do you want the pin on and do you need an inverting circle” dialogue is quite a good touch, when my old system tends to
be a little more laborious (the lines and circles aren’t part of the pin and have to be
manipulated separately). So I’m thinking “well done on that front, guys”.
Then I exit the editor, back to my schematic, and find that my connections did not stay
with the pins I attached them to! Instead, they’re connected to the new pins that are
now located where the old pins were. That is, where I’d put the usual capacitor from
pin 5 to ground, that cap is now connected to whichever pin happens to now be where
pin 5 previously was.
Before I ask “Is there anyone here who’s even remotely taking the netlist seriously?”,
is there some step I missed, like “do this to update the netlist to reflect your modified
Yes, the netlist is serious and important.
No, you did not miss anything (or not much at least).
In KiCad wires are not really attached to pins. KiCad relies on the coordinates of wires and pins to match to create the netlist.
When you edit the symbol and then put it back in the schematic, KiCad does not make any attempt to move wires. I’ve seen programs that do this, and it’s horrible. It resulted in the program creating a big birdnest of the wiring and I ended up deleting all wires and redrawing them.
Instead, KiCad just leaves it to you.
typically you change the symbol before you attach te wiring, and then it’s not a problem at all. If you change a symbol after wires have been placed in the schematic, you are aware of the changes you made and how to update the schematic.
Wrong and WRONG. The correct behaviour is to maintain connectivity to the pin that
the user connected it to - PERIOD. I’m coming from a system that does this, and it’s the
only reasonable approach. Whether it’s an 8-pin DIP or a PQ208 or a BGA1156, if I
choose to modify a symbol the system MUST maintain connectivity to the pin. Obviously
if it’s a 555 and the connections get scrambled it’s going to be easy to spot and correct,
but if you’re working with a device with hundreds of - or a thousand - pins, do you really
think it’s proper to make the user go back and sort out all those screwed up connections
manually? At that point, might as well not be using CAD at all. You’ve “seen programs
that do this, and it’s horrible”? I’ve lived with programs that do this, and without it I
could never have put those designs into production. Do the connections to the pins
get ratsnested after an edit? Of course, and so what? It’s a trivial task to then reroute
them, especially when compared to having to then recheck all of your lines (potentially hundreds of them) for valid connectivity.
Seriously, folks. This is deal-stopper stuff. I decided to give V6 a go because a trusted
friend said that it signaled KiCAD graduating into the realm of professional tools. Now
I’ve got to go back to him and say “Are you serious? All you have to do is move a
couple of pins around on a symbol to make your schematic make a little more sense,
and the system trashes your design.”
If what you say is true, and that when you attach a wire to a pin you’re not really
attaching a wire to a pin, but suspending them at the same coincidental location so
that something later can actually decide that that coincidence has meaning, I can’t
believe nobody has ever flagged it as a fundamental design flaw.
Eh what you describe is completely normal not just for KiCad but in EAGLE and OrCad from my own professional use. Schematic connections are graphical. You aren’t drawing a net, you are drawing a wire and applying a net label to it or letting it autogenerate a net name. The netlist is created based on the drawing but your drawing isn’t the netlist. Multiple wires can share a net name, heck you can branch multiple wires awkwardly off one pin.
You can create very large messes including shorts galore if the wire chased the pin automatically that’ll be even worse to fix.
But hey, it sounds like KiCad is not the tool for you. There’s a reason why there are multiple competing CAD programs, all implementing workflows and interfaces differently and users get to pick what fits their needs.
Out of curiosity, I made a small schematic.
I then updated the PCB from the schematic, making a net list.
I then modified a pin on the IC on the schematic.
I then updated the schematic from the PCB.
This is the result:
All the little ducks MUST be in a row before wires are laid.
Pins must have the right length and the right distance between to accept other symbols when needed so no bends in the wires whenever possible.
Symbols must be on the correct grid lines, with the right aesthetic appearance, nicely balanced on the page before wires laid.
And if the schematic looks unbalanced after the wires are laid?
Well, I just move everything around a bit, but generally don’t need to move pins on ICs.
Well I can understand the urge. Sometimes the grouping of pins on symbols is not as I would like, and no single arrangement will suit all designs. But I draw the line at making such modifications. I put up with a less than ideal arrangement so that I don’t have to save another symbol, even if it’s inside the project rather than my symbol library.
Your misunderstanding of what EDA is about - and of schematic capture - is profound.
Drawing a schematic isn’t about drawing a schematic. It’s about creating a netlist. The
rest of the design flow could give a toss what the drawing looks like, and you can draw
pages of (humanly) incomprehensible crap and still come up with a valid design. So the
cosmetic appearance of a schematic only matters to the humans looking at it.
If you understand that, you’ll grasp that the primacy of the netlist is absolute, and that
when the designer attaches a wire to a pin, that is the design and it must be regarded
Don’t talk to me about what what OrCAD (a schematic tool that sucked from Day One
and wasn’t even part of a suite, so they didn’t have to give a rat’s what happened to the
data that resulted from it) or Eagle does. If they or anyone else don’t maintain netlist
integrity then they’re trash too.
As for “creating very large messes”, you’ve obviously never benefited from mature,
powerful, and properly designed EDA tools. Nobody creates the perfect symbol on the
first try, and if you do, you still find out later that it’s wrong. Schematics evolve as the
drawing is laid down, and as they evolve you see where things can be moved and
modified to improve the drawing’s readability and logical flow. And that in turn requires
the ongoing ability to revise the symbols without the penalty of destroying valid
So - if you’re using good software - the notion that “you can create very large messes
including shorts galore if the wire chased the pin automatically that’ll be even worse to
fix” is pure twaddle, because the schematic capture KNOWS THAT THE NETLIST IS
THE ABSOLUTE TRUTH and treats the rubberbanded lines over top of other lines or
pins or anything else that it hasn’t been explicitly connected to by the user as incidental
noise that only affects the human readability of schematic, and simply flags them with
warnings. Then you go in and straighten and reroute the lines (manually or otherwise)
and all’s well again - and even if you don’t, it doesn’t trash your design.
And none of this has to do with competing notions of UI or workflow or any such foolish
distraction. If your schematic entry doesn’t allow you to create, and then enforce, a
valid netlist, you do not have a trustworthy, useful tool. You have child’s play.
Hence my question about when the system considers itself in possession of a valid
netlist, if in fact it ever does, because that enforcement has to take place in both
forward and back annotation. Without knowing (or, really, having any interest in the
software’s internals, so don’t waste your time suggesting I crack open the source and
get at 'er) at what point in the flow that happens, I can’t speculate on whether this
staggering fundamental error in design can be corrected within the schematic capture
module, or whether it pervades the entire package. If the former, clear heads need to
prevail and get serious about the netlist rather than treating it as some kind of
afterthought. If the latter, it might be too late to turn this into a grownup system without
a nose-to-tail rototilling.
I’m fence sitting, because I’d like the ability of being able to use both methods, depending on the task.
Occasionally, after a change in the symbol, I’ve asked: now which wire goes to which pin?
As I demonstrated above, in Kicad you can use the nets, with effort, BUT, I don’t like this statement:
The end purpose of the schematic is for humans to read, is it not?