(This is the continuation of a “take pity on a n00b” thread that I started under Schematic/Symbols,
but it really does need a fresh thread.)
So I’m getting going on my schematic entry, nothing exotic, just a bucket of SSI and MSI TTL.
I’m still getting used to the UI drawing logic, but it’s okay. I have a few gates wired using the
default snap V/H setting, which is fine. But when I pick up a symbol (or symbols) and the wires
outside of the move block rubberband, they don’t snap orthogonally when I complete they move -
they’re left at odd angles - and I don’t know how to return them to orthogonal. In Mentor I’d
simply set my select filter to vertices and move them back into place manually, or select the wire
or net and tell it to autoroute it, which again will return them to orthogonal. But I can’t see how
to square them back up in here.
And I’ve already run into something that looks like a real problem. In the course of one of these
moves, a vertex landed on a line. Now, what I’m used to in this case is an error (a warning flag,
actually), because the vertex is now in contact with a wire from a different net. But KiCAD
instead joined the two, even adding the dot! This is way wrong. It’s a recipe for completely
messing up a schematic in the normal course of moving stuff around.
This happens if a wire is moved on top of a symbol pin. It also happens if two perpendicular wires form a T-junction. This should not happen if two wires only cross. Whether KiCad should join the nets can be discussed, by I wouldn’t say it’s an error. It doesn’t make sense to form a T-junction if you don’t want to join the wires. I understand it’s easy to do this accidentally if there are many wires moved, but still.
One way to protect yourself is to give explicit names for nets from the beginning. V6.99 gives a warning if there are competing net names at the same level.
I’m with @via here.
Both 5.1 and 6.0 have a very nasty habit of dropping unwanted dots on connection crossings in a random way. You have to meticulously proof-read schematics before release. Wastes a lot of time.
Well, doesn’t KiCAD assign default names to the nets as the schematic is laid down? If it’s
done that way (rather than just treating the connections as meaningless lines that can be
joined to each other at will), schematic entry should bark about two nets being merged and
ask whether that’s really what you want to do - without your having to waste a lot of time
naming every net as you go to prevent getting screwed later.
That addresses my second question, but not the first: How do I restore lines that have
rubberbanded to odd angles to orthogonal?
Yes, but they are semantically meaningless and can change according to some internal rules. If you don’t give an explicit name, you imply that you don’t care. And it would be impossible to do productive work if KiCad would complain every time you connect previously unconnected nets (say, starting from one pin, then stopping but continuing from another pin and finally reaching the first wire). If you name nets explicitly before connecting them, KiCad can deduct there may be something wrong, although at the moment it only warns about it when doing the ERC check.
I know, and generally don’t complain, but rather try to help where I can.
I worked with @jmk on one of the latest FAQs and just posted one myself.
Please don’t push me into the “freebie-whiner” corner.
Expected release for 7 (Currently the 6.99 testing) is by the end of Jan 23 so pretty soon.
So what happens when 7 comes out and nobody has been in the market as a Guinea pig? - that’s when a pile of bugs get posted along with a refrain of KiCad isn’t really ready for the mainstream. You can install the two versions alongside each other. Nobody is asking you to use 6.99 in a production environment but a bit of quid pro quo testing in exchange for free software doesn’t seem too much of an imposition.
[quote=“eelik, post:7, topic:39217, full:true”]
Yes, but they are semantically meaningless and can change according to some internal rules. If you don’t give an explicit name, you imply that you don’t care.[/quote]
That’s a pair of terrible behaviours. What’s the point of assigning a “semantically meaningless”
net name that “can change” arbitrarily? Assign it a name that means “this is this net’s name”,
take that name seriously, and don’t screw with it. If the user wants to change its name later to
something specific, let him. If I don’t give it a name, I imply that I don’t care what its name is, not that I don’t want it treated it like the net I drew.
You’re basing your argument on an extreme interpretation in which every pin is a net, even if
it’s not connected to anything. If that made sense, your argument would, but it doesn’t. What
you need to do is just treat nets like nets i.e. an unconnected device pin isn’t assigned a net
and remains available for connection to any net the user chooses, at which point it becomes
part of that net.
Well, that’s logic that I can buy into if I try - not allowing the user to just pile a bunch of wires all
over the drawing that aren’t connected to anything and then try to assign net names to them.
That’s a reasonable constraint, though you then have to address the case in which lines that
were connected to things (and which constituted valid nets) are later orphaned in the editing
process. There are obviously a few different ways to treat that. But I could just as easily offer
a counterargument that says I should be free to draw complex buses all over the place, assign
net names to them, then connect them to components later. One should allow the draughtsman
the freedom to draw in whichever style and order he prefers.
Is 6.99 file format compatible with other versions? That is, if you ever save with 6.99, do you loose your files?
Edit: Sorry my extreme words, but previous version did that. (Backup helped.)
Okay, so I’ll accept that this (giving all pins net names) is an architectural necessity. How
is the connection of nets managed? If one starts drawing a wire other than at a pin, is it
given a net name? If not, does it get the pin’s name when it’s connected to a pin? Or, if
so, when the two nets are merged at time of connection, which name wins?
As for the original problems, I’m not arguing that what KiCad does is necessarily the best possible behavior. Some of it has good reasons, but it doesn’t mean it can’t be better. Write a concrete detailed description about non-wanted and wanted behavior with an example file and steps to reproduce the problem, and it can be considered by the development team.
I appreciate the qualification; this may be a case of people just having learned to put up
with, through the course of development, behaviour that absolutely would not be tolerated
in mature commercial software. But this is a very serious fault that dramatically reduces
the trust one can place in the tools.
The problem is simple: Do not merge nets without warning the user. For the purposes
of this rule, a single-pin net doesn’t count.
