You know I would pay for Kicad if the paid option was for a useable interace.
I loaded up Circuitmaker and proceeded to try and enter the same circuit as I was trying to do previously. After struggling with the daft component selection system (Kicad does this way better) within a couple of minutes I had tens of components placed and wired up with nice intuitive right click mouse clicks a appropriate. What an out and out pleasurable experience. It is such a shame I now have to go back a trawl through Kicad's documentation to figure out how to use it.
I understand KiCAD might be similar to Eagle.
That's because the Kicad developers have a suggestion that goes along the lines of: "If there is a question about how to implement a feature, look at how the leading Maker favorite package does it, and do the opposite."
Quote from: meThat's because the Kicad developers have a suggestion that goes along the lines of: "If there is a question about how to implement a feature, look at how the leading Maker favorite package does it, and do the opposite."
Thing is, as I understood it, KiCad was once developed by a single guy who, if I'm not mistaken, was a teacher. Impressive work for a single developer but... the context says it all, pretty much. The key GUI features come from the original ideas, especially in the schematic editor which is the part that has been the least reworked of all. Anyone that had to deal with software written by university teachers will probably know where I'm heading to.
In this day and age we should not have to sit on the bog with a tablet reading software's instruction manuals
Quote from: meThat's because the Kicad developers have a suggestion that goes along the lines of: "If there is a question about how to implement a feature, look at how the leading Maker favorite package does it, and do the opposite."
Good one! :-DD
Thing is, as I understood it, KiCad was once developed by a single guy who, if I'm not mistaken, was a teacher. Impressive work for a single developer but... the context says it all, pretty much. The key GUI features come from the original ideas, especially in the schematic editor which is the part that has been the least reworked of all. Anyone that had to deal with software written by university teachers will probably know where I'm heading to.
I've taken a look at the source code, although not extensively, but changing the GUI substantially would probably require a complete rewrite.
To be fair, they have done a pretty decent job with the layout editor's overhaul.
In fact, I am almost willing to fork the entire project and find a couple of motivated people to work just on the GUI until even my mom can work with it.
I just don't really have a problem with the GUI, it's not going to win any awards but it doesn't have to, I've been designing PCBs in KiCad for close to a decade and it gets the job done. I tried out every EDA I could get my hands on and none of them had good UIs. If I can use it effectively I don't see why anyone else can't.For the very simple fact that not everyone is called james_s.
I just don't really have a problem with the GUI, it's not going to win any awards but it doesn't have to, I've been designing PCBs in KiCad for close to a decade and it gets the job done. I tried out every EDA I could get my hands on and none of them had good UIs. If I can use it effectively I don't see why anyone else can't.A bad rower blames the oar.
I've seen a surprising number of people not being able to do.
if you like to improve the GUI now is the time for it. The current 5.1.0 development is mainly about improving the overall user experience including finding and fixing inconsistencies. You will notice quite a bit of GUI changes compared to KiCad 5.0.0.I could live with the GUI if I could just get better automated handoff of the netlist and live updating of the netlist (with an option to disable or perhaps undo the last import) among the various tools. The GUI is a collection of related apps that feels unpolished, but I have to admit that it's functional. (As is the netlist handling to be honest, so I'm even contradicting myself a bit there perhaps...)
I do not share your feeling how KiCad prioritizes work. Working on the GUI is only one of many things, and there are many things to do.
Are you talking in general or about kicad? If kicad I can imagine why. But I don't want to put it in dirt, at the end, this is the only opensource tool that is not totally useless.
if you like to improve the GUI now is the time for it. The current 5.1.0 development is mainly about improving the overall user experience including finding and fixing inconsistencies. You will notice quite a bit of GUI changes compared to KiCad 5.0.0.I could live with the GUI if I could just get better automated handoff of the netlist and live updating of the netlist (with an option to disable or perhaps undo the last import) among the various tools.
I do not share your feeling how KiCad prioritizes work. Working on the GUI is only one of many things, and there are many things to do.
The GUI is a collection of related apps that feels unpolished, but I have to admit that it's functional. (As is the netlist handling to be honest, so I'm even contradicting myself a bit there perhaps...)
It's definitely functional and I can quite reliably get boards out of it. Any limitations with the tool are my own.same here.
It's not about the quirks.
It's about the inconsistencies and KiCad is full of them.
Getting a good consistent GUI for multiple platforms isn't difficult, there are plenty of (free) examples out there that prove it.
Many people have said it before and I repeat it again; it's all about priorities.
Personally I would like to add that it's also about attitude.
With that I mean really listen to the community, people who have been working as a PCB designer for many years.
The developers of KiCad don't really seem to care about it.
In fact, I am almost willing to fork the entire project and find a couple of motivated people to work just on the GUI until even my mom can work with it.
I recommend doing that. Then you will either a) create a much better tool or b) find out writing a much better tool is actually not that easy.
There are projects with similar goals you might want to help out, Horizon (https://github.com/carrotIndustries/horizon) LibrePCB (http://librepcb.org/). There have been several other people promising to make a "better KiCad" but I don't think they got anywhere.
The biggest flaw in the head of a developer/software programmer.It's not about the quirks.
It's about the inconsistencies and KiCad is full of them.
Getting a good consistent GUI for multiple platforms isn't difficult, there are plenty of (free) examples out there that prove it.
Many people have said it before and I repeat it again; it's all about priorities.
Personally I would like to add that it's also about attitude.
With that I mean really listen to the community, people who have been working as a PCB designer for many years.
The developers of KiCad don't really seem to care about it.
Have you filed bug reports and wish list items at the Kicad Launchpad? Do you follow the developers' email listserv so you can see clearly what they are working on and why they've prioritized things the way they do?
The assertion that they don't care is not true.
The biggest flaw in the head of a developer/software programmer.It's not about the quirks.
It's about the inconsistencies and KiCad is full of them.
Getting a good consistent GUI for multiple platforms isn't difficult, there are plenty of (free) examples out there that prove it.
Many people have said it before and I repeat it again; it's all about priorities.
Personally I would like to add that it's also about attitude.
With that I mean really listen to the community, people who have been working as a PCB designer for many years.
The developers of KiCad don't really seem to care about it.
Have you filed bug reports and wish list items at the Kicad Launchpad? Do you follow the developers' email listserv so you can see clearly what they are working on and why they've prioritized things the way they do?
The assertion that they don't care is not true.
This is not a bug, this is just fundamental understanding how to build up an intuitive piece of software.
Bit off topic, but I am completely convinced why most open source (not all!) totally fail in the long run because of this flaw.
Don't get me wrong, KiCad has a lot of potential, you can't deny that.
But the interface is made by and for programming geeks, NOT your every day, professional, I need a smooth interface that I can trust PCB user.
Most very good and professional PCB designers don't even know anything about programming or just the basics.
This kind of interface was an excuse 10 years ago maybe, but not anno 2018 anymore.
Yes I (and with me many others) have tried to talk to the developers and get involved.
But with an attitude that "we know it better, and we are not gonna do what all the big companies are doing, meh" you're not gonna make it.
Not to mention the overly sensitivity with every teeny bit of critique that is being given.
Everybody who feels the same and knows how to program, please contact me and I will have a look what we can do.
Don't know what I am talking about?The biggest flaw in the head of a developer/software programmer.It's not about the quirks.
It's about the inconsistencies and KiCad is full of them.
Getting a good consistent GUI for multiple platforms isn't difficult, there are plenty of (free) examples out there that prove it.
Many people have said it before and I repeat it again; it's all about priorities.
Personally I would like to add that it's also about attitude.
With that I mean really listen to the community, people who have been working as a PCB designer for many years.
The developers of KiCad don't really seem to care about it.
Have you filed bug reports and wish list items at the Kicad Launchpad? Do you follow the developers' email listserv so you can see clearly what they are working on and why they've prioritized things the way they do?
The assertion that they don't care is not true.
This is not a bug, this is just fundamental understanding how to build up an intuitive piece of software.
Bit off topic, but I am completely convinced why most open source (not all!) totally fail in the long run because of this flaw.
Don't get me wrong, KiCad has a lot of potential, you can't deny that.
But the interface is made by and for programming geeks, NOT your every day, professional, I need a smooth interface that I can trust PCB user.
Most very good and professional PCB designers don't even know anything about programming or just the basics.
This kind of interface was an excuse 10 years ago maybe, but not anno 2018 anymore.
Yes I (and with me many others) have tried to talk to the developers and get involved.
But with an attitude that "we know it better, and we are not gonna do what all the big companies are doing, meh" you're not gonna make it.
Not to mention the overly sensitivity with every teeny bit of critique that is being given.
Everybody who feels the same and knows how to program, please contact me and I will have a look what we can do.
Do you really think that the Kicad developers aren't also PCB designers? See, that's why I said you should actually join the developers' listserv to see what is actually going on and see who is actually doing the development. Because you don't know what you're talking about.
You say you've "tried to talk to the developers." Where?
Basically their answer is; wait until version 6 and we will see it from there.
No????Basically their answer is; wait until version 6 and we will see it from there.
So basically you're complaining they're not going to throw out their existing development plan and progress to do things your way immediately?
Frankly I'd be annoyed if the UI changed significantly at this point because I'd have to spend time re-learning how to do things, time that I could instead spend making more boards.Would it be so bad to fix the fact that you hit "c" to duplicate something in the schematic editor, but Command-D to duplicate something in the PCB layout tool or footprint editor, but it's drag to select and then right mouse to duplicate to duplicate something in the parts library editor (or that you can drag to select and then copy block and when you immediately go to paste the block, you get an error message "Warning: No block to paste")?
And if they focused on the UI at the expense of everything else, they'd throw out a different section of the market. There are other tools out there with nicer UIs but they are not as flexible or powerful as KiCad. If the UI is that important to you then I suggest using one of the tools that has a more polished UI. The rest of us have managed to work around the UI issues in KiCad, it's just not a big deal.Most of them have, that is correct.
I've used at least 5 or 6 different EDAs and they all had lousy interfaces, even one that cost thousands of dollars. KiCad is free and it does the job. Frankly I'd be annoyed if the UI changed significantly at this point because I'd have to spend time re-learning how to do things, time that I could instead spend making more boards.
In fact, I am almost willing to fork the entire project and find a couple of motivated people to work just on the GUI until even my mom can work with it.
I recommend doing that. Then you will either a) create a much better tool or b) find out writing a much better tool is actually not that easy.
There are projects with similar goals you might want to help out, Horizon (https://github.com/carrotIndustries/horizon) LibrePCB (http://librepcb.org/). There have been several other people promising to make a "better KiCad" but I don't think they got anywhere.
As the main developer of horizon EDA, I obviously beg to differ. I recently completed the PCB for my master thesis using horizon EDA: https://github.com/carrotIndustries/x-band-tx (https://github.com/carrotIndustries/x-band-tx)
Even though some features are still missing, it's perfectly usable for small to medium-sized projects.
(https://raw.githubusercontent.com/carrotIndustries/x-band-tx/master/output/3d.png)
Frankly I'd be annoyed if the UI changed significantly at this point because I'd have to spend time re-learning how to do things, time that I could instead spend making more boards.Would it be so bad to fix the fact that you hit "c" to duplicate something in the schematic editor, but Command-D to duplicate something in the PCB layout tool or footprint editor, but it's drag to select and then right mouse to duplicate to duplicate something in the parts library editor (or that you can drag to select and then copy block and when you immediately go to paste the block, you get an error message "Warning: No block to paste")?
If cleaning that up would hurt the usability of the tool for you, then KiCAD project really is stuck between a rock and hard place...
I've tried to be patient with it, but its unusable. The user interface is just terrible (and I'm a professional software engineer). I finally lost it and uninstalled when I dropped a transistor om a schematic, tried to move it and had it leave part of the symbol behind (this is the latest 'stable' version as of the time of this post).If you are looking for a schematic package completely free of quirks like that you'll be searching a long time. Its amazing how reliable the production of boards can be when you consider the number of on screen quirks most software exhibits.
I've tried to be patient with it, but its unusable. The user interface is just terrible (and I'm a professional software engineer). I finally lost it and uninstalled when I dropped a transistor om a schematic, tried to move it and had it leave part of the symbol behind (this is the latest 'stable' version as of the time of this post).
I've tried to be patient with it, but its unusable. The user interface is just terrible (and I'm a professional software engineer). I finally lost it and uninstalled when I dropped a transistor om a schematic, tried to move it and had it leave part of the symbol behind (this is the latest 'stable' version as of the time of this post).
I've tried to be patient with it, but its unusable. The user interface is just terrible (and I'm a professional software engineer). I finally lost it and uninstalled when I dropped a transistor om a schematic, tried to move it and had it leave part of the symbol behind (this is the latest 'stable' version as of the time of this post).
Altium schematic entry has some quirks that I find cumbersome and annoying. If they get rid of them, then someone else will complain... And, it still crashes, or gets into a state where I need to quit and restart. One could say that this is also horrific.especially considering the price you (your employer) paid for it...
The reason I jumped at PCAD ( then ACCEL PCB) back in the late 90s (I think) was that it had been designed from the ground up to use windows GUI conventions, which made it very easy to get into using.
I this day and age we should not have to sit on the bog with a tablet reading software's instruction manuals.Could not agree more. Your absolutely right.
Well let us know when you've finished creating a professional grade EDA with a wonderful polished user interface. Better yet one that is free, and no less powerful/capable than KiCAD.
Perhaps it's because these are low volume niche applications, they are not selling millions and millions of copies. Given limited dev resources I'd much rather have them fixing bugs and adding useful features instead of wasting time polishing the UI. No matter how good you make the UI, people are still going to complain about it, EDAs are complex by nature.
People saying that pcb software is complex therefore we have to put up with bad UIs is utter nonsense. In the industry I work in, the software used daily is extremely complex, with literally tens of thousands of tools and commands. But the UI and user workflow in the vast majority of those applications is mostly straightforward with a few rare niggles. Where the software does not have a good user interface, complaints fly thick and fast, and people switch to other tools.
I think it is because EEs have low standards and don’t demand excellence from their user experiences.
it is still annoying but it works
(Attachment Link)
Do you want to select a menu item "Place Wire ..." or click a toolbar icon or just press the W key? If you prefer the first two options, you necessarily have to move your mouse to the starting point and then click. If you prefer the latter, you can place your cursor at the starting point and press W and that starts the wire, no extra click involved.KiCad can do both :)
Which is better? I don't know!I do know!
from skidl import *
anodes = Bus('a', 6) # 6-bit anode bus, but only use a[1]..a[5].
cathodes = Bus('k', 16) # 16-bit cathode bus, but only use k[1]..k[15].
# Create an LED template that will be copied for each LED needed.
led = Part('device', 'D', footprint='Diodes_SMD:D_0603', dest=TEMPLATE)
# Connect the 60 second LEDs to the anodes and cathodes.
for a in anodes[1:4]: # Connect LEDs between anodes 1, 2, 3, 4.
for k in cathodes[1:15]: # and cathodes 1, 2, 3, ... , 15.
led(1)['A', 'K'] += a, k # Copy LED template and connect anode and cathode.
# Now connect the 12 hour LEDs, all of which are attached to anode a[5].
# The nested for loops select the cathodes in the correct order.
for i in range(2,6):
for k in cathodes[i:i+10:5]: # Connect k[2,7,12], k[3,8,13], k[4,9,14] and k[5,10,15].
led(1)['A', 'K'] += anodes[5], k # Copy LED and connect anode and cathode.
ERC() # Look for rule violations.
generate_netlist() # Generate netlist file.Now I will admit I am a complete novice using Kicad. I will also acknowledge I haven't read all the documentation I should have done. But my God the interface of Kicad is F***ing HORRIFIC!!!! Why can't I have multiple schematics in a project - I have one project with a requirement of 4 PCBs. Why can I have multiple sheets without 'hierarchy'. Why can't I import a schematic into an empty Project (because I accidently loaded Eeschema independently). WHY is the F***ing cursor permanently snapping on the screen so annoying...The list goes on!!
A friend of mine published some free software years ago ( Realterm ). Some twit was complaining bitterly about some aspect of it - so my friend offered him his money back :-DDThen again, a lot of such tools written by engineers typically have a very convoluted user interface that is only logical to the creator of it (Realterm is no exception...). 8) I can imagine people offering constructive criticism but I get that creators are not open for that; after all the tool works for them.
Kicad is FREE. Why are any of you complaining? If you don't like it go use something else.
I wouldn't call drawing parts a "skill". Srsly, a square with pads is not hard to draw. Drawing pads for non-standard packages is far more tedious (and error-prone).
If software is created as a part of business, I do not care if the product is offered for me “free” or not. Being part of the business it’s never really free and I see no reason to behave any different than as if I paid for it directly. Make your demands and complain loudly if they do not listen “because it’s ‘free’”. Open source or not, free or not, doesn’t matter as long as it’s a part of their business.
There are 3 modes for software, paid for directly by user, completely free and funded free software.
Kicad is funded around $20k a year.
QuoteKicad is funded around $20k a year.
Which is enough to pay a single programmer for about 1/2 day each week. To what does that entitle the typical KiCad user?
Kicad is FREE. Why are any of you complaining? If you don't like it go use something else.
I really hate this attitude, it is unfortunately pervasive in many open source communities and it does a lot of damage to the open source movement. Just because software is free doesn't mean it has to be garbage, and it doesn't mean people aren't allowed to criticize it. A sensible author will listen to criticism and at least take it into consideration. Yes the software is free, but so is all the QA they are getting from the people that are criticizing it. A lot of free software is very good, very polished, and continues to improve, free is not an excuse for being crap.
There's a world of difference between providing constructive feedback to the developers, and whining about something on an unassociated forum.
People are allowed to whine, get over it. If you don't like it, don't read it.People are allowed to whine about whining, get over it. If you don’t like it, don’t read. :popcorn:
Writing from a soft-dev perspective here.
It seems to me that everyone who has made a suggestion about a database driven library has a specific way they want it implemented and they're all different. And nobody with such an opinion has stepped up to the plate and actually written an implementation proposal.In the end the will to make a change has to come from the inside; some of the Kicad developers have created an implementation proposal for a database driven component system and it is being developed. AFAIK to be included in release 7. Nobody had a different opinion about that BTW; most CAD packages that have it, implement it in the exact same way.
In the meantime, the developers have concentrated on the nuts-and-bolts usability of the application, and honestly, it's quite excellent.You can always wish for all improvements / new features to be part of the next release but the reality is: One step at a time.
... again, as eugene notes, this thread was started in 2018 and many (most?) of the complaints in it have been addressed by the Kicad developers. They really are responsive to user requests.The message, to which I was responding, was written yesterday, not in 2018.
Kicad is FREE. Why are any of you complaining? If you don't like it go use something else.
I really hate this attitude, it is unfortunately pervasive in many open source communities and it does a lot of damage to the open source movement.
Thing is, open-sourcing some software in itself doesn't make developers owe anything to their users. They're already cool enough to share their projects and give them essentially free time.
And your attitude is bound to change completely depending on which side you're on. As a user, you feel your suggestions, rants and whining are all reasonable, useful and should be listened to. The same people getting on the other side of the fence suddenly realize there's a bunch of people "watching you work" while explaining to you how you should do it.
He's just sore because he couldn't earn that with his significantly less capable software.
It seems to me that everyone who has made a suggestion about a database driven library has a specific way they want it implemented and they're all different. And nobody with such an opinion has stepped up to the plate and actually written an implementation proposal.
Writing from a soft-dev perspective here.
Software built by the users suits authors’ needs and is built by adding new features as required. It is not written with other people in mind, at least initially. If you write your own program, learning a single new input action is zero effort. You go through it dozens of time while implementing the feature anyway. They are usually coming from branches unrelated to programming or are early on that path, so they lack relevant knowledge and may make unexpected choices. That leads to applications that, when first used by a newcomer, seem to be filled with unintuitive controls. As soon as the obstacle of learning them is overcome, they are not worse than any other.
Situation is different if the application is built with the intention of being sold or at least delivered internally to a vast group of workers. That type of software since beginning is developed to appeal to possibly wide audience. Any obstacle in adoption is putting the company in a serious disadvantage compared to the competition.(1) So care is taken from the very beginning to make UI familiar. Since the program is written by professional developers, who know their trade,(2) they have knowledge, experience and studies to do that. They are usually also not the pioneers in the field, but build upon existing solutions, which they copy and improve.
You obviously haven't software developed enough.So you are trying to dismiss a general observation by providing particular exceptions? Even worse, the primary mention being SAP — a system that entered market nearly half a century ago and most of its current position is from vendor lock-in and massive branding? :palm:
Side note, there will be database library support in 7.0, we are going to generalize as far as a ODBC and REST api interface and let everyone reinvent the wheel a thousand times to make whatever ERP / PLM integration they want.
The PCB layout software has gone a step back in stability compared to version 5. I just spent the last 6 hours laying out a design and the trace router bogs down with more than one bend, also it crashed the program on one occasion. I don't remember that happening in version 5.
Whatever changed in version 6 has been there since the first release version. I'm on 6.0.4 now.
I remember a friend of mine who works there telling me that Satya Nadella stated in a presentation "who better to test the code than the developers that wrote it?"If that is true (which I strongly doubt), then Satya Nadella is a complete idiot. Everyone knows that the developers of software are the worst candidates to test their code. Even chimpansees straight from the forrest are better for that job.
If that is true (which I strongly doubt), then Satya Nadella is a complete idiot. Everyone knows that the developers of software are the worst candidates to test their code. Even chimpansees straight from the forrest are better for that job.
How many of KiCad's developers are actually using it for designing circuits?How many of them use it on a regular basis on a professional level?
How many of KiCad's developers are actually using it for designing circuits?How many of them use it on a regular basis on a professional level?
Spitting out at least a couple of highly complicated boards every month, being paid by the hour, having to minimize developing time as much as possible.
But anyway, not that it matters, because it seems 99% impossible to have a constructive and respectful conversation about it.
I wonder how many Altium or Eagle/Fusion software developers design PCBs for a living?This kind of snappy responses do not help, and just add weight on b_force's statement that it is really hard to have a conversation regarding this. I'd assume that Altium/Autodesk have (or at least should have) people employed who talk to and look at how EE's work with EDA tools. Furthermore, they certainly listen to requests from their big customers. But this is a viable mostly for big businesses. Small businesses don't really have a say what is got, what is bad and how should it be improved. Well they can say, but I doubt anybody listens
This kind of snappy responses do not help, and just add weight on b_force's statement that it is really hard to have a conversation regarding this.
I agree his statements are too absolute, and at least to me is seems as he made up his mind. And as wiser man have said "If you’re arguing, you’re losing" so I dont really want to engage him.
But your response is just adding gasoline to the fire. I know it is hard to keep your mouth shut, but the only way we might get some of the people which have already made up their minds to open up a bit is with polite conversation. Even if the conversation from their side is not polite at times.
I agree his statements are too absolute, and at least to me is seems as he made up his mind. And as wiser man have said "If you’re arguing, you’re losing" so I dont really want to engage him.
But your response is just adding gasoline to the fire. I know it is hard to keep your mouth shut, but the only way we might get some of the people which have already made up their minds to open up a bit is with polite conversation. Even if the conversation from their side is not polite at times.
But we are getting OT
That is not what MitjaN is saying. Bring back solid arguments in a polite/calm manner and, if all else fails, ignore and do not engage anymore. That works with children of all ages, including the ones well beyond their teenage years. ;DI agree his statements are too absolute, and at least to me is seems as he made up his mind. And as wiser man have said "If you’re arguing, you’re losing" so I dont really want to engage him.
But your response is just adding gasoline to the fire. I know it is hard to keep your mouth shut, but the only way we might get some of the people which have already made up their minds to open up a bit is with polite conversation. Even if the conversation from their side is not polite at times.
But we are getting OT
So what you're saying is that if a child repeatedly and unreasonably insists that peanuts are made from peas, then we should not explain to the child how they are wrong, but instead console them and tell them that we love them.
But I'm not the kid's mother.
I'm frustrated because this thread is five pages and four years of going in circles. The complaints seem largely unchanged even though the thing being complained about has changed. Moreover, those changes have been a direct result of the complaints, yet the complaints keep coming more or less unchanged.I couldn't agree more with you. Being a user of Kicad for years, I can attest to how improved the newer versions are. Being also a user of Altium and Cadence as well, I can tell that each can stand on their own merits.
That's just not my own "opinion" but coming from quite some experience with other companies and teams as well.
Except for some hobbyists, I have never met a person in a professional company liking KiCad.
I have been hearing for years that it will improve.
[
Now you know of two professional EE's that use and like KiCad. You are no longer entitled to say "I have never met a person in a professional company liking KiCad." 8)
[Childish and passive aggressive response deleted.]
I'm frustrated because this thread is five pages and four years of going in circles. The complaints seem largely unchanged even though the thing being complained about has changed. Moreover, those changes have been a direct result of the complaints, yet the complaints keep coming more or less unchanged.
Going a bit off-topic here but out of interest:
@Eugene: since you seem to have experience with both Kicad and Altium: what is your assessment on how far KiCad is from becoming an actual replacement for Altium? My feeling is that the next version of Kicad could hit that mark or am I very wrong?
Anyway. This thread appears in pretty much all electronics forums.
*After looking at recent threads after getting those digest emails, I realized that the reason I stopped participating was because the forum had become a circle jerk. The same people talking endlessly about the same topics. There were no new-user posts.
There's no doubt that Altium has a more mature interface, but I'm not sure that actually makes it better. 'Mature' eventually turns into 'old.' :-DD
The complaints seem largely unchanged even though the thing being complained about has changed. Moreover, those changes have been a direct result of the complaints, yet the complaints keep coming more or less unchanged.
In fact it's the main reason why I don't bother much to be on forums and these kind of discussions anymore.But anyway, not that it matters, because it seems 99% impossible to have a constructive and respectful conversation about it.I wonder how many Altium or Eagle/Fusion software developers design PCBs for a living?This kind of snappy responses do not help, and just add weight on b_force's statement that it is really hard to have a conversation regarding this.
What is the bigger picture? That by itself is a bit of an empty statement. For sure there are other more advanced CAD packages out there compared to Kicad. But there are also less advanced ones. The way I see it KiCad is somewhere on the middle of the road and has replaced Eagle as a general purpose schematics & layout tool.In fact it's the main reason why I don't bother much to be on forums and these kind of discussions anymore.But anyway, not that it matters, because it seems 99% impossible to have a constructive and respectful conversation about it.I wonder how many Altium or Eagle/Fusion software developers design PCBs for a living?This kind of snappy responses do not help, and just add weight on b_force's statement that it is really hard to have a conversation regarding this.
These days I can even literally predict the next response; that they beg to differ, but totally missing the bigger picture.
In fact it's the main reason why I don't bother much to be on forums and these kind of discussions anymore.
These days I can even literally predict the next response; that they beg to differ, but totally missing the bigger picture.
Also instead of having an objective constructive debate, people just come up with personal believes that are already set and stone.
That is not a debate or an argument, that's just throwing statements at each other.
In a proper discussion or argument people try to understand each other points of view.
If you want a constructive discussion, you might start by being a bit self-critical about your earlier post. Do you really believe that, for Kicad to have merit, its programmers also must be professional PCB designers? Do you really believe that Kicad has not improved at all over the years, as you had implied?And this is the exact reason why I don't bother.
I can't speak to other platforms, but a few years ago I decided to try my hand at making a PCB to do what I wanted. After struggling with the schematic editor for Eagle I gave up in frustration and downloaded KiCad. I found KiCad to be far more intuitive to use. Right-click popped up context menus and the keys were generally intuitive. Want to delete a component? Select it and hit delete. I've used it ever since. There's certainly room for improvement, especially with all the UI bugs I'm hitting with 6.0. I'm hitting a serious problem where the focus switches away from the PCB editor to the schematic, so when I select a component to rotate with 'R' I might suddenly have the same component in the schematic editor rotate! This may be some weird interaction with KWin and the fact I use focus follows mouse. I'm sure that will be fixed since I'm not alone with this.
I think part of KiCad's problem was their choice of wxWidgets compared to something like Qt, the latter being better for large complex applications with custom GUI requirements. I also hit a lot of issues with routing in 6.0 where it seems to struggle at times, and clicking a track does not lay it down to let me continue, much to my chagrin. In many ways, I prefer 5.1. It certainly worked a lot better for me.
No one is forcing you to use KiCad, so use Circuitmaker? I don't see the problem.
It's funny how entitled people get when you give them free stuff.
Well you've covered a broad series of grievances I think that should help advance the development of Kicad. I'm surprised after a hundred exchanges with others you still wish to persist with Kicad. Surely trying something else might yield better results for you.
He's got some good points. One thing I actually appreciate about EAGLE is that the schematic is the controlling document, so to speak. From what he's saying, it sounds like KiCAD not only still doesn't do back annotation properly, in the sense that coherence between the board layout and schematic are continuously enforced, but that it treats connections as "artwork" rather than as first-class objects.
I can see where a lot of people would find that approach problematic while others might not care as much.
The part I quickly found incomprehensible is that this isn't a bug, it's a feature. When you think you're
connecting a wire to a pin, you're not. All you're doing is putting an end of a line at a place where there
happens to be a dot. KiCAD's schematic capture does not join the two and add the connection to the
netlist database, because there isn't one. Somewhere later in the design flow, I guess, some netlisting
module must run around and generate meaningful data, but at that point you're just drawing a bunch
of extremely error-prone pictures, because any time you move something, lines and pins and vertices
are going to bump into each other, and without a running netlist db to verify against, KiCAD can't tell
you when you're about to screw yourself.
[...]
And... oh, yeah... the GUI's really awful too. These people (the developers) have obviously never
heard the old saying about how great composers don't invent - they steal. Go and nick the best
ideas available for your GUI from every piece of software you can get access to and roll them
together into a better one. NIH is for idiots.
One of us must be missing something. What exactly do you mean with the schematic capture not joining pins and wires and adding that information to the netlist? KiCAD quite obviously "knows" in the schematic editor, that wires are nets and what they connect to, and it becomes abundantly obvious as soon as you hit the ERC button.
Regarding the GUI, beauty is in the eye of the beholder. I can find no (major) fault with KiCads way of interacting with me, but that may just be my personal bias (or lack thereof). As far as "steal is better than invent", I'm sure glad the developers didn't copy from "Eagle".
Tell me: If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing? Do the connections follow along, rubberbanding
the wires to the pins?
Yes, with KiCad the connections rubberband, maintaining 90-degree angles if you like. Air bunnies not involved. When have you last tried it?
Schematic capture evidently knows nothing and enforces nothing. Tell me: If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing? Do the connections follow along, rubberbanding
the wires to the pins?
The command you want is G(rab), not M(ove). Voilà, rubberbanding.
Voicing strong opinions does not work so well if not backed by solid knowledge...
In any case you are jumping to conclusions. Yes, in some situations KiCad does not automatically re-route the connections (namely if you change a footprint and move its pins around while it is already in your schematic). But how does that lead you to the conclusion that it does not "know" about the connections? KiCad knows about them; it lets you break them; it then knows they have been broken (and will tell you so if you do an ERC).
You may wish for a feature that lets you move footprint pins mid-flight, I can see how that might be useful at times. (I can also see how it might create a mess at times.)
But jumping from there to a "KiCad's architecture is fundamentally flawed" is fundamentally flawed...
Does the
phrase "feeping creaturism" mean anything to you? This is what happens when you
have a perfectly democratic, egalitarian project: Nobody takes responsibility for QC
and saying "wait, that's an obscure, idiotic, and confusing sort-of-duplication of
functions, so one of them has to go."
Kicad has actually pretty good documentation, so instead of whining, read up a little and then if some feature still bothers you, change to another product or actually get involved and do a feature request. Or instead of that attitude, actually ask nicely, and someone could bother to answer. Sorry, if I'm being an ass today.
And here we see the sort of person who doesn't think a bolt can be turned without a Snap-On wrench.
Dear propellerhead, you got Mentor Graphics, you got an attitude problem -- is there anything else you need? Not from me, I reckon. Bye.
But your comment is really just an ad hominem attack
Oh - I know... they're waiting for someone to sit them down in front of a
real EDA system so they can grow up and stop impressing themselves with how
they compare to Eagle.
Your uh, 'good' gesture driven UI, by the way, would be entirely unusable to me.
I'm providing a public service,
- If you aren't an ass today (or any other day), you'll find you don't have to apologize for it.
Your uh, 'good' gesture driven UI, by the way, would be entirely unusable to me.
I'm genuinely interested in learning why. Is it a physical limitation, or something else?
Spatial dysgraphia. Or at least symptoms generally in line with such. I can type at speed, I can spell perfectly well, my fine motor control ranges from microsoldering to long range shooting, but ask me to draw you the letter 'a' and you'll get something you'd expect from a three year old. Gestures are torture.
Spatial dysgraphia. Or at least symptoms generally in line with such. I can type at speed, I can spell perfectly well, my fine motor control ranges from microsoldering to long range shooting, but ask me to draw you the letter 'a' and you'll get something you'd expect from a three year old. Gestures are torture.
That's really interesting. I don't envy you at all, but it's certainly interesting. So are you
able to successfully navigate EDA like this because you're picking items from a list, have
orthogonal routing enabled on a coarse snap grid, etc., - operations that don't require
accurate and unconstrained motions in space? Do you substitute a lot of keyboard
operations for stuff usually done by mouse? If so, maybe the issue would be the tolerable
level of complexity of the gestures - or is it so severe that getting the orientation of a
straight line is really hard?
Just for reference, this topic has been discussed here, too https://forum.kicad.info/t/symbol-editing-and-the-netlist/39271 in similar style and with similar intent.
The reality is that there is no netlist
within schematic capture! That was painfully confirmed in the course of the long argument in
the KiCAD forum that I referred to earlier, so please don't try to pretend there is.
I don't know how hard that would be to implement in the existing editor.
Looking at the referred-to thread in the Kicad forum the example shown is where a pin is moved from the bottom of a device to the top, and the wire that was (supposedly) connected to it is left hanging. But, it shows that the wire has the correct net name, and the device has the pin named as such. Surely it wouldn't be that difficult to think, "Hmmm, this wire is on the net for that pin, when not just plonk it on top?"
Of course, there would be unintended consequences - do you really want wires auto-joining whenever you plonk something down? Perhaps there could be some distance-related magnet on a pin (which might solve the queries we see of wires not joining to pins because both aren't on the same dot of a stupidly small grid).
However, if the wire has the right net and the pin isn't connected to that net, wouldn't that cause an ERC error? If so, surely that's the problem solved.
One of us must be missing something. What exactly do you mean with the schematic capture not joining pins and wires and adding that information to the netlist? KiCAD quite obviously "knows" in the schematic editor, that wires are nets and what they connect to, and it becomes abundantly obvious as soon as you hit the ERC button.
Schematic capture evidently knows nothing and enforces nothing. Tell me: If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing? Do the connections follow along, rubberbanding
the wires to the pins?
[...]
[skipped description of stroke based UI]
And if you can actually visualize it, play these operations for your mind's eye, you'll
immediately grasp that at no time do your eyes deviate from the area of focus - the
part of the schematic or layout that you're actually working on - so your brain doesn't
have to do a context switch finding the needed function in a huge menu or the key
you need on the keyboard before returning to the work and trying to recover your
context. Not only fast as hell, but less mentally exhausting. This is what's meant
by "a good UI".
Well. KiCAD recently gained the ability to rubberband wires on dragging symbols, but it's a far cry from what you describe. It will create a tangled mess of lines when you "overdo" it. Hence I tend to not "wire up" my schematics, but I use net labels mostly to connect, well, nets by their name instead of using an actually visible wire. Rearranging my schematic is then just moving the symbols with their connected net labels. Some say it creates schematics that are easier to read. But this may just be an excuse ;)
Regarding the stroke UI, I can totally see the advantage of gestures instead of chasing a menu, and I can picture how it would work far better with a tablet and stylus instead of a mouse. Indeed it might be really fast, when it's ingrained in your brain after a couple years. But is there really a clear advantage over well chosen keyboard shortcuts to common functions? Apart from the obvious advantage of freeing up one hand for holding a coffee mug.
The existence of a superior UI doesn't make all other UIs horrible, tough.
And, for a project that effectively has two full-time paid developers and a 5 figure budget, I think they're doing
great. I'd guess even the first prototype for Mentor Graphics stroke UI was more expensive than KiCads entire yearly
budget.
Well. KiCAD recently gained the ability to rubberband wires on dragging symbols, but it's a far cry from what you describe. It will create a tangled mess of lines when you "overdo" it. Hence I tend to not "wire up" my schematics, but I use net labels mostly to connect, well, nets by their name instead of using an actually visible wire. Rearranging my schematic is then just moving the symbols with their connected net labels. Some say it creates schematics that are easier to read. But this may just be an excuse ;)
I can assure you that I'm not among that "Some". That has its place, but I keep seeing it done where its use isn't
really justified and could be avoided by just thinking the drawing's layout through a little further. I really won't do it
unless I'm carrying signals to another sheet. And I've seen it done to such a ridiculous extreme that what should have
been a coherent schematic really had no lines at all; it was a thick binder of 11x17 sheets, each of which had maybe
a dozen gates on it, with the net names on every input and output. It was perfectly accurate, perfectly unreadable
and perfectly uninformative.
Where it comes to the GUI: in my experience every piece of software that does a somewhat complex task, has a horrible GUI that simply needs time to learn.
I am causal KiCAD user....
Is KiCAD a good enough tool not is KiCAD perfect.
I am causal KiCAD user. I get that there is some non optimal issues when updating a symbol already used in your schematic. What I do not get is the extreme violent reaction to such a simple thing? Obviously we are many that manage to use the tool anyway.
...
Is KiCAD a good enough tool not is KiCAD perfect. We know it has flaws. The issue being discussed here I would put under "quirks" and not something that will stop my use of the tool. I hope it gets fixed. Until then I will just remember that I need to fix my schematic after updating a symbol - not that big a deal?
I don't want to come off sounding as though I have fundamental problems with the open source development
model, but with the passage of time it's become quite clear that it has not fulfilled one of its basic promises,
which is the assurance of high quality thanks to a large number skilled participants constantly vetting and
improving the code.
Is it "good enough"? Obviously, for many people, yes. But then again, if you're chained to a car axle in a
dump, eating weeds, garbage, and the odd rat and drinking your urine might be "good enough" to keep
you alive.
[...]
Look, I don't get into these bunfights because I have some weird personality defect that craves conflict,
a perverse need to lord superior knowledge over others, etc. This entire conversation comes from a
sincere desire to see KiCAD improve to the point at which I think it's "good enough". I love Mentor, and
there isn't anything I can't do with it. But I would like to be able to work on a system that weighs
less than 50 kilos - without having to suffer windoze! At present, though, that's just not possible because
whomever made the early decisions around schematic capture and the netlist appears to have lacked
some really necessary experience in the field of EDA and made very poor choices. The emperor has no
clothes; you can now choose what you see.
... realtime netlist observance is very closely coupled to, but not actually a feature of, the GUI. It's core functionality that, if not taken seriously (as I've argued), compromises and diminishes schematic capture ease of use and reliability and pushes the burden of both avoiding and detecting errors back to the user.
The behaviour in Orcad capture (and I suspect Altium as well) is that every connection receives a unique netlist name which get updated when several connections are joined together in a schematic. During post-processing the nets get optimised & cleaned up depending on whether sheets are re-used or not (like the linking process when compiling a C program). This behaviour makes it possible to browse nets in a design and navigate to them from an overview of all the nets in a schematic (for example). This is useful to work efficiently on bigger designs but from the remarks of some it seems Kicad isn't doing this (yet).Quote... realtime netlist observance is very closely coupled to, but not actually a feature of, the GUI. It's core functionality that, if not taken seriously (as I've argued), compromises and diminishes schematic capture ease of use and reliability and pushes the burden of both avoiding and detecting errors back to the user.
The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.
When evaluating if I need to ditch KiCAD for a commercial alternative, it is really not the small things like that. It is the big things like Altium being totally unaffordable and the company appears to behave badly too.Last time I checked Orcad is pretty affordable and you can choose the modules you need so you don't pay for what you don't need (although I highly recommend getting the CIS option for database driven component management).
Wow - you've really missed the point here, haven't you?
The problem with symbol editing is not what
this conversation is about. It's where it started - the rock that, when flipped over, exposed a cavern of rot.
It's not the disease, just a symptom.
The thing is you have a perceived idea of what the underlying data structures should be. Without actually checking how said data structures actually are implemented and why. From what I can tell, you are just doing a guessing game here. I suspect the issue is a lot more complicated.
Checking the text content of a random schematic file, I notice that everything has a UUID assigned. Yes it appears the wire end points are identified by the coordinates instead of the UUID. But switching that around would be a trivial change of the file format. Generating the netlist from this file is actually trivial.
But this is completely irrelevant for me as a user of the program. If I wanted to contribute to the program I might care but not as a user. You are naive if you believe the internal data structures of your favorite closed source program is perfect according to some standard for perfectness. You might even be shocked to discover your favorite closed source program doing the exact same thing internally - how would you know?
The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.
I'm guessing you are referring to realtime ERC. For this to work you'd need to have symbols with input, output, bidirectional and power pins properly specified. In reality this gets in the way quickly. What if you want to filter the power supply using an RC filter or ferrite bead? All of the sudden you are connecting a generic net to a power pin.The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.
No, you're getting lost in the explanation. The entire netlisting part that I've described isn't, and shouldn't be,
the user's business. It's something schematic capture does without your participation - it's just part of the
process. You go about your business and the schematic UI creates, maintains, and enforces - in real time - the
netlist which, yes, will be needed later, but in the here and now keeps you from inserting errors into your own
work.
I don't see this "promise" broken. The definition of quality is a difficult thing, and everybody who has a different opinion on that should read Robert M. Pirsigs' "Zen and the Art of Motorcycle Maintenance". Subjectively, you're hunting for a certain functionality and declare "rot" because your expectation is not fulfilled.
I'm guessing you are referring to realtime ERC.
No. Please rephrase your wall of texts / rants into 2 or 3 (at most) short sentences for everyone to understand the exact problem definition you are trying to convey.I'm guessing you are referring to realtime ERC.
Nope. My recommendation would be to go back and actually read what I wrote rather than guessing.
Please rephrase your wall of texts / rants into 2 or 3 (at most) short sentences for everyone to understand the exact problem definition you are trying to convey.
The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.
No, you're getting lost in the explanation. The entire netlisting part that I've described isn't, and shouldn't be,
the user's business. It's something schematic capture does without your participation - it's just part of the
process. You go about your business and the schematic UI creates, maintains, and enforces - in real time - the
netlist which, yes, will be needed later, but in the here and now keeps you from inserting errors into your own
work.
Once you've generated that net, you can't mess it up by accident. If you, say, move a resistor pin onto an existing
net, it gets an error flag until you either explicitly connect or separate them.
If you don't understand what it is trying to do then you'll be either fighting it all the time or trying different things out because that worked, once, last week.
But my post above, which you quote, is asking how essentially how it decides you've 'metaphorically
clicked a button'
and the design is as you want it, or you're still working on it. It's quite common to be modifying the design as you go along (that's why we do it all in CAD rather than scribbling it on a fag packet before drawing it up so it's Right First Time). Often I will insert a resistor or remove it or have hanging nets because, well, it's being designed innit. I don't mind a little red icon pointing out some unfinished business (but tend to ignore them anyway because, well, it's being designed and I know it's not finished). But if I had to manually ack every such case I'd be rooting away in settings to find the relevant tickbox to untick.
So it's not clear to me at all what benefit (other than the one nctnico spelled out about overview maps) being hassled to ack something every time I make a change brings.
And, while we're here, I really hate the Kicad GUI. In fact, that's the major reason I am not making things with it. But I hate gesture-based interfaces just as much because you can end up commanding something unintentionally. And even intentionally, you can command the wrong thing. Just to keep this on topic :)
"Wall of Rants" - I like it, except for the Phil Spector comparison it suggests/invites;
he was always a psychopath who made near-totally-shit music.
[...] that choice is entirely due to
the netlist-ignorance problem. In my limited experience I found it confusing and inconsistent, in part
because when I thought I was making connections they didn't behave as though they were... which
turned out to be correct.
If you don't understand what it is trying to do then you'll be either fighting it all the time or trying different things out because that worked, once, last week.
I can't even begin to imagine where you got that from. You connect things and they're connected.
You don't and they aren't. If they aren't but look like they are (such as might happen with a move or a
symbol edit) they get flagged so you can correct them and make sure they aren't errors in the making.
I absolutely cannot comprehend how you get a recipe for confusion and conflict out of a few simple rules
like that.
The irony here is that my personal opinion being that everything that isn't strokes pretty much
sucks goat ass isn't actually affecting my choice not to use KiCAD (yet) - that choice is entirely due to
the netlist-ignorance problem. In my limited experience I found it confusing and inconsistent, in part
because when I thought I was making connections they didn't behave as though they were... which
turned out to be correct.
Wrt strokes, I'd be interested in hearing more about your experience and why you don't like them. Sure,
I muff strokes when I get going too fast and the gestures get a little too sloppy, but you can always escape
a function before it does anything you don't want, and if you don't, there's an undo queue - you just back
up as many steps as necessary with the Undo stroke.
In the 50 or so designs I've done with KiCad (some simple, some not) I have have not seen this "netlist ignorance problem". I create the schematic, then do the layout. The layout rats next shows the netlist connections, and there's never been any confusion there. I run the layout DRC tool and it tells me if the layout matches the schematic. I don't change the layout connections and then back-annotate the schematic (which might be a useful thing for me to try), I always work from the schematic. So where do you see the netlist ignorance problem?
"Wall of Rants" - I like it, except for the Phil Spector comparison it suggests/invites;
he was always a psychopath who made near-totally-shit music.
Is this an example of the "objective reality" we should all be striving for?
I take music as seriously as a sucking chest wound, and yeah, I'll
stand by what I said: A psychopath and a hack.
a band that has been foundational in progressive music since 1970whos that then?
I'm guessing you are referring to realtime ERC.
Nope. My recommendation would be to go back and actually read what I wrote rather than guessing.
"Oh, I wish you hadn't gone there. I read that pop junk as a teenager shortly after it came out, rejected it as
the edge-of-new-age woo-woo that it is, and opted for a life of engineering instead that wasn't informed by
Jonathan Livingston Seagull or Carlos Castaneda or whatever other silliness occupied the bestseller charts at
the time. I talk about stuff like that over Sunday coffee with old university pals who took the arts+philosophy
route, and as I did at the time and have in the decades since, continue to gently mock them for ever having
taken it seriously, and over time most of them have gradually swung over to my side and acknowledged that
it really was a complete waste of time.
But that stuff was harmless, and the world's become in many ways too serious to tolerate that kind of mushy
thinking - that's essentially why the US political scene is the giant smoking trash fire that it is. As a society
they allowed themselves to be steered, by sinister forces, into believing that objective truth does not exist
and that "alternative facts" is a valid notion. Take that step, and the next thing you know half of your electorate
believes in goddamn Qanon.
So, contrary to your claim, I'm out on the ramparts fighting for objective truth, which includes "This is superior
to that, and if you think otherwise and lack evidence, experience, and a sound and compelling argument, it is
not a mere 'matter of opinion'. You are a cult victim."
Ultimately the choice is yours. As we say, "Your gun, your foot.""
"And you know absolutely nothing about my background in music. So you have an opinion -- congratulations!
As for the rest, never mind. I'm also out of patience."
Quotea band that has been foundational in progressive music since 1970whos that then?
Look, I don't get into these bunfights because I have some weird personality defect that craves conflict,
a perverse need to lord superior knowledge over others, etc.
Seriously though: Since you are so fond of instructing others to re-read the thread...
What makes this difficult experience worthwhile are those clueful, experienced few who not only
get it, but agree
The ego is impressive, at least.
The ego is impressive, at least.
I get by. But you need to ask why you're fixated on the messenger rather than the message.
Evidently you have no appreciation for how tedious these little lectures on improving one's
character are, particularly when they come from the colonists.
As fascinating as you find me to be, the conversation here is actually about CAD software.
About the rest, I. Simply. Couldn't. Give. A. Toss.
Makes it look more like you're interested in argument than improving a piece of software you don't use and never will...
Makes it look more like you're interested in argument than improving a piece of software you don't use and never will...
Except that your claim is contrary to my explicit statement that I look forward to KiCAD crossing
this bridge so I can give it another try and see if it's ready to be taken seriously, because I think
it could be useful. So it would seem this is just another skimmer inferring my intentions to fit his
own mental model rather than actually reading what I wrote.
I haven't used kicad since 2011 and i dont remember editing a part causing thr netlist to break.
So im curious did you change the pin numbers on the part or did you simply move them?
And you will inevitably find yet another deviation from your comfort zone and decide the software is still unusable.
And you will inevitably find yet another deviation from your comfort zone and decide the software is still unusable.
Personally, I don't like making predictions, especially about the future.
I'll make another: You'll continue to ignore the human element and argue ineffectually, thus making slow or no progress towards your stated (but not necessarily true) goal. You have fun with that.
I'm still here to discuss a basic problem with KiCAD's schematic capture that'll bring a huge
improvement in its usability, if taken seriously. I will not entertain further discursion from
you on my style of presentation, so save the keystrokes, colonist.
I'm still here to discuss a basic problem with KiCAD's schematic capture that'll bring a huge
improvement in its usability, if taken seriously.
Seriously, you've stated what you think is wrong with the schematic (although I struggle to see how that results in the 'GUI' title).
I haven't used kicad since 2011 and i dont remember editing a part causing thr netlist to break.
So im curious did you change the pin numbers on the part or did you simply move them?
You're coming in late and missing the point. The result of my editing a symbol was the revelation
that schematic capture has no netlist. The lack of a netlist in schematic capture is the point.
KiCAD only generates it later, as a postprocessing step from the completed schematic.
I agree with Via that not handling connections as connections but as graphics is somewhat problematic and I would prefer having some way, whether it be only perceived or actually reflecting the architectural implementation, of preventing accidental de- and re-connecting implicitly something while modifying a design. But I also agree strongly with Jon that the tone in this discussion haven’t been constructive, whether Via feels that way or not. I honestly have felt some arrogance here.
I certainly have my disagreements with many design decisions in KiCad implementation or behavior and have certainly annoyed the developers more than once. Yet this isn’t a good way forward. I’ll close this thread for now. The facts and opinions have already been expressed anyway. The subject matter itself is open for discussion in the future, of course.
why are you so hung up on the netlist? file -> export -> netlist...
But it still seems Kicad has -by the looks of it- a complete electrical rule check in the schematics editor. So its not like the schematic editor is completely dumb.I haven't used kicad since 2011 and i dont remember editing a part causing thr netlist to break.
So im curious did you change the pin numbers on the part or did you simply move them?
You're coming in late and missing the point. The result of my editing a symbol was the revelation
that schematic capture has no netlist. The lack of a netlist in schematic capture is the point.
KiCAD only generates it later, as a postprocessing step from the completed schematic.
there are people that indeed think 'I don't need this so nobody needs this'.
But still, it could turn out to be something worthwhile to persue. I'd like to have a clear understanding of what the problem is and how that can be solved.there are people that indeed think 'I don't need this so nobody needs this'.Bear in mind we're dealing with an equally extreme viewpoint, "I need this so everybody needs this".
Again: it would be nice if you could outline the benefits of having a netlist aware schematic editor in Kicad. Without getting sidetracked by 'Mentor does it this way' or Mentor specific user interface behaviour. IOW: what is the bare to the bones benefit to users to have a netlist aware schematic editor? What kind of useful features does it allow?
As others in the conversation have noted, there are examples of both methods
out there among the different packages, but in general, the higher-end, more mature, and
(incidentally) more expensive ones maintain and enforce the netlist in real time because
there's significant value in schematic capture understanding the difference between things
that are connected and things that aren't, and KiCAD has no such understanding.
In any case, the response is baffling, because they're arguing
for a tool that does less work for them and makes it easier for them to drive errors into their
designs, apparently because they think it's right because that's how it's always been done here.
Since you don't hold back insulting anyone, I may be frank with you and say you come over as an old retired man that never got into the modern world. No cell phones, stuck using a computer and software older than some people here. And now you tried something new, didn't like it but felt a need to explain to the world it was not you, but everyone else at fault. Doesn't help that you may actually have a valid point about something not good in KiCAD. It is still a silly reason and likely not the truth about why you gave up on something new.
I cant believe this thread is still going. I think I posted a bit of a cringeworthy reply like 3 years ago. Anyway - in response to the 'if you dont like it make your own' crowd I'm actually doing exactly that, started a few months ago. I'm aiming for something that will cater especially to visually impaired people - that way its something positive in its own right instead of just another 'up yours' to something I don't like.
As pointed out earlier in this exchange, propellerhead (under the user name "via") has already brought this up a few months ago on the Kicad forum. We can save ourselves time and aggravation, since that thread has fully explored the matter and ends with a very nice summary by moderator eelik:
https://forum.kicad.info/t/symbol-editing-and-the-netlist/39271/110
Coincidentally, he joined EEVBlog just when that thread got closed, and has posted nothing but this rant about the netlist.
I've been pretty happy proof reading and double checking my symbols before I start connecting them up. Even if you don't get the solution you wish, start by addressing the self inflicted aspect of this problem.
Just to be clear (as I have no experience with Mentor at all so you can tell me anything): what you are after is that if you move a symbol the connections will rubber-band along without creating connections that shouldn't happen. If yes, then I think that is a usefull feature that can prevent costly mistakes.Again: it would be nice if you could outline the benefits of having a netlist aware schematic editor in Kicad. Without getting sidetracked by 'Mentor does it this way' or Mentor specific user interface behaviour. IOW: what is the bare to the bones benefit to users to have a netlist aware schematic editor? What kind of useful features does it allow?
You'll find a reasonably concise and descriptive example in reply #173. Yes, I refer to Mentor,
but that's just because it happens to be the system I'm most familiar with, so it's easiest for
me to walk through the steps. There's absolutely nothing about it that is or should be specific
to that package, so if you don't like the word "Mentor", mentally substitute "Mumble".
One more time, though, I'll repeat the benefit: It provides automatic, real-time error-checking
as you enter your schematic. Not full ERC, but the most basic confirmation that what you see
on the page is really what you want, and makes it difficult to insert mistakes into it during the
course of simple operations like moves or symbol edits. If the schematic keeps track of the
netlist as you're entering the drawing, it's able to spot inconsistencies so you can correct them
before they make their way to postprocessing.
Just to be clear (as I have no experience with Mentor at all so you can tell me anything): what you are after is that if you move a symbol the connections will rubber-band along without creating connections that shouldn't happen. If yes, then I think that is a usefull feature that can prevent costly mistakes.
I'm a long time Orcad user and I can tell Orcad doesn't do such checks so you have to be carefull when moving components in order to keep the connections the way you intend. The old DOS version was even worse. When I was an intern at an electronics company they had me create a PCB layout from a netlist. Once the PCB was assembled & being tested the electronics engineer started giving me a lot of flack for making a mistake in the layout. Having quite a bit of layout experience at that point already I was quite sure I didn't because the DRC check wasn't showing any shorts. Long story short, it turned out the engineer had moved a component and DOS-Orcad had screwed up. Instead of 2 lines crossing, both lines where taking a right turn and thus making the wrong connection. This was not visible on the schematic at all! The same circuit was repeated 16 times on the board as well so there was quite a bit of rework involved. Modern day versions of Orcad automatically place a dot in such situations indicating a connection between the lines (and put them into the same net). You could succesfully argue that this leaves checking the schematic for continued correctness with the user.
Worth adding that the system I'm talking about doesn't flag every crossing, of course. That'd
be a makework PITA. It just flags the ones that are more likely to be mistaken for valid connections,
such as a line crossing a pin, vertex landing on a pin, vertex (or end) touching a line, etc.
I don't think Altium and Orcad being 'grown up products' means that their implementation is somehow right or wrong. IMHO the idea that you have to make a connection between parts specifically instead of having the CAD package making assumptions (like Altium and Orcad do) has a lot of merit. I can certainly see the added value of having the CAD package ensuring the integrity of the connections during editing so the chances of errors due to moving / shuffling parts around and/or changing symbols are much smaller.QuoteWorth adding that the system I'm talking about doesn't flag every crossing, of course. That'd
be a makework PITA. It just flags the ones that are more likely to be mistaken for valid connections,
such as a line crossing a pin, vertex landing on a pin, vertex (or end) touching a line, etc.
Altium does that: drag or otherwise cross a pin with a net and they auto-connect, often leading to adjacent-pin shorts when trying to work close to a part. And Altium is a grown-up product. I've also used several products which make a great point of being able to plonk down something in the middle of a net (or, sometimes, net collection) and have them auto-connect.
I don't think Altium and Orcad being 'grown up products' means that their implementation is somehow right or wrong.
Thinking about it: a PCB package will yell at you when you try to make the wrong connection. But why does the schematic package allow you to do this without warning?
Everybody is free to set their own standards. IMHO it is worth debating the merits of certain features as it can only lead to improving Kicad and make it useful for a larger audience.QuoteI don't think Altium and Orcad being 'grown up products' means that their implementation is somehow right or wrong.
Indeed, but the premise seems to be that if they have this sort of behaviour then they are toys and not worth bothering with. Propellerhead says that this is the reason he won't use Kicad.
Yes, but what if the change to the schematic is unintentional (when using an editing mode that isn't intended to create/change connections)?QuoteThinking about it: a PCB package will yell at you when you try to make the wrong connection. But why does the schematic package allow you to do this without warning?
Because you're not making it up as you go along with the PCB? The schematic is where you create the netlist; the PCB is where you use that netlist. Thus you want to be able to make changes easily in the schematic but are very unlikely to do so on the PCB.
but what if the change to the schematic is unintentional
While I agree with you about the advantage of thorough consistency of the predominant “noun-verb” paradigm with Mac and Windows, that’s actually what Altium uses almost everywhere. The z-order commands (send to back, etc) are some of the exceptions that use “verb-noun” instead, as are some of the room management commands.Quotebut what if the change to the schematic is unintentional
You get into the realms of mode switching. I don't think you need a pukka netlist if modes are used, but I haven't written one of these things. Maybe ask Nigel :)
Actually, that's something that annoys me with Altium. In most modern interfaces you select something and then command something to happen to it. Let's say changing the z-order of a window in on Windows: select the window, right click the system menu (both of these could be one operation, of course), select 'stay on top' or whatever your window manager calls it. In Altium to decide what you're going to do and then do it to objects. So for this example you would open some menu (of course, not a right click context menu but some global one) and select 'stay on top', then click the window to which you want it to happen.
I understand how it go to be like that, and that it can even be a Good Thing if you're doing an op on lots of things. Plus it's a mode, so you can't accidentally, say, roll up a window by mistake in that example. But I find it a drag because often I use that particular thing just to make some filled box be in the background when making a component. I think it's quite rare that I am doing the same op to many objects, and if I would it wouldn't be that much aggro to preselect them all anyway.
Yes, and probably another reason why they are so irritating!Agreed. :)
QuoteWorth adding that the system I'm talking about doesn't flag every crossing, of course. That'd
be a makework PITA. It just flags the ones that are more likely to be mistaken for valid connections,
such as a line crossing a pin, vertex landing on a pin, vertex (or end) touching a line, etc.
Altium does that: drag or otherwise cross a pin with a net and they auto-connect, often leading to adjacent-pin shorts when trying to work close to a part. And Altium is a grown-up product. I've also used several products which make a great point of being able to plonk down something in the middle of a net (or, sometimes, net collection) and have them auto-connect.
I don't think Altium and Orcad being 'grown up products' means that their implementation is somehow right or wrong. IMHO the idea that you have to make a connection between parts specifically instead of having the CAD package making assumptions (like Altium and Orcad do) has a lot of merit. I can certainly see the added value of having the CAD package ensuring the integrity of the connections during editing so the chances of errors due to moving / shuffling parts around and/or changing symbols are much smaller.
I don't think this is particulary hard to implement; keep a netlist with connections between devices / pin numbers and only allow changes to this netlist in 'connection mode'. Any other edit that invalidates the netlist, results in errors.
Thinking about it: a PCB package will yell at you when you try to make the wrong connection. But why does the schematic package allow you to do this without warning?
Yes, but what if the change to the schematic is unintentional (when using an editing mode that isn't intended to create/change connections)?
You have two modes: 1) making connections and 2) placing components / moving components around to make the diagram fit / look better.Yes, but what if the change to the schematic is unintentional (when using an editing mode that isn't intended to create/change connections)?Can you explain that, please? I don't understand what an editor that doesn't edit might be.
QuoteWorth adding that the system I'm talking about doesn't flag every crossing, of course. That'd
be a makework PITA. It just flags the ones that are more likely to be mistaken for valid connections,
such as a line crossing a pin, vertex landing on a pin, vertex (or end) touching a line, etc.
Altium does that: drag or otherwise cross a pin with a net and they auto-connect, often leading to adjacent-pin shorts when trying to work close to a part. And Altium is a grown-up product. I've also used several products which make a great point of being able to plonk down something in the middle of a net (or, sometimes, net collection) and have them auto-connect.
That's insane. Is it optional, that is, behaviour you can disable?
You have two modes: 1) making connections and 2) placing components / moving components around to make the diagram fit / look better.
So if I want to move not only a symbol (or symbols), but some other stuff along with it like text, a block of wires,
etc., I enable symbols, text, and wires in the select filter, then enclose the block I want to move, select and move it.
QuoteSo if I want to move not only a symbol (or symbols), but some other stuff along with it like text, a block of wires,
etc., I enable symbols, text, and wires in the select filter, then enclose the block I want to move, select and move it.
What happens if something in the selection filter isn't moveable (or open to whatever command you're pushing)? Proteus used to be like this, in that you could select multiple components but only move the last one. Then they had a 'move' mode where you could multi-select and all would be moved, but it failed on some non-component things that got excluded. I think this is an example of changing the existing code to implement a new style, and often it's non-optimal. Don't know what the solution is, other than change the underlying design.
You are overthinking it. Moving a symbol is not editing, so it is not allowed to make/break connections. IOW: the user doesn't select the mode, it is inferred from the type of operation the user is performing.You have two modes: 1) making connections and 2) placing components / moving components around to make the diagram fit / look better.
Maybe that was one of the things I was finding confusing - some combination of not knowing
that they were different modes and not knowing where to look to see which one I was in. I'm
not a fan of modes like this in UIs if there's any other way; why not just have one mode - edit -
and make everything else a command/operation?
You are overthinking it. Moving a symbol is not editing, so it is not allowed to make/break connections. IOW: the user doesn't select the mode, it is inferred from the type of operation the user is performing.
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
Not even a little bit. Of course it shouldn't alter the netlist, any more than should moving
anything else. The netlist should only be affected by explicit "connect" and "disconnect"
operations/commands.
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
This seems quite close to what propellerhead suggested from the start? One might expect the default "move" operation to keep netlist connections intact. Which in KiCad it does not; you need to G(rab) or (dra)G to do this.
Kicad behaves the way it does for historical reasons, I assume: M(ove) came first. Then dragging was added, but it could only produce awkward angled wires, so one definitely wanted to keep the M(ove) mode for moving parts and connections around manually. Kicad 7 now has added a dragging mode which retains tidy, orthogonal traces. Maybe it's time to make that the default "Move" behaviour?
As far as I can tell this is essentially the entire issue, wapped up in major communication failure.
As far as I can tell this is essentially the entire issue, wapped up in major communication failure.
Yes, that's what I also understand now, with one addition: If one edits a symbol while it is already connected in a schematic, Kicad does not offer any way to automatically keep the connections. (For moving the symbol around, it does offer dragging as an alternative, so it's only a debate what the default command should be called or how it should behave.)
I believe that was my second point regarding library updates (changes to symbols).
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
This seems quite close to what propellerhead suggested from the start? One might expect the default "move" operation to keep netlist connections intact. Which in KiCad it does not; you need to G(rab) or (dra)G to do this.
Kicad behaves the way it does for historical reasons, I assume: M(ove) came first. Then dragging was added, but it could only produce awkward angled wires, so one definitely wanted to keep the M(ove) mode for moving parts and connections around manually. Kicad 7 now has added a dragging mode which retains tidy, orthogonal traces. Maybe it's time to make that the default "Move" behaviour?
Moving a symbol while severing it from connections should indeed be something you need to ask for explicitly. Additionally, library updates which physically move a pin on the symbol should not sever connections made to that pin.
As far as I can tell this is essentially the entire issue, wapped up in major communication failure.
We should not overlook the case of drawing the wires first and then dropping in a component. This usually only happens with really simple components such as resistors and caps. Nevertheless it is a move or place command that does two things: moves something and makes new connections. And is used all the time by everyone.
We should not overlook the case of drawing the wires first and then dropping in a component. This usually only happens with really simple components such as resistors and caps. Nevertheless it is a move or place command that does two things: moves something and makes new connections. And is used all the time by everyone.
Indeed, and there's discussion to be had as to whether that should occur. I admit, I have a tendency to drop things like dividers and decoupling onto nets in that manner, but I can very easily adapt to either positioning components prior to drawing the net, or giving an explicit command to connect at that point (non-connections of course should be clearly marked in realtime - a simple red x suffices).
Both this case and the case of moving a component while detaching it from nets could be comfortably handled by the use of a modifier key to cause the connect/disconnect behaviour when desired. If one doesn't like such behaviour.. don't press the key.
And I would happily skip those steps in favour of holding Alt as I finish the move command. Same result, less work. Just a macro to save effort.
What if you want some, but not all, of the resulting potential connections to be connected?
Then you don't use the handy 'connect everything' modifier and proceed to handle it manually instead. You choose to invoke it when you know it's the outcome you want.
My view is that if you design without allowing those kind of switches (or make
the explicit decision that they should be used only when absolutely necessary, such as
making rotating/flipping/mirroring options within "move", you can keep the sum total of
commands and commands options much smaller - the RISC vs. CISC decision I spoke
of above.
And my counterview is that giving no such options to shortcut common actions merely gets in the way of efficient workflows. Further, when workflows are already established which rely on such behaviour, entirely removing that behaviour only alienates existing users to the detriment of the project.
No. Moving a symbol is formatting the schematic. Editing is altering the function of the circuit.You are overthinking it. Moving a symbol is not editing, so it is not allowed to make/break connections. IOW: the user doesn't select the mode, it is inferred from the type of operation the user is performing.
Huh? This sounds like either a zen koan or I'm just being pranked. "When is an edit not an
edit? When you're moving a symbol."
Moving a symbol on a schematic is, intrinsically, editing the schematic.
No. Moving a symbol is formatting the schematic. Editing is altering the function of the circuit.
In that case you are limited by your own thinking and perhaps get hung up by semantics... Maybe think about it a bit more and you'll start to see my distinction is very valid. Especially if you want to translate your requirements into creating software algorithms. Ebastler is right on the money with the printed media example.No. Moving a symbol is formatting the schematic. Editing is altering the function of the circuit.
I reject that as a silly distinction, and would love to hear who made it up.
Sorry, I understand the argument, but it's a hair-splitting distinction probablyUnfortunately, under the hood the CAD package will have to make that distinction in order for the functionality you proposed to work. But as a user you don't have to understand that. I'm outlining this as a possible implementation for a Kicad developer who might be reading along.
arrived at by someone with severe OCD. If I substantially rearrange an entire
drawing to group together related functional blocks for possible reduction into
PLDs, it's a mere matter of "formating". If I happen to notice a missing ground
connection while I'm at it and correct the error, suddenly I'm "editing" instead.
And my counterview is that giving no such options to shortcut common actions merely gets in the way of efficient workflows. Further, when workflows are already established which rely on such behaviour, entirely removing that behaviour only alienates existing users to the detriment of the project.
Sure, one can't ignore the "inertia" argument.
Unfortunately, under the hood the CAD package will have to make that distinction in order for the functionality you proposed to work. But as a user you don't have to understand that. I'm outlining this as a possible implementation for a Kicad developer who might be reading along.
I agree that kicad should have an inherent awareness of the netlist. but not for any of the reasons mentioned so far. My one real feature wish for kicad is to enable back propagation of changes to the netlist from PCB to schematic. i.e. back annotation or pin/gate swapping as some would say. I know not everyone thinks this is needed but its a feature I use all the time in Proteus with processor pins. When designing the symbol, I define groups of pins as swap-able. Then when laying out the PCB I can drag net lines from pin to pin to make the layout easier (it swaps the nets on the to and from pins). These changes back propagate to the schematic, but not by moving any wires. That would lead to the kind of schematic mess already described. Instead it swaps the pins on the schematic symbol. That way a neat schematic layout is maintained.
However I don't see how such a feature could work without the schematic having an intrinsic knowledge of the netlist. That would seem to be a necessary first step.
While we will continue to add features and refine KiCad's editing tools to make it faster and more capable (for example, by adding pin/gate swapping) in the future, we will not be changing to a model that requires explicit "connect" and "disconnect" actions to modify the netlist. (Note that unlike the assumptions made by some in this thread, this does not mean that the schematic editor is unaware of the netlist -- it juts means that the netlist is not a separate "entity" that can be interacted with through explicit connect/disconnect actions).This only shows that the Kicad developers don't understand the core of the problem -yet-. As I wrote before, it likely doesn't take much work to the underlying structures to add a realtime 'ERC' which safeguards the integrity of the schematic while formatting the schematic.
If there's one thing I wish they'd fix, it's the inability (as far as I've found) to create traces with square instead of round ends. I find this incredibly annoying when trying to connect a wide trace to a small pad, the rounded end of the trace overlaps the edge of the pad. It would be nice to be able to select different styles of transition when a trace changes width too.100% agreed.
This only shows that the Kicad developers don't understand the core of the problem -yet-. As I wrote before, it likely doesn't take much work to the underlying structures to add a realtime 'ERC' which safeguards the integrity of the schematic while formatting the schematic.
For the benefit of readers here who do not feel up to reading through the long thread on the KiCad forums that repeated this discussion:
Unbelievable as it may seem to at least one frustrated poster here, us KiCad developers *do* see this behavior as a feature, not a bug.
While we will continue to add features and refine KiCad's editing tools to make it faster and more capable (for example, by adding pin/gate swapping) in the future, we will not be changing to a model that requires explicit "connect" and "disconnect" actions to modify the netlist. (Note that unlike the assumptions made by some in this thread, this does not mean that the schematic editor is unaware of the netlist -- it juts means that the netlist is not a separate "entity" that can be interacted with through explicit connect/disconnect actions).
I suggest that users who cannot approach KiCad's paradigm here with an open mind should probably just move on and use other CAD tools. None of us will be offended! There are a number of reasons why KiCad can't and won't be the perfect tool for everyone. If there is enough demand for an open-source CAD tool that works more like Mentor Graphics, perhaps someone will create one.
But If I do horizontal swap of component (mirror) , Kicad will happily DISCONNECT whatever I connected and than silently CONNECT any pins to any wires that happen to align... Silently is key word here...
If there's one thing I wish they'd fix, it's the inability (as far as I've found) to create traces with square instead of round ends. I find this incredibly annoying when trying to connect a wide trace to a small pad, the rounded end of the trace overlaps the edge of the pad. It would be nice to be able to select different styles of transition when a trace changes width too.
No. But if you would be so kind to do that and point to this thread. Maybe it helps to create some understanding for how and why this realtime ERC feature is handy instead of outright dismissal. What 2N3055 wrote is precisely on point IMHO.This only shows that the Kicad developers don't understand the core of the problem -yet-. As I wrote before, it likely doesn't take much work to the underlying structures to add a realtime 'ERC' which safeguards the integrity of the schematic while formatting the schematic.
Did you post above request to the improvement list yet?
Yes, it's a dismissal -- of one specific idea/request, that KiCad should require explicit user action to "connect" or "disconnect" things in the netlist rather than retaining the ability to make connections by moving/placing objects.You missed the point where Kicad can infer the intend of the user perfectly fine. For example: when the user selects the function to draw connections or delete connections, it is obvious that the user is going to make/break connections. However in other modes (like dragging components / wires around, changing symbols) it would be nice if there is a safeguard that helps the user to maintain integrity of the schematic. I know CAD packages like Orcad and Altium don't work that way but I can definitely see the advantage for people working on more complex designs where a mistake can be costly.
Yes, it's a dismissal -- of one specific idea/request, that KiCad should require explicit user action to "connect" or "disconnect" things in the netlist rather than retaining the ability to make connections by moving/placing objects.
There are many other ideas in this thread that are not really related to this specific idea (for example, realtime ERC) that I'm not dismissing.
This discussion (and previous ones) goes nowhere if people continue to assume that the KiCad developers just don't understand something -- the way KiCad works here is an intentional choice and we really do understand the alternatives that some other software tools use. If you accept that, we welcome suggestions and feature requests that would improve KiCad within this paradigm.
Yes, it's a dismissal -- of one specific idea/request, that KiCad should require explicit user action to "connect" or "disconnect" things in the netlist rather than retaining the ability to make connections by moving/placing objects.
There are many other ideas in this thread that are not really related to this specific idea (for example, realtime ERC) that I'm not dismissing.
This discussion (and previous ones) goes nowhere if people continue to assume that the KiCad developers just don't understand something -- the way KiCad works here is an intentional choice and we really do understand the alternatives that some other software tools use. If you accept that, we welcome suggestions and feature requests that would improve KiCad within this paradigm.
Perhaps, then, you'll go a step further than dismissal and the insistence that there's some mysterious paradigm at work here, and explain why you think this is correct and desirable behaviour.
Really, I do understand what is being proposed. KiCad makes an intentional choice to allow users to modify the connectivity of the schematic by moving items around, rather than assuming that once an initial connection has been made to a pin, that connection should be preserved through all other editing operations except ones that explicitly "disconnect" the pin.
In general, KiCad has two tools to change the position of items interactively: moving and dragging. Moving does not, and will not, attempt to preserve connectivity. Dragging does. We welcome suggestions for how dragging can work better (there are certainly cases where a drag can accidentally result in connectivity changes today), but we're not going to get rid of moving.
Really, I do understand what is being proposed. KiCad makes an intentional choice to allow users to modify the connectivity of the schematic by moving items around, rather than assuming that once an initial connection has been made to a pin, that connection should be preserved through all other editing operations except ones that explicitly "disconnect" the pin.
In general, KiCad has two tools to change the position of items interactively: moving and dragging. Moving does not, and will not, attempt to preserve connectivity. Dragging does. We welcome suggestions for how dragging can work better (there are certainly cases where a drag can accidentally result in connectivity changes today), but we're not going to get rid of moving.
As for the OP's original scenario of wanting to edit a symbol in the symbol editor and have its pins stay connected the way they used to be: realistically I don't see that happening, not because of technical limitations but because it is not the kind of "magic" we want. However, a reasonable workaround that we could have in KiCad is to allow the user to drag around symbol pins directly on the schematic canvas (and drag operations should preserve connectivity). This fits a lot better with KiCad's workflow.
I assure you no PCB designer thinks in terms of graphical design and they absolutely think in terms of "this wire to this PIN".
Absolutely wires have to stay attached to the pins EXCEPT when I deliberately perform operation that severs the connection.
No electrical engineer thinks in terms of "connectivity by moving things around".
If you don't see this then this is one of those "opinions" of Kicad team that is not in line with intended audience.
By the way, I think there is a bit of misunderstanding here, as we don't disagree about everything. I'm in full agreement that ERC tools to remind you of potential problems are a good idea.
I assure you no PCB designer thinks in terms of graphical design and they absolutely think in terms of "this wire to this PIN".How do you presume to know how ALL EEs think? Clearly they do not all think alike, or else this discussion wouldn’t be taking place.
…
No electrical engineer thinks in terms of "connectivity by moving things around".
I assure you no PCB designer thinks in terms of graphical design and they absolutely think in terms of "this wire to this PIN".Huh?
No electrical engineer thinks in terms of "connectivity by moving things around".But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.
You haven’t succeeded in coherently articulating what you actually want, never mind a cogent interaction model for it.By the way, I think there is a bit of misunderstanding here, as we don't disagree about everything. I'm in full agreement that ERC tools to remind you of potential problems are a good idea.
And yet you have "dismissed" (your word) the implementation of the simplest, most front-end, user-friendly,
meaningful, interactive ERC that your (potential) users want. I presume this means you'll do ERC the way
you're doing netlisting now - after the schematic is done; that is, too late.
I assure you no PCB designer thinks in terms of graphical design and they absolutely think in terms of "this wire to this PIN".
Absolutely wires have to stay attached to the pins EXCEPT when I deliberately perform operation that severs the connection.
No electrical engineer thinks in terms of "connectivity by moving things around".
If you don't see this then this is one of those "opinions" of Kicad team that is not in line with intended audience.
I've been an electrical engineer and PCB designer for longer than I've been a KiCad developer. Speaking in absolutes about how people think, and telling me you know better, doesn't really help move a conversation forward. I get it: you disagree with me about this. But you can disagree without insisting that your way is the only correct way.
By the way, I think there is a bit of misunderstanding here, as we don't disagree about everything. I'm in full agreement that ERC tools to remind you of potential problems are a good idea.
You haven’t succeeded in coherently articulating what you actually want, never mind a cogent interaction model for it.
I assure you no PCB designer thinks in terms of graphical design and they absolutely think in terms of "this wire to this PIN".How do you presume to know how ALL EEs think? Clearly they do not all think alike, or else this discussion wouldn’t be taking place.
…
No electrical engineer thinks in terms of "connectivity by moving things around".I assure you no PCB designer thinks in terms of graphical design and they absolutely think in terms of "this wire to this PIN".Huh?
Everyone knows that clean schematic design is really important. There’s a huge graphical component to that.
Don’t forget that a schematic is not only a stepping stone PCB layout. The schematic is where and how you work out the circuit design, so while it’s a prerequisite for a DRC-supported PCB layout, the schematic is simultaneously also a goal in and of itself.No electrical engineer thinks in terms of "connectivity by moving things around".But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.
You haven’t succeeded in coherently articulating what you actually want, never mind a cogent interaction model for it.
IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:No electrical engineer thinks in terms of "connectivity by moving things around".But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.
A "connection" that isn't a real (that is, as represented in a live netlist) connection remains
a nonconnection regardless of whether you "move", "drag", or "juggle" it. This is ridiculous.
Sorry, I thought for a while that I had understood your point, but now you have lost me again.
(a) I fully understand the desire for a set of commands which manipulate the schematic while keeping all connections intact. KiCad has those: You can drag a part or a wire, including rotating and mirroring the part, and keep all connections in place.
(b) I kind of understand the preference that commands which break connections should not be available at all, or should be well-hidden in a way where you do not use them unintentionally. Kicad does not do that by default, it makes the connection-breaking Move, Rotate etc. commands easily available. But that is a very superficial change which you can make on the user level: Just assign exotic hotkeys (or none at all) to these commands you don't want. And I see the developers' point that other users will have different workflows and styles and want to use these commands regularly.
(c) What I do not understand is your insistence that a "proper internal netlist" representation is the only path to happiness. That seems dogmatic. From a user perspective, why should I care how Kicad works internally -- as long as it offers (a), and for those so inclined enables (b)?
Thanks for clarifying!
First I want to say I am happy with KiCAD and not complaining at all. But if this is a user survey (and everyone should have one of those regularly) I will say there is some merit to this thread. I don't want the schematic editor to change by alot but it really could handle connections in a more sane way. And without needing two edit modes or anything like that.Interesting. When I export an Orcad schematic to XML (as the native format is binary), the wires are children of a net instance.
I have not checked the source code but I did check the save files. I don't like that wires seem to be indexed by coordinates. From a data science point of view this so wrong. Instead we should have points of interconnect defined with uuid and coordinates. A wire is then a connection between point uuid A and point uuid B or a pin uuid C.
First I want to say I am happy with KiCAD and not complaining at all. But if this is a user survey (and everyone should have one of those regularly) I will say there is some merit to this thread. I don't want the schematic editor to change by alot but it really could handle connections in a more sane way. And without needing two edit modes or anything like that.
I have not checked the source code but I did check the save files. I don't like that wires seem to be indexed by coordinates. From a data science point of view this so wrong. Instead we should have points of interconnect defined with uuid and coordinates. A wire is then a connection between point uuid A and point uuid B or a pin uuid C. That way the point can be moved but the connection never breaks unless intended. And we will not have unintended connections not even if some bug caused the coordinates to be the same.
It means the GUI code needs to be explicit about when to break connections. Yes we can still have "move" that breaks connections but the code behind would need to explicitly break those connections and not have it happen as a side effect. This would then enable the GUI to discover possible unintended (dis)connections and put up a warning dialog.
For example mirroring a symbol causing disconnects on one side and reconnect to random stuff on the other side is probably very rarely intended and should display a dialog to which the user can select ok/cancel. And if editing a symbol can not use "grap" semantics but needs to use "move" then I am ok with it causing disconnections but NOT that it might cause random connections.
TLDR I feel the data model is wrong and it causes errors. It could be fixed without changing the look and feel of the GUI.
You have repeatedly offered explanations, but they have not been clear and concise. That you think it was clear and concise doesn't mean it actually was. As others have pointed out, you have made contradictory explanations that have prevented people from having a clear idea of what you want. And your very rigid, yet unconventional, use of terminology has also made it harder to understand what you mean.You haven’t succeeded in coherently articulating what you actually want, never mind a cogent interaction model for it.
To the contrary, I've repeatedly offered a clear and concise model for exactly what schematic
capture should be doing.
If you haven't read it, it's not because I haven't (coherently) articulated it.I have read it, which is why I know it's not been coherent.
1. When you connect something, it's connected. Not only is it visually connected, but the connection isWhich it does.
entered (by the schematic capture) into the netlist it maintains.
2. When you disconnect something, it's disconnected, and that disconnection is similarly reflected in theWhich it does.
netlist - again, transparently to the user.
3. The software may not make or break connections as the result of moves, symbol edits, etc. Only the userSo which manipulations do allow connections to be made or broken? It's a graphical editor, so the schematic diagram is how the user makes and breaks connections (that is, that is the mechanism for conveying user intent to the software).
can change connections.
If, as a result of moves, edits, etc., entities in the schematic intersect such that theyThe connections created during those operations are real connections.
create the appearance of connections (that haven't been explicitly created by the user), they are flagged
as warnings to the user.
Under no circumstances should the software permit faux connections, that is, elements of the drawing"Faux" means fake, non-real. But they are real connections, and they are represented in the netlist.
that appear to visually represent connections yet aren't properly represented in the netlist. This is what #3
is meant to prevent. It's also apparently the only kind of "connection" presently supported by KiCAD.
Could that possibly be clearer or more coherent?Yes. Your terminology in particular is really problematic.
You are operating from a dichotomy that does not exist. There aren't "real" and "faux" connections. Every connection you see is a real connection, they're the only thing that exists.Quote(a) I fully understand the desire for a set of commands which manipulate the schematic while keeping all connections intact. KiCad has those: You can drag a part or a wire, including rotating and mirroring the part, and keep all connections in place.
Almost, except for the part about "keeping all connections intact". My overarching point is that they
aren't actually "connections" - they just look like connections. If they were real connections you
would not, for example, require a "drag" (which maintains the faux connections) vs. a "move",
which just lets things reveal their true nature and fall apart.
I'm fully aware of those issues, and understood that.IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:No electrical engineer thinks in terms of "connectivity by moving things around".But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.
- Dragging a component can result in creating new connections that may not be wanted. Especially true when dragging a larger piece of circuitry. Personally I have always found this a tricky & cumbersome operation in Orcad as you need to keep a really close eye on what is going on exactly.
- Changing a symbol where pins end up on other locations could go unnoticed as well. Especially when working on a design in a team.
All in all this thread suddenly has made me feel I have been kind of making do with Orcad (for several decades already!) which simply leaves a lot of schematic integrity checking tasks to the user. To be honest I never really gave this much thought until now.
Just thinking out loud: wouldn't it be more efficient to store the wires as being part of a net when the design is saved to a file? That way the software doesn't need to extract connections from the schematic every time it is loaded. A really large schematic may load faster that way.It's entirely possible that some programs do cache the compiled netlist. But I suspect that it's computationally so trivial that there isn't much point in doing so, and runs the risk of the schematic and netlist getting out of sync. If one makes the reasonable assumption that the schematic is only saved when in a stable state (i.e. all operations performed to it are atomic, and have been completed or rolled back), then opening it shouldn't require all that much computation.
The point is that some actions are not intentional and with some additional features, the software can be made smart enough to detect that and warn the user. This is exactly the reason why people use PCB design software with DRC to design PCBs instead of MS paint (to exaggerate a little bit).I'm fully aware of those issues, and understood that.IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:No electrical engineer thinks in terms of "connectivity by moving things around".But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.
- Dragging a component can result in creating new connections that may not be wanted. Especially true when dragging a larger piece of circuitry. Personally I have always found this a tricky & cumbersome operation in Orcad as you need to keep a really close eye on what is going on exactly.
- Changing a symbol where pins end up on other locations could go unnoticed as well. Especially when working on a design in a team.
All in all this thread suddenly has made me feel I have been kind of making do with Orcad (for several decades already!) which simply leaves a lot of schematic integrity checking tasks to the user. To be honest I never really gave this much thought until now.
That doesn't change the fact that in graphical schematic capture software, the graphical representation is how we convey our intent to the software.
I obviously understand this. I understood it before your first reply. And before the second. At the latest, after reading my last reply to propellerhead above, it should be very clear that I understand the problem deeply.The point is that some actions are not intentional and with some additional features, the software can be made smart enough to detect that and warn the user. This is exactly the reason why people use PCB design software with DRC to design PCBs instead of MS paint (to exaggerate a little bit).I'm fully aware of those issues, and understood that.IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:No electrical engineer thinks in terms of "connectivity by moving things around".But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.
- Dragging a component can result in creating new connections that may not be wanted. Especially true when dragging a larger piece of circuitry. Personally I have always found this a tricky & cumbersome operation in Orcad as you need to keep a really close eye on what is going on exactly.
- Changing a symbol where pins end up on other locations could go unnoticed as well. Especially when working on a design in a team.
All in all this thread suddenly has made me feel I have been kind of making do with Orcad (for several decades already!) which simply leaves a lot of schematic integrity checking tasks to the user. To be honest I never really gave this much thought until now.
That doesn't change the fact that in graphical schematic capture software, the graphical representation is how we convey our intent to the software.
No electrical engineer thinks in terms of "connectivity by moving things around".I said that "moving things around" is how GUIs work, and it is.
I said EE, not graphical designers. When you are designing new "electronic contraption" you are compiling a set of components (passive, active and parasitic) and their interconnections. Schematic is human friendly, graphical netlist+BOM. Nothing more. Everything else on schematic is organizational data, revisions, manufacturing data etc....I understand this. But it kinda is part of the job to produce schematics that are easy to read for whoever else needs to work on it down the line (which includes yourself in the future!).
You don't draw a line between two little circles, you are connecting two connector endpoints with a wire. By drawing a line between two little circles. According to a predefined graphical language that was standardized by convention for that purpose.
Clean and clear "look" is certainly a large part of well done schematic layout. But, funny enough, it is not mandatory, and during years I've seen both exceptional and horrible ones. That both created exceptional PCB layout.
You move things around to organize layout and functional groups. That is important, but connections between components are THE SCHEMATIC.Well, the connections between components are the circuit. The schematic is simply a diagram of the circuit. That is to say, the connections/circuit are the actual concept, the design itself, while the schematic is a visual representation of that concept. The fact that the same circuit can be represented in any number of schematic layouts, or even completely different schematic types (e.g. the ones used in industrial automation).
Other stuff is only how it looks and consequently how nice is to read.The latter of which is kinda important.
And many of these things newest versions of Kicad do very well. What is left open to "unpredictable results" is component mirroring and changes to component symbol after the fact. If you mirror pins left and right on symmetric layout component will scramble where inputs and outputs connect... Without warning... That is potential source of error... That would not exist if Kicad was remembering connection to pin which had coordinate , instead remembering connection to arbitrary coordinate in coordinate space that happen to coincide with coordinate of pin of a (whatever) component that happen to be on that position...I know that, but I never said otherwise. I was disputing your blanket claims about how all engineers think.
Then why bother debating something we already agree on? :-// You keep on insisting something isn't what it is and then you suddenly agree. And it turns out your beef is not even with what I wrote.My "beef" was with something someone else wrote, which is why I responded to them. I didn't write to you. You later chose to respond to me over your interpretation of something I hadn't actually said. I didn't "suddenly agree", you only think that because you thought I said things which I had, in fact, never said.
I said EE, not graphical designers. When you are designing new "electronic contraption" you are compiling a set of components (passive, active and parasitic) and their interconnections. Schematic is human friendly, graphical netlist+BOM. Nothing more. Everything else on schematic is organizational data, revisions, manufacturing data etc....I understand this. But it kinda is part of the job to produce schematics that are easy to read for whoever else needs to work on it down the line (which includes yourself in the future!).
You don't draw a line between two little circles, you are connecting two connector endpoints with a wire. By drawing a line between two little circles. According to a predefined graphical language that was standardized by convention for that purpose.
Clean and clear "look" is certainly a large part of well done schematic layout. But, funny enough, it is not mandatory, and during years I've seen both exceptional and horrible ones. That both created exceptional PCB layout.
The fact that a poor schematic (of a good circuit) can produce a good PCB doesn't mean that it's not part of the job.
As for "not graphic designers" -- well, the only places where you see schematic diagrams drawn by graphic designers are in magazines and datasheets. Everywhere else (at least that I've seen), even in places with technical documentation teams, schematics come from the engineers.You move things around to organize layout and functional groups. That is important, but connections between components are THE SCHEMATIC.Well, the connections between components are the circuit. The schematic is simply a diagram of the circuit. That is to say, the connections/circuit are the actual concept, the design itself, while the schematic is a visual representation of that concept. The fact that the same circuit can be represented in any number of schematic layouts, or even completely different schematic types (e.g. the ones used in industrial automation).Other stuff is only how it looks and consequently how nice is to read.The latter of which is kinda important.And many of these things newest versions of Kicad do very well. What is left open to "unpredictable results" is component mirroring and changes to component symbol after the fact. If you mirror pins left and right on symmetric layout component will scramble where inputs and outputs connect... Without warning... That is potential source of error... That would not exist if Kicad was remembering connection to pin which had coordinate , instead remembering connection to arbitrary coordinate in coordinate space that happen to coincide with coordinate of pin of a (whatever) component that happen to be on that position...I know that, but I never said otherwise. I was disputing your blanket claims about how all engineers think.
One solution, which we know the KiCad team expressly does not want, is to have explicit connect/disconnect commands or modes. But my hunch is that you probably don't actually want that, either.
You have to be able to disconnect with the same ease and consistency of use as you had when you connected.
Nothing hidden, nothing asymmetric. A "connect" function and a "disconnect" function, both doing exactly that, and
retaining the awareness of what each means, which is actual connectivity vs. faux connectivity.
Now you are semantically arguing fine points of English language. I'm not saying youre not technically correct, but I'm sorry my English is not that good.Your English is very good!
To most of the people I know, saying schematic means schematic diagram, and that is a document that explain circuitry in device.. It has same functional meaning. You will hear people saying schematic and think circuitry in a device (as in:" we changed the schematic" meaning they changed the circuit ) and when meaning they changed the documentation they will explicitly say "schematic diagram"..Oh, for sure, you hear them used somewhat interchangeably in everyday speech, but they are still distinct things, and since that distinction is at the core of this entire discussion I think it's important to keep it in mind! :)
I will have to insist here. ALL EE think in terms of circuits. When you are designing a circuit you are designing the circuit, not it's schematic representation and don't use idiosyncrasies that particular tools bring in design process.I totally get that, that we are often doing both circuit design and schematic layout simultaneously. But not always, and this is why I think your blanket statement is wrong (that is, it is not ALWAYS true, even if it is true most of the time): sometimes, you're modifying schematics in ways that aren't really circuit design as such, but certainly aren't mere graphic design, either. For example, changing a pinout on a connector. It's absolutely part of the system engineering, but it's not reeeeeeallly conceptual circuit design as such. Imagine if the change is to a connector with more pins, and you need to insert a new signal somewhere in the middle, so you need to shift the existing ones over by a pin. That really is something where your thought process will be entirely on how to do it in your program, not on circuit design.
While designing the process is not creating schematic file but the actual working circuit. Schematic is just a jolted down notes about it...
So when designing ALL EE think in terms of circuit (in physical sense) and all the idiosyncrasies of tool they use to document it is what they have to suffer on the way. So when drawing circuit the have to "translate" to CAD idiosyncrasies to write it down. Less translation needed, more intuitive and productive tool is.
What did ALL EE think about when designing circuits for years before CAD tools, with pencil and paper?.. You would jolt all kinds of crap on paper in whatever format it was simplest and most logical for you.. Schematic was mostly done later by draftsman based on engineers notes and sketches. Or in a small company or working alone, EE would do combination of notes, sketches and iteratively would eventually make a full schematic in presentable format...
Today all is the same logically. Only pencil and paper are replaced with computer and CAD. It is much easier to draw and edit, tidier, easier to do revisions...
But this is the circuit (schematic) you are designing:
(https://www.eevblog.com/forum/kicad/kicad-gui-is-horrific!/?action=dlattach;attach=1775507;image)
and schematic diagram is only this:
(https://www.eevblog.com/forum/kicad/kicad-gui-is-horrific!/?action=dlattach;attach=1775513;image)
Don't get confused by the fact that in CAD it seems that you are "designing" the second one because it all happens at once..
(a) I fully understand the desire for a set of commands which manipulate the schematic while keeping all connections intact. KiCad has those: You can drag a part or a wire, including rotating and mirroring the part, and keep all connections in place.
Almost, except for the part about "keeping all connections intact". My overarching point is that they
aren't actually "connections" - they just look like connections. If they were real connections you
would not, for example, require a "drag" (which maintains the faux connections) vs. a "move",
which just lets things reveal their true nature and fall apart.
Quote(b) I kind of understand the preference that commands which break connections should not be available at all, or should be well-hidden in a way where you do not use them unintentionally. Kicad does not do that by default, it makes the connection-breaking Move, Rotate etc. commands easily available. But that is a very superficial change which you can make on the user level: Just assign exotic hotkeys (or none at all) to these commands you don't want. And I see the developers' point that other users will have different workflows and styles and want to use these commands regularly.
No, you're imagining something complicated and useless. You have to be able to disconnect with
the same ease and consistency of use as you had when you connected. Nothing hidden, nothing
asymmetric. A "connect" function and a "disconnect" function, both doing exactly that, and retaining
the awareness of what each means, which is actual connectivity vs. faux connectivity.
Quote(c) What I do not understand is your insistence that a "proper internal netlist" representation is the only path to happiness. That seems dogmatic. From a user perspective, why should I care how Kicad works internally -- as long as it offers (a), and for those so inclined enables (b)?
Internally to the software, I couldn't give a single shit in a million years how it's done - or what it's called.
So there's no dogma to be found here, nor for that matter catmas or mousemas. The schematic capture needs
to maintain some kind of internal database in order to keep track of valid connections, otherwise it has no
way of distinguishing the valid connections (the ones you made) from the faux connections and other errors it
needs to bring to your attention.
I'm not going to reply in my usual point-by-point manner to your extremely long, ramblingI think the words you're looking for are "thorough" and "detailed".
and probably stoned posting.That's presumptuous. I actually don't do weed (or any other drugs), though I don't care if others do.
Instead, I'm going to present a single key example illustrating how little attention you've paid to what I've been saying:Oh, I read everything you wrote. That didn't escape me.One solution, which we know the KiCad team expressly does not want, is to have explicit connect/disconnect commands or modes. But my hunch is that you probably don't actually want that, either.
When what I wrote in my immediately-previous post was:QuoteYou have to be able to disconnect with the same ease and consistency of use as you had when you connected.
Nothing hidden, nothing asymmetric. A "connect" function and a "disconnect" function, both doing exactly that, and
retaining the awareness of what each means, which is actual connectivity vs. faux connectivity.
Seems I was pretty clear about the need for both connect and disconnect commands. So instead of "hunching", I
recommend "reading". Your entire reply is based on, and filled with, similarly spurious writing.
Your entire reply is based on, and filled with, similarly spurious writing.It would make sense if you actually climbed off your high horse and read it (like really read it to understand it, not just read it to retort).
To be absolutely clear about my terminology, many respondents who are very familiar with KiCAD have confirmed thatSo the KiCad representative in this thread is wrong?
schematic capture has no internal representation of the netlist. None.
Note that unlike the assumptions made by some in this thread, this does not mean that the schematic editor is unaware of the netlist -- it juts means that the netlist is not a separate "entity" that can be interacted with through explicit connect/disconnect actions.
Just a bag of coordinates that indicate where things are, but not any relationships between them, such as "connection". I have thus employed my own term "fauxIf they're connected on the schematic, then they're connected in the netlist. That's as real as it gets.
connections" for those that appear be connections on the drawing, but really aren't because schematic capture does not understand that concept - in other words, everything on a KiCAD schematic that you call a connection is in fact a faux connection. That's why, when you move a symbol, the wires do not remain connected and rubberband. In order to make that happen, KiCAD has a parlour trick called "drag" which - perversely - brings along all the wires that aren't connected to it.
Where others here (and elsewhere) understand very clearly what I'm talking about, you've employed lengthy sophistryUmm, multiple different people have told you that you are unclear. The fact that multiple different people have used phrases to the effect of "I think you mean...", "I guess you mean...", etc. indicate that you are pervasively bad at articulating your thoughts. The fact that you think you're being clear does not mean you are actually being clear in your communication. It's not helped by your grotesque attitude. You think you're some goddamned prodigy who does no wrong, but you're actually just a conceited, rigid bully who doesn't even feign an attempt to really listen to what others have to say, even those who are trying to understand and help you. And then you lash out at anyone and everyone who doesn't lick your boots.
of very poor quality to convince yourself otherwise.
My point is that what you think you want and what you actually want need not be the same thing! (And this is in NO WAY a criticism, it's actually a really normal human thing!!!)
Thanks for replying! But I still don't get it. It seems to me that you are concerned with the internal data representation, not the user-facing functionality
First, allow me to ask whether you have experience with any other schematic capture packages, or whether
KiCAD is the extent of it. Your answer may give me some context for moving ahead with an explanation
you might find easier to grasp.
Not amateur: I used to work in usability professionally, and that included user observation, requirements engineering, interaction design, etc. At the absolute core of usability is human behavior. And one of the many, many human quirks is that what people think they want is often not really the scratch for their itch. If you give them what they say they want without digging deeper, you can end up investing in a solution that doesn’t actually solve their problem. That’s frustrating for everyone.My point is that what you think you want and what you actually want need not be the same thing! (And this is in NO WAY a criticism, it's actually a really normal human thing!!!)
Honestly, if you stuck to the subject matter rather than playing amateur psychologist,
I just tell you that in order to indicate that my desire for KiCAD to improve is genuine and not a Quixotic crusade.I absolutely believe that. Despite the obnoxious way you go about communicating it, it is very evident that you do care and that it’s coming from a place of positive intent, of a sincere desire to improve the software.
So when I describe the desired behaviour, though I'm describingWell, therein lies the rub: As you absolutely correctly mentioned to ebastler in the next post, the internal representation is closely coupled to the UI, and they have to work in concert.
the steps one goes through in Mentor, I am not insisting that it's a standard that KiCAD
should conform to, but a clear example of the essential functionality - maintenance of the
netlist - that I and many others regard as a requirement for a credible schematic capture
package. The fine details of the UI and the underlying implementation aren't particularly
important, as long as the overall concept is the same. That's all.
I would find it helpful if you could describe which behaviour (or lack of a certain behaviour) in Kicad you find problematic, from the perspective of a user who considers Kicad a black box. Beyond the "undesirable" operations which mess with the connections (Move and its relatives), what is causing you problems? And why would it require different internal data structures to fix these problems, rather than just making these problematic operations unavailable to you?
But to do this, you have to let go of the conceit that you already know the One True Solution. Your wording throughout your participation in this thread has continuously used wording that just oozes overconfidence and/or disdain: “essential” functionality (apparently not, since many EDA programs don’t do it), “parlour trick”, “reveal their true nature and fall apart”, etc.
It could be that there’s a better design that works better than either the current KiCad model or the Mentor model. But you can only figure that out if you give others and yourself the space to explore the interface design. And to do that, you have to dial your ego back a bit and be open to digging deeper into the problem. When people challenge you for more information or clarification, it’s not because they’re attacking you, it’s because they want to get to the root of the problem. You’ve been quite resistant to that, however.
Okay, replying to this posting will be a lot more tolerable than those prior in which you quoted six-deep.How magnanimous of you… 🙄
Do you really expect people to parse all that noise?1. It’s not noise, it’s detailed analysis. Detail takes time and space.
And I really, once again, could do without the extraneous personality (defect) analysis.It’ll stop when you decide to focus only on the content and stop with the jabs and insults and condescension to me and everyone else. But I doubt you will, since you’ve been exuding that arrogance from every pore literally from the very post you ever made on these forums.
You mayhave heard the phrase "Sure, he's an asshole. But he's our asshole." That's my friends describing me, and in case you're finding it hard to parse, it means that as much of a pain in the ass as I am, I'm right more often than not and overall worth putting up with.English is my native language, I have no trouble parsing your sentences when they are cogent, like in this reply.
I've made repeatedly clear that the interaction model I'm citing is simply the example I'm most familiar with that offers anI did. It’s in that “lengthy sophistry of very poor quality” that you dismissed without actually reading it, or if you did read it, that you casually dismissed because it wasn’t the same solution you envision. I don’t know which, since you declined to comment on it other than the snide
effective contrast to KiCAD's failure to do its job. I didn't write it, and I'm not here to champion Mentor as the One True Path
or anything else. But it does illustrate what's required of the job. If you don't agree, why aren't you suggesting a similarly functional alternative rather than arguing here to little or no positive outcome with those who essentially agree with me? Do what you're telling me I should be doing rather than just pointing out what an asshole I am for failing to do it.
I'm not going to reply in my usual point-by-point manner to your extremely long, rambling, and probably stoned posting.
(A whole bunch more stuff that's all about propellerhead rather than the actual subject matter.)
’twas your decision to attack me instead of replying to the on-topic discussion I posted earlier. You could have chosen to engage with the content and maybe say “oh, sorry for being unclear, I simply meant this…” You chose to ignore the content and attack me instead, so that’s on you, dude.(A whole bunch more stuff that's all about propellerhead rather than the actual subject matter.)
So, because I'm here to discuss KiCAD's schematic capture, and not me, I'm really done with you now.
Here some simple testings about the pitta.
Even LTSpice is in this regard miles better while strict .... while KiCad deals with no NETLIST :palm: :palm:
1) Normal 2 resistors connected (BasePicture)
2) Shifted main and lines follow = OK (BasePictureShifted)
3) Mirror Horizontal.... whats on the connected lines ?? (BasePictureHorizontalMirrored)
4) Shifting the mirrored as (BasePictureHorizontalMirroredShifted) :palm: :palm:
The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.
The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.
Currently there is no simple solution on rotating / mirroring nor any blocking(s) on that action, if a circuit has any connection(s).
The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.
Currently there is no simple solution on rotating / mirroring nor any blocking(s) on that action, if a circuit has any connection(s).
You do not really state what you want to achieve. But assuming that you want to mirror or rotate a component which already has connections:
Select the component, enter drag mode (G), then mirror (X/Y) or rotate (R) to taste. Kicad does not seem to support the new "orthogonal" dragging of connections for mirror and rotate operations (why not?!), but it does leave all connections intact, using diagonal lines to show them.
To my knowledge, editing a symbol mid-flight is the only operation where Kicad does not offer any option to do this without changing the schematic connections as a side effect. Since symbol editing is done by a different application, it happens "under the radar" from Eeschema's perspective, and Eeschema cannot keep track of the connections. Hence in this specific case propellerhead's statement seems to be correct that Eeschema would need a different data structure to stay on top of things.
Did the simple test again...
Actions: G hit, mirror, than shifting .. see attached
it gets as this as already posted while after the mirror action the snapping gets into account what results in a mess!!
Did the simple test again...
Actions: G hit, mirror, than shifting .. see attached
it gets as this as already posted while after the mirror action the snapping gets into account what results in a mess!!
Your result is certainly different from the one I get. Did you do the mirror operation while still in drag mode, as I described? The mirror and rotate operations work differently within this mode.
Also, which version of Kicad are you using? I tried 6 and 7, they behave the same in this respect.
Edit: Oh, hang on! I tried this again with a different footprint and surrounding schematic, and did indeed run into problems. Seems I was lucky with the footprints I dragged around before, where I did not run into any "collisions" with the surrounding wiring.
Ok, so this does not always work. And if it goes wrong, the results can be quite messy and confusing indeed...
Did the simple test again...
Actions: G hit, mirror, than shifting .. see attached
it gets as this as already posted while after the mirror action the snapping gets into account what results in a mess!!
Your result is certainly different from the one I get. Did you do the mirror operation while still in drag mode, as I described? The mirror and rotate operations work differently within this mode.
Also, which version of Kicad are you using? I tried 6 and 7, they behave the same in this respect.
Edit: Oh, hang on! I tried this again with a different footprint and surrounding schematic, and did indeed run into problems. Seems I was lucky with the footprints I dragged around before, where I did not run into any "collisions" with the surrounding wiring.
Ok, so this does not always work. And if it goes wrong, the results can be quite messy and confusing indeed...
I don't often remake symbols mid-design in the schematic[1], but where I do that kind of change on the PCB I do tend to disconnect any tracks before the operation. I far prefer a blank space into which I will re-route the tracking than the mess of rubber-banded connections that's just a, well, mess. I think for the schematic, in the example where a pin is moved, I'd just naturally check afterwards that things are as they are meant to be.
1. Thinking back, mid-design symbol changes seem to fall into two camps: small ones (like in the discussion) which I make before connecting stuff because they're tend to be obvious, and big ones where the symbol will be split into two or more smaller parts (or vice verse). In the latter it's just simpler to vape the connections and do them all again.
I don't often remake symbols mid-design in the schematic[1], but where I do that kind of change on the PCB I do tend to disconnect any tracks before the operation. I far prefer a blank space into which I will re-route the tracking than the mess of rubber-banded connections that's just a, well, mess. I think for the schematic, in the example where a pin is moved, I'd just naturally check afterwards that things are as they are meant to be.
1. Thinking back, mid-design symbol changes seem to fall into two camps: small ones (like in the discussion) which I make before connecting stuff because they're tend to be obvious, and big ones where the symbol will be split into two or more smaller parts (or vice verse). In the latter it's just simpler to vape the connections and do them all again.
The in-between case in schematic capture is where I find the greatest value in proper wire-to-pin connections
surviving the symbol edit process: Where you need to make relatively simple changes to a high-pin-count symbol.
I mean, you always do your best to get the symbol right in the first place and visualize the placement and organization
on the sheet, but as the saying goes, "Everyone has a plan until they get hit in the mouth." Once you actually start
drawing it it's not at all uncommon for a completely different organization to reveal to you that it's more readable.
So if I'm bringing a bus or two and a handful of discrete (control) signals off of a CPU or big FPGA or something, and
I find, for example, that I now want to draw the address bus going up the drawing instead of down, the change of
direction for that bus ripper is going to have implications for the drawing of those adjacent signals. So if I open up
the symbol and move that bus 50, 100, 200 thou to make room for routing those other signals, suddenly I've got
32 pins that have changed location. Let's see, now... do I want those pins to rubberband so I can just move the
ripper and line everything up again, or would I prefer that all of those pins are now either dis- or mis-connected?
Arriving at the right answer shouldn't take a lot of cycles.
A workaround for that is to use labels liberally.
A workaround for that is to use labels liberally.
Use of net labels is INSTEAD of schematic connections. It has its use where it makes sense, like power distribution or signal busses...
What I have seen by people where "schematic diagram" has no wires at all but only net labels is not a diagram. That is literally like you would write a netlist manually (like we used to do for SPICE)... You can do that in excel, that is taxative list, not a schematic DIAGRAM.
A workaround for that is to use labels liberally.
Use of net labels is INSTEAD of schematic connections. It has its use where it makes sense, like power distribution or signal busses...
What I have seen by people where "schematic diagram" has no wires at all but only net labels is not a diagram. That is literally like you would write a netlist manually (like we used to do for SPICE)... You can do that in excel, that is taxative list, not a schematic DIAGRAM.
As a Kicad user I am interested in this discussion and find it (apart from the incidental throat-ripping) quite enlightening. The way I use Kicad (and used Eagle before that) is that I make use of labels extensively. I only use wires in isolated parts of the schematic. These connect to the rest using labels. CPU's and the like only have labels. The same labels I use when designing the firmware and naming pins. That might be like writing a netlist manually but I find that the mixing of labels and actual wires on a diagram gives me a very good overview of what I am trying to achieve when I draw a schematic. Much better that having wired connections all over the place. Detail where I need it and helicopter view where I don't. Mind, I'm not designing the next i9 motherboard, so maybe that is why this works for me.
And AFAIK I never ran into the problems described. If I move, rotate or mirror a component I never use rubberbanding. Just delete connections and rewire. if I change pins around on a symbol in a library I delete it in the schematic, replace and rewire it. I never ended up with unwanted connections.
But is nice to read how other EDA software tackles problems that I did not knew existed :)
Use of net labels is INSTEAD of schematic connections. It has its use where it makes sense, like power distribution or signal busses...
What I have seen by people where "schematic diagram" has no wires at all but only net labels is not a diagram. That is literally like you would write a netlist manually (like we used to do for SPICE)... You can do that in excel, that is taxative list, not a schematic DIAGRAM.
And AFAIK I never ran into the problems described. If I move, rotate or mirror a component I never use rubberbanding. Just delete connections and rewire. if I change pins around on a symbol in a library I delete it in the schematic, replace and rewire it. I never ended up with unwanted connections.
But it is nice to read how other EDA software tackles problems that I did not know existed :)
The "A"s in CAD and EDA stand for "assist[ance]"
Software that assists and automates would not make you do all that deleting, replacing, and
rewiring.
QuoteThe "A"s in CAD and EDA stand for "assist[ance]"
Actually "aided". Essentially the same meaning, but helps your argument to not have obvious faults in it
QuoteSoftware that assists and automates would not make you do all that deleting, replacing, and
rewiring.
I question this. Sure, the ideal is that the tool does everything for you, but even if it just acted as a simple drawing package it would be CAD since it aids in drawing. There is an expectation that some minimum level of automation would be appropriate for an electronics design tool, but that level can be a relatively low bar. I would suggest that assuming 'CAD' means 'all singing, all dancing' is seeing things that won't necessarily be there.
Over the years "aided" and "assisted" have been used interchangeably, so it's not really a distinction worth pointing out.
Over the years "aided" and "assisted" have been used interchangeably, so it's not really a distinction worth pointing out.
Yes, I am sure they have been used interchangeably. It just has not happened all that often. ::)
Those wacky krauts have a word for everything!
You've been conditioned to accept substandard tools.
Demand^H^H^H^H^H^HExpect better.
As other have noted: Altium's schematics capture isn't better in any way compared to Kicad. For starters: try to get rid of Altium's default Times font they use for pins and labels. Times is by far the worst font for that purpose if you want to print readable schematics and Altium makes it nearly impossible to change it :palm:While it is a bit of a pain to eliminate Times New Roman (mostly in that there are a LOT of defaults you need to change once, and then setting the document font once), once you’ve done it, it’s more or less gone.
As other have noted: Altium's schematics capture isn't better in any way compared to Kicad. For starters: try to get rid of Altium's default Times font they use for pins and labels. Times is by far the worst font for that purpose if you want to print readable schematics and Altium makes it nearly impossible to change it :palm:While it is a bit of a pain to eliminate Times New Roman (mostly in that there are a LOT of defaults you need to change once, and then setting the document font once), once you’ve done it, it’s more or less gone.
BTW...These things don't bother me. I have zero tolerance.
Those who (like me sometimes) have difficulties distinguishing an O for an 0 could try using "Andale Dot" font.
In that font, the number 0, zero is represented with a dot in the center of the oval...
8)
new kicad user here.
tried to place a resistor, a cell, a switch and connect them with wires. then tried to figure out how to run simulation. 15 wasted minutes later: apt-get purge 'kicad*', back to (pirated) proteus under wine. works like a charm!
this thing was most definitely created by a brain-damaged person, and, unlike the case of vim and TeX, there is no positive connotation in that.
new kicad user here.
tried to place a resistor, a cell, a switch and connect them with wires. then tried to figure out how to run simulation. 15 wasted minutes later: apt-get purge 'kicad*', back to (pirated) proteus under wine. works like a charm!
this thing was most definitely created by a brain-damaged person, and, unlike the case of vim and TeX, there is no positive connotation in that.
You spent only 15 minutes trying to learn to use a complex piece of software and then decided there's a problem with the software and dumped it?yes, that's precisely what happened.
Try to learn to use Solidworks or Photoshop or Blender or any other similarly complex software in such a short time and you'd have the same problem.good point!
For those of us that even occasionally use the software for paid jobs pirated tools are not an option.good point too, but my case is occasional hobby usage. yes I'd much prefer not to use a pirated copy. I'd even buy it if it had a hobbyist license for a reasonable price, say, $50 or $100, and I'd do it even more willingly if it had a native linux build. but starting at $7k? really? are you kidding me? don't be surprised that your software is pirated.
why doesn't kicad have this very obviously necessary feature? I don't know.
Because you haven't written it yet.and I never will, because of the amount of effort it requires to get started and do simple things. it fails to get new users quickly addicted to it, thus losing potential future contributors.
yes, that's precisely what happened.
complex software does not have to be horribly difficult to get started with. besides, there is nothing complex in drawing a very basic circuit.
for comparison, i needed literally 5 minutes to get started with proteus: its UI follows the industry standard principles of user interaction and has no apparent goal of preventing the user from using it intuitively, which makes it easy to get started with, but, at the same time, not less powerful when it comes to more complex tasks.
obviously, considerable effort of a team of professionals in the respective area was put into getting it right.
and I never will, because of the amount of effort it requires to get started and do simple things. it fails to get new users quickly addicted to it, thus losing potential future contributors.
this is, unfortunately, a fundamental problem of many FOSS projects.
this is, unfortunately, a fundamental problem of many FOSS projects.
They don't want you as a contributor anyway.... It's also not useful to have somebody just complaining about something but refusing to do anything to improve it. It's pretty obvious that you just came here to complain.
This statement is about eight kinds of wrong, beginning with being predicated on a false equivalency: That
being an expert user somehow equates with being an expert - or even a merely competent - programmer.
Don't make me go on.
Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once.
why is it not at all unexpected to receive personal attacks in response to criticism about the obviously flawed UI of a product that badly needs attention of a proper UI/UX professional? it should also be noted that I am not alone in this.
no, sorry, gentlemen, when the software product is well designed, it does not require new users, who already have significant experience with other similar products and with computer systems in general, to invest any considerable effort into learning and forcing themselves to change their habits developed over decades of using products that follow the UI/UX practices that are considered standard in the industry.
if it does that, then the problem is in the software, not in new users trying to get started. the fact that it is free and/or open source does not cancel the fact that the user experience it provides is poor.
of course, I cannot demand that a FOSS product absolutely must have a professionally designed UI or anything else, and, for those who haven't noticed, I don't do it. I merely state that this product, unlike some, if not many, others fails to provide an easy start for new users, and for some users, who have alternatives, it is a sufficient reason to dump this product altogether.
p.s. w/r/t "stealing" software. this is an incorrect term. it's not stealing, because stealing makes someone lose something that they own, which is not the case with pirated software: if someone makes a copy, the original does not disappear.
it's not even lost profit, because, in my case, I wouldn't pay for this software anyway: at this ridiculous price point, it's either pirated or nothing, and it brings up an interesting question of what of these two choices is actually more useful for its maker (remember how pirating windows 95 actually helped it to gain enormous popularity and finish off the competitor).
Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once.
I don't understand. Can you explain that, svp?
You have very odd idea about theft. If you don't buy a ticket for the subway and use it nevertheless, on the argument that it's too expensive, maybe that is not technically "theft", but it's not legal, either.
What I find puzzling about it is how, despite having some fairly advanced features, in other areas it’s astoundingly basic. I’m a proficient Altium user, and whenever I need to work in KiCad, I get irritated at things that aren’t there (like really good alignment/snap tools). I’m sure that some things are simply it not being what I’m used to, but others really aren’t there. Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once. That’s something so fundamental I am flabbergasted it can’t do it. (And yes, I’ve verified that it really can’t.)
Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once.
I don't understand. Can you explain that, svp?
Assign same value/constraint/field to multiple objects, last i've checked they have promised it's in the works because for now the solution is "just write a python script to do that"
Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once.
I don't understand. Can you explain that, svp?
Assign same value/constraint/field to multiple objects, last i've checked they have promised it's in the works because for now the solution is "just write a python script to do that"
But it's been a while since i used any PCB cad, too many programming jobs lately :(
You can also edit the color/style of multiple wires at once in eeschema.
You can also edit the color/style of multiple wires at once in eeschema.
Oh. So this is what they consider important in schematic capture. Bitch, pleez...
Absolutely right, so don't try to make it about me.
Schematic:Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once.
I don't understand. Can you explain that, svp?
Perhaps you're not familiar with it - it's a specific cultural reference.The fact that you chose that specific way of being flippantly dismissive doesn’t change the fact that you were flippantly dismissive. That’s what people were responding to, not the specific words used to do so.
https://youtu.be/EWVGJg-7jLQ
The fact that you chose that specific way of being flippantly dismissive doesn’t change the fact that you were flippantly dismissive. That’s what people were responding to, not the specific words used to do so.
P.S. The phrase “bitch, please” predates the SNL skit by decades. As I gay man myself, I assure you, we were saying it loooong before!
I didn’t respond to it. I only explained why others responded.The fact that you chose that specific way of being flippantly dismissive doesn’t change the fact that you were flippantly dismissive. That’s what people were responding to, not the specific words used to do so.
Of course it was flip. And you're so easily trolled by it...
I didn’t respond to it. I only explained why others responded.
With that said, if you’re admitting to trolling: just knock it off and don’t waste people’s time with that. It doesn’t improve your reputation…
I didn’t respond to it. I only explained why others responded.The fact that you chose that specific way of being flippantly dismissive doesn’t change the fact that you were flippantly dismissive. That’s what people were responding to, not the specific words used to do so.
Of course it was flip. And you're so easily trolled by it...
With that said, if you’re admitting to trolling: just knock it off and don’t waste people’s time with that. It doesn’t improve your reputation…
@propellerhead: If you want to be flippant, go for it, just don't expect people to value your opinion as much as they otherwise might. The fact that you delight in having "easily trolled" someone with your behaviour does, by the way, not make it better.
Maybe you could help me understand the specific cultural reference behind your "propellerhead" moniker? I understand it has something to do with smarts, but is there also a hint at social ineptitude?
No, it’s a big difference.I didn’t respond to it. I only explained why others responded.
So you're metaresponding. The difference is insignificant.
If you want discussions “of substance”, then you need to stick to the substance and leave the trolling, arrogance, and unfunny “jokes” at the door. You reap what you sow. You forfeit the right to complain about being off-topic when you’re the one who takes it there!QuoteWith that said, if you’re admitting to trolling: just knock it off and don’t waste people’s time with that. It doesn’t improve your reputation…
And we were doing so well discussing matters of substance.
Don't get your knickers in a twist just because I refuse to use those idiotic emojis.Stop lying. I didn’t say anything about emoji use.
Oh. My. God. You're exhausting. Talk about strangling all the fun out of harmless banter.Your “harmless banter” is just idiotic annoyance.
You may be further out on the spectrum than you think.Given that I have said nothing about where on the spectrum I might land, you have zero right (or point of reference) to make any claims about it. (Unlike me debunking your explicit claims of having intellect so superior that it supposedly makes up for your rotten personality.)
Perhaps you're not familiar with it - it's a specific cultural reference.
https://youtu.be/EWVGJg-7jLQ
Given that I have said nothing about where on the spectrum I might land, you have zero right (or point of reference) to make any claims about it. (Unlike me debunking your explicit claims of having intellect so superior that it supposedly makes up for your rotten personality.)
Not only that. A feature I use often in Orcad is a table view (called part manager) with all the components which can be sorted in various ways. When sorted by value it is super handy to do part value optimisations. For example: if there are 2 3k9 resistors to set a divider and 10 4k7 resistors used for logic pull-ups, it makes sense to change the pull-ups to 3k9 as well. And the same for component sizes. Sometimes I copy parts of a schematic as well but some designs are 0402 and others are 0603. The part manager is a huge help to get a good overview. WIth the component database behind it, the component changes not only change the footprint but everything that is needed to create a correct bill of materials. Schematic entry is not just about creating a netlist but it also plays a huge role in the logistics side of having boards produced.Schematic:Something I use all the time in Altium that KiCad can’t do is editing multiple objects at once.
I don't understand. Can you explain that, svp?
Suppose the boss has said to change all the resistors from 0805 to 0603. I can do a Find to find and select all the 0805 resistors, then use the Properties to assign the 0603 footprint to all of them, all the while all their other properties remain unchanged.
Or maybe I need to change an IC from one type to another, for example the old 7805 to a more modern LM1117-style LDO. I can prepare a schematic symbol with the same layout, then select all my 7805’s and replace the symbol with the LM1117.
Not only that. A feature I use often in Orcad is a table view (called part manager) with all the components which can be sorted in various ways. When sorted by value it is super handy to do part value optimisations. For example: if there are 2 3k9 resistors to set a divider and 10 4k7 resistors used for logic pull-ups, it makes sense to change the pull-ups to 3k9 as well. And the same for component sizes. Sometimes I copy parts of a schematic as well but some designs are 0402 and others are 0603. The part manager is a huge help to get a good overview. WIth the component database behind it, the component changes not only change the footprint but everything that is needed to create a correct bill of materials. Schematic entry is not just about creating a netlist but it also plays a huge role in the logistics side of having boards produced.
Coincidentally, KiCad has a functionality quite similar to what you describe as a "part manager". It's a table view of all components in the schematic, with entry grouping for various attributes. Huge help in consolidating BOM lines. Also makes it easy to change e.g. all footprints of all 100n capacitors in the design etc.
One thing that has bitten me in the ass is that duplicating a symbol in schematic copies ALL attributes, including the "exclude from BOM" one.
No need to say that the duplicated symbol in question was not meant to be excluded from BOM.
That wouldn't have been a problem if there was a clear indication of a symbol not being in BOM, either on the schematic itself or in the symbol fields table. It's on neither.