It might have been in the year 1987 when for the first time I tested Electronics CAD software. In that time it was named “EEDesigner” and it was made for DOS, as I think Windows was not yet sophisticated/developed enough to run stuff like that. This software had something called “save wirelist/netlist” and “load wirelist/netlist” and also "front- and back annotation” (or similar) which worked pretty well as we had no other choices. Now, 34 years later the “netlist/annotation” thing seem to still remain in many of the “modern” CAD software suits, which in a bit surprises me. It seems like Cadsoft/later Autodesk Eagle is the one and only not having this, so my question here and now is: do the KiCad developer team have any plans to get rid of this somehow, to get it possible to just ”work” between schematics and PCB/get it automatic updated like smooth dance instead of this endless “updating” between them 2 things – to make it all work like a more simple “unit”? If not, please explain why, preferable so non programmers can understand it. Thanks!
First, external netlist isn’t needed in KiCad. Data exchange happens inside the running program when you use Tools -> Update PCB from Schematic.
But why not automatic? Some users would like that, and I don’t see a reason why this shouldn’t be an option. See https://gitlab.com/kicad/code/kicad/-/issues/4469 for a discussion (and add a thumb up so that the developers see you need the feature).
This may tell something about historical baggage of the applications developed for decades, but it may also tell something about hobbyist/professional division.
“First, external netlist isn’t needed in KiCad. Data exchange happens inside the running program when you use Tools -> Update PCB from Schematic.”
Thanks. Yea I know and that “Tools -> Update PCB from Schematic.” should not be needed. It just messes it all up one step furter. Have you tested Eagle, any version since way back in time?
You mentioned external netlist (in other programs) and it’s somewhat common misunderstanding that KiCad would still need an external netlist, therefore I mentioned it. The newer internal update process is only half that much work for the end user, one action instead of save + load.
Well, you don’t have to convince me. I don’t see your vote in the gitlab issue.
One more thumbs up pressed now in the GitLab vote part.
@TheSwede, I share your thoughts as I came from 25 years of eagle.
The ways eagle and KiCad aproach the same targed is quite differend. I took me a couple of hours (weeks to be honest) to understand and finally accept KiCads philosophy, especially regarding the consistency thing.
Today I compare both the systems like that:
Eagle is a railroad. Jump the train, after a while is takes you to your destination savely, as you dont get lost.
Kicad is Motocross. Jump the bike, kickstart, enjoy your ride through the woods and puddles, but mind the pottholes and keep an eye on the sun and stars to navigate.
You still can ride savely following marked paths in the beginning, as I still do, but I see there is more freedom and speed avaliable for future use.
I restrict this poem to the use of eagle 5.11, as this is my latest version, but I guess eagles philosophy has not changed much since then.
Yes marera, agreed, today I ran this Motocross ride (link below) – it can be dangerous, easy to crash straight into a tree – especially on a more busy PCB…
@TheSwede, I fully agree. Giving one to much freedom can leed to anarchy, and anarchy only works if everyone follows the rules!
Some would answer to you „YOU did wrong, dont blame KiCad.“
I am member of the less blessed minority, I would like KiCad to take more care of me sometimes. Your video is a good example.
KiCad developes, and who knowes? I think in a while I‘ll be experienced enoug to make suggestions to the developers, as the need the feedback and input from users.
I copy one whole project (schematic + PCB) to new name and then change something - for example I delete all elements of 13.56MHz RFID and replace it with all elements for 125kHz RFID.
I suppose that updating PCB after each step of my work can lead to bigger mess at PCB then updating it when I know that I have changed everything I wanted - so when I tell program “Now we are ready to update.”
I have never worked with program that does it automatically.
Let me know how it is solved in such programs to avoid that expected by me bigger mess.
Eagle transfers every single change you do in the schematic imediatly to the pcb, you cant inhibit that, nor do you have to care about that.
In PCB there is no way to change anything that affects the schematic. That avoids the mess you are afraid of. Schematic always represents the PCB and vice versa, always, every single moment in time.
In my first attempts Kicad gave me the freedom to make a mess…
That is what some former eagle users run into.
KiCad has been designed from the beginning with the manual update model in mind. Many things work differently than in Eagle, therefore it can’t be implemented just like that. All use cases and situations must be thought through before even deciding if this is realistically possible, considering the available developer resources and competing feature needs. When I’m now thinking about the details, this is starting to feel a bigger task than what I first imagined.
This is not meant to be discouragement, and it would be great to have that feature for those who feel they need it, but realistically speaking there are already enough planned features for even v7 to take all the resources. Especially because Eagle seems to be the only popular EDA which has that feature, or is it? The vision of the KiCad project is to compete with the big ones, and professional corporate needs drive the development more than beginning hobbyists (for whom, I suppose, this feature is more interesting). If some feature makes it more difficult to develop KiCad towards that direction the feature isn’t likely to be accepted.
But I don’t really know how difficult this would be to implement and if it would require changing the current architecture.
Oh, I did not mean the realtime pcb update to be developed, but e.g. A hint if you connect two different nets, with a choise for the resulting name. That doesnt affect the philosophy.
And you think it is good?
You see that changing microcontroller pin assignment would help when you are working with PCB and not schematic.
You see that rearranging NAND gates in 7400 will help route their tracks when you are working with PCB and not schematic.
Why not allow to do it at PCB and then update schematic to it. I think in KiCad it is planned.
Having such possibility is in my opinion worth more than to not need to click Update PCB from Schematic.
I was not writing about a mess generated by changes made by me at PCB, but only by changes made at schematic.
For example I remember at least two times when I decided to remove some part of schematic having a plan to replace it with something different, but when drawing the new solution I got some information that made me changing my mind and getting back to previous solution.
The mess I was thinking is that I suppose that in such case when I deleted elements at schematic and program automatically deleted them at PCB and than when I add them back the program will not know where to place and how to connect them as they were before. That problem not exists if you update PCB when you are sure that your schematic is as you want it.
Sorry for a possibly stupid question (I haven’t used Eagle in a while…).
What happens in Eagle if I cut a large part of a schematic in one hierarchical sheet and then paste it in another place in the hierarchy? Will my PCB stay identical after this change?
In reply to all:
I wanted to point out why former eagle users sometimes do have difficulties in understanding „the KiCad way“. I do not judge one to be better.
Further this thread is not intended to become an eagle tutorial. And even if it would, my eagle knowledge is limited to the 12yo version 5.11.
I just assume eagles philosophy has not changed meanwhile.
Just this much: dispite the different aproach, eagle is capable to give professional results, it is easy to use, and it has features I still miss in KiCad.
I looked at some Eagle files, and if I’m correct, Eagle uses refdes as unique ID. That’s of course a far reaching architectural decision, along with auto-update, tight coupling and disallowing certain things in the layout. For example it seems to auto-annotate when adding or copying a part and if I’m right, it must do that always to prevent duplicates and unannotated items. All sheets seem to be in the same sch file. Moving items between sheets isn’t a problem for auto-update.
BTW, Eagle doesn’t even have a “Cut” edit command.
“What happens in Eagle if I cut a large part of a schematic in one hierarchical sheet and then paste it in another place in the hierarchy? Will my PCB stay identical after this change?”
Instead of “cut” in Eagle let’s try it with “move”…
For me the manual updating from schematic to layout is must.
Though I try to have a finished schematic before starting the layout, I can’t remember a single project without any modification of the schematic at some point after the layout is quite advanced.
In my opinion automatic update should not be even an option.
Don’t understand me wrong. I pretty much have the same opinion. I do like having the ease of mind over the control that my PCB does not get damaged by just changing something on the schematic. I have also never used eagle or another program that tries to always keep schematic and PCB in sync. So in the end it boils down to having an opinion over a workflow I never used myself.
I do admit though, that if the schematic and the PCB are always kept synchronized with each other, then a bunch of causes for errors simply disappear. For example, I’ve always put the mounting holes in the schematic, just to make sure I can not delete them accidentally when the PCB is being updated.
I am also afraid that if the update is done automatically, “some things” will break and some common workflows in KiCad would not be possible anymore, but I’m not sure what those are, and if that could be fixed.
Ok, but what does that mean?
If you change the schematic, you will also have to modify the PCB, no matter how advanced your PCB is.
A part of my workflow is that I always do an Update PCB from Schematic [F8] and a DRC just before making gerbers, just to make sure that schematic and PCB are in sync before sending out Gerber files.
So I’m curious, what sort of troubles would there be? And how difficult would it be to fix them?
At the moment the “Schematic symbol” is the reference item for a “Part” in KiCad. A more abstract and logical choice would be to just make the UUID itself the reference. The RefDes would then just be a text string that makes it easier for humans to identify a part.
One problem is that schematic symbols do not always have footprints. That could be fixed for KiCad, by storing (X, Y) and rotation of the footprint in the “Part” itself. If you delete the footprint from the part, it’s not visible on the PCB. If you add a footprint, it reappears on it’s previous location.
Another problem with the current workflow is if you use [Ctrl + X] to cut a section from a schematic and then use Paste Special (new in KiCad-nightly V5.99) to paste it in another hierarchical sheet. But the solution is also simple. The PCB footprins also get cut, and when the schematic part is pasted into the hierarchical sheet, the footprints just re-appear on the PCB again.
I mean when I make changes in the schematic they are not always adding things, but sometimes some kind of going back and forth. Sometimes I delete a cap and after some rethinking I change my mind and I want that cap back (I’m sure it is not the best example).
Maybe it is only the way I’m used to, but I would like it to be like it is as other people want features of their old ECAD implemented in KiCad.
About mounting holes or footprints embedded in the symbol, I have worked with both solutions. Depending on the company I work for, I go one way or the other. Even with a footprint with only edge-cuts perimeter and mounting holes and outer connectors representing the whole pcb.