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.IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:
- 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.I'm fully aware of those issues, and understood that.
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".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.IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:
- 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.I'm fully aware of those issues, and understood that.
That doesn't change the fact that in graphical schematic capture software, the graphical representation is how we convey our intent to the software.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).
No electrical engineer thinks in terms of "connectivity by moving things around".
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....
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.
Other stuff is only how it looks and consequently how nice is to read.
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...
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.
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....
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.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!).
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.
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"..
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.
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:
and schematic diagram is only this:
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, rambling
and probably stoned posting.
Instead, I'm going to present a single key example illustrating how little attention you've paid to what I've been saying: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.
To be absolutely clear about my terminology, many respondents who are very familiar with KiCAD have confirmed that
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 "faux
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 sophistry
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.
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.
So when I describe the desired behaviour, though I'm describing
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.
Do you really expect people to parse all that noise?
And I really, once again, could do without the extraneous personality (defect) analysis.
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.
I've made repeatedly clear that the interaction model I'm citing is simply the example I'm most familiar with that offers an
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.)
(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
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)
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.