Is there a way to name nets in eeschema without putting a local label on each one? Putting one one on every wire of a large schematic seems really messy, and inconvenient, but without names, it’s difficult to assign all of the nets to their respective classes.
Is there a non-obvious alternative that I’m missing?
2 Likes
There doesn’t seem to be a visibility toggle. I just tried in
Application: kicad
Version: (5.0.0-rc2-dev-45-ge3c71efbe), release build
and it allowed me to set a zero size for the text.
All nets have names. When assigning classes, do you have the filter set to suppress the auto-generated names?
No, they have the automatic names, it’s just very tedious lo go through hundreds of nets to match up the numbers to sort them into their classes, and it’s tedious and messy sticking labels to every wire, with the added possibility of moved parts ending up dropped onto the wrong labels, etc.
OK. I’m not sure that I know of a better way. Do you have any suggestions?
I don’t understand what you need.
Does it looks messy, or is the process of doing it messy? What “inconvenient” means?
If there are hundreds of nets it’s tedious anyways, but they would be easier to sort if they would have descriptive names.
Again, does “messy” mean “it looks messy when there are labels”? But “tedious” - I understand it as being tedious to click on each wire and write the names, am I correct? If so, what could be an alternative? Some magic which attaches the names you want without you needing to tell what they are are and to which nets to attach them?
It looks messy, because there’s no way I can see to have a net named, without that name always displayed, though that isn’t a really big deal. The bigger issue is that if you drag a part with g, its labels get left behind, and in some cases could end up attached to the wrong net. If you don’t notice this when it happens, this could lead to nets being disconnected or bridged on the pcb.
It would make more sense to me if you could edit a net name by clicking its wire, and the label tag would simply display the name of whatever net it is attached to.
Alternatively, if the wires would stretch from net labels when moving parts, that would at least prevent accidental connections, even if things still look a little cluttered.
After messing with it a bit more, I think my last suggestion would probably be the best way to fix it.
I can deal with the clutter, and I am coming to appreciate how much easier the current method makes pin swaps, etc, as compared to something like diptrace, where it’s a bit more of a hassle to split a net once you’ve joined them by name.
It would still be nice if when moving a part with G, the traces wouldn’t detach from their labels. (and by extension, any nets that have been joined by name)
The current system where the net name is attached as an external object to some coordinate point on a net segment isn’t very good IMO. Instead, the net name should be a property of the net, like reference is part of a footprint, regardless of where it’s located. The biggest difficulty in the current system, as far as I can see, is that if a line is not exactly horizontal or vertical, it’s doesn’t necessarily hit any point in the grid at all except in the two end points. Then the net name can’t be attached to it unless it’s moved far from the original relative location. As far as the whole concept is as it is, it can’t be fixed easily. Hopefully this will be changed when the schematic engine (view and toolset) is rewritten for the version 6 (within couple of years). You can of course file a wishlist bug report.
My first instinct was the same. with the external object being bad, but I can kind of see some benefit, too. Accidental disconnects requiring me to rip up and redraw traces was annoying, while in diptrace(which I have more experience with), the nets retain their names forever. On the flip side, in diptrace if you need to split a net that was previously joined, you need to delete the wire at the first segment at the footprint, which can be a bit of a hassle as well. (by default, changing the net name at any point will rename the whole net)
With the current system in kicad, a pin swap is much easier. You can just drag the labels around to their right sides. I think it’s a “6 in one, half a dozen in the other” scenario… Another option might be to give a checkbox to only rename directly connected wires, or something like that.
I think a simpler solution in the shorter term might be to convert “G” moves so the traces get drawn out as a combination of orthogonal traces. I mean, really, who draws a schematic with random angle lines anyway? That would probably make the issue with accidental connections worse, since currently it’ll mostly happen only on horizontal or vertical moves (because of the angle thing you’re talking about), and with it drawing out an L shape for a diagonal move, it would intersect random net labels much more often.
But, if the first change was to make the wires snap from the label instead of the other footprint, That should fix the accidental wires disconnecting/reconnecting, and then switching to pulling orthogonal (L) lines should be relatively safe. Assuming that dragging traces could be made to follow similar rules, and not make funny angles, it would probably be not too much trouble to just drag your traces back in line to detangle them after a footprint move.
Maybe it would be a decent band-aid fix in the mean time that would make things a bit more manageable without needing a lot of re-write?
A different approach:
KiCad-eeschema reference manual Chapter 14 “Creating Custimized Netlists and BOM Files” may be a nice entry point to attach a custom exporter or script to rename nets or directly assign them to net classes from a table. I never used it, but apparently you can use an XSLT file to describe the output format of the netlist you want.
Or do it in several steps. Create a list of all net names, put them in a spreadsheet and assign net classes there. Then run a script in PCBnew or an exteral script for integrating / translating the spreadsheet table into the PCB.
I may be missing here, but the manual assingment of hundredths of net names seems a bit weird to me.
Normally I have a handfull of named net’s for some net classes, GND, Vcc and some other high current traces. All the rest is moot, and gobbled up by a single net class with the same thin traces.
Here you are talking about pin swaps, but why would a pin swap change anything about the net routing classes?
Could it be that you are trying to duplicate the workflow you got used to in Diptrace, while adapting another workflow that fits better with KiCad could be more appropriate here?
I think that with the net renaming, we could be focussing too deeply on a to small part of the problem.
Another aproach could be to make good use of the auto generated net names.
I’m having an @#$%^& problem with PCBnew at the moment and unfortunately I can’t run it at the moment for some experiments.
It’s not only the netlist that needs the nets named, though. The schematic does as well, because one of the primary reasons for naming them is to join them without a rat’s nest of lines.
In the particular case I’m working on right now, for example, I’m using some sdram. On a 32 bit memory with proper termination that’s around 100 nets per chip. No sane person is going to draw that out with individual traces, so the only other way is to join them by name, which means naming a lot of nets. The current system in kicad isn’t all that bad, really, and the insert key auto-increment is an awesome time saver.
The thing that sucks, is that if I move a chip, all of those labels get disconnected, and all of the lines are angled, so the labels can’t usually be attached again. At that point, I have to delete all of those angled lines, redraw them orthogonal, and then drag the names back onto the correct wires. Worse yet, is that if the move of the chip is orthogonal, you can end up with different wires dropping onto the labels.
Treating the labels like any other footprint that’s not being moved would mostly solve that. The lines would instead snap from the label to the part you’re moving, and stay attached. Then you could “g” on the label to square things up however you want them.
Another example where this can go very bad, is if you accidentally bump the y key when your cursor is over a IC with a symmetric symbol, and it gets flipped and just connects like nothing happened. I mean, you’ll probably notice during routing, but it’s still kind of scary.
Maybe you shouldn’t even be able to do any move/flip/rotation without either having traces stay connected, or by doing a “disconnect all pins” first?
As far as using auto-generated names goes: It’s often good to know what you’re routing when you’re on the PCB so you don’t route high impedance analog traces along clock lines or noisy planes, etc. On a simple board, this stuff will probably be more obvious, but on a fairly dense board that has switching regs, memory buses, and analog signals in the same place, it’s not hard to accidentally route something badly.
I don’t know where you got the idea that I’m trying to duplicate the diptrace workflow. I just used it as a comparison, where I said that one part was easier, but the other harder. shrug I think it’s probably valuable to make such comparisons, just to see when someone else might have come up with a better solution to a problem, or on the contrary when they’ve tried an idea and it’s gone badly, so you don’t repeat their mistakes.
1 Like
You probably worked with “m” = move, and “g” = grab, but for this it is much more convenient to use a block move.
Just press down [LMB] and drag a rectangular window around your component and labels. Connected wires wil also simply move with the block without getting distorted.
When working with lots of parallel wires (DRAM address bus to blue databus for example) you can also make easy use of the block functions to copy 4 wires into 8 wires, copy 8 wires into 16 wires. ( Press [RMB] for context menu while a block is selected) And of course, if you put a wire junction on the first few wires, they will get copied along.
Changing the length of a bunch of those wires (for example to make more room for labels) can be easily done by placing a connector (or a copy of your dram chip) on the wire end and then “Grab” the connector and all the wires will change length with the movement of the connector. Delete connector when done.
If some wires end gets slanted accidentally you can “g” on the wire end and move the end (or a junction of wires) to set it straight again.
With the “intemediate connector”, you can "g"rab some slanted wires, Then pick up some more stranded wires, and repeat that a few times untill all loose wires have been picked up by the “intermediate connector”.
It is a sort of equivalent of the multiple cursor typing in some text editors.
Edit:
I was just reading KiCad’s Reference manual because I forgot how the repetition command [Inert] worked. Turns out you can also use the [insert] key to add wires to your schematic. Works very fast, faster than the copy method.
Such a symbol would have to be 100% symmetrical for this to not get noticed. Especially if you use the Electrical Rules Check. DRAM chips and such have enable and other lines which will get torn loose. This is btw also a good argument to keep signal flow from left to right (as per usual convention).
Maybe you should not press keys when you don’t want to?
But I’m the kind of person that gets annoyed by a " Save: yes/no? " dialog when I close my bloody text edtior.
I probably had a brainfart about the diptrace workflow, forget that.
So to recuperate: You wanted to connect hundreds of wires on a schematic by labels, without those labels being visible? Sounds like a very bad idea to me.
A row of labels like:
A0
A1
A2
A3
A4
next to a chip is easily verifiable, even when the thing is printed on paper or exported as pdf or whatever.
With the block copy you can easily move blocks without risk of the wires & labels getting tangled and that seemed to be the main problem for you.
And even if you mess it up completely, deleting and redrawing the labels for a 32 bit databus is done in a few seconds with the [Insert] increment function.
Forget the original post. The extra clutter on the schematic isn’t really a big issue, so much as all the stuff we’ve discussed since, regarding the way labels are basically ignored by g, and how moves can silently cause dis/misconnections.
I know how to work around all of these issues that I’m discussing, but that doesn’t mean that there’s not things which could be fixed to make it a lot more beginner friendly with near zero cost to power users.
IMO, it’s not a question of whether DRC, or the likelyhood of patterns being asymmetric will catch your errors. The question is how often you legitimately want to rotate/flip/move a pattern and connect traces in an offset way. The answer is probably never, with the exception of maybe flipping a polarized cap or diode that you realize is backward. (in which case you’re punished by needing to select “disconnect wires” before you do the flip) It’s like wearing a seatbelt. 99.9% of the time it doesn’t matter, but the cost of wearing one is so minimal that you may as well do it to catch the odd corner case where it might matter.
I like the very simple and straightforward way the rotation and flipping works.
You press “x” or “y”, and a symbol flips. KiCad simply does exactly what you tell it to do.
You can also easily flip blocks of auto numbered labels if an address / data bus is numbered from the bottom up.
With the block move there is also no chance of the labels getting mis/disconnected.
What you call “extra clutter” I call an “essential necessity”.
Labeling all wires for address / data busses etc has been the standard way for 40+ years.
How else would you see where your wires are connected to (on a pdf of printout)?
I also very much like the very simple interface with which the labels work.
It makes it easy to copy blocks of labels or blocks of wired labels with a few key strokes.
No distractions from complicated “user friendly” algorithms which are only convenient 80% of the time.
And workarounds for the other 20% cost more time than the “convenience” has saved in the first place.
Just simple and straightforward.
The only “downside” I see is that labels are not connected to slanted wires. But I never use slanted wires anyway because they gett too messy too easily.
If you drag a box around a bunch of endpoints of slanted wires with the mouse and then hitting [Tab] you can easily straighten them. If you draw the box around the labels, they move with the box.
I really do not see much use in making this more complicated.
A possible alternative for you:
Some time ago I saw some scripts for KiCad (probably a python library) to help with designing netlists in code.
The demonstration looked pretty intuitive for combining pins from chips with labels into nets, but I do not draw enough (complicated) schematics to justify the time investment to learn to use it properly.
still doesn’t answer the question of how often you want to move a part and automatically connect pins where it lands.
I’m not saying you can’t get used to it and work around the issues, because obviously that’s what we all do, but you need to think about whether all these automatic subconscious workarounds are adding a lot of extra clicks that might outbalance the penalty of any noob friendly safeties.
If you move a wire, the label detaches? I think if you instead move the label, the wire follows.
If you “g-key” a footprint, the wires will follow the part, but they ignore the existence of any attached labels and snap directly. It would be more consistent with the rest of the interface if they were treated like any other part’s pins, and snap from the label to the new pin location, as opposed to directly, ignoring the labels (and leaving you with a non-grid aligned trace that you can’t join the label to), pretty much requiring you to delete/redraw the trace.
My answer is: Always. That is because I only flip / rotate the part when I want it to. flip / rotate.
Exactly because it is so very easy to attach / detach wires from components makes a lot of editing of schematics simple, intuitive and straigtforward.
If you can’t keep your hands of the keyboard you can re-assign the “x” shortcut to [ctrl+alt+delete+x] or disable the shortcut so you can only flip / rotate with mouseclicks from a menu.
It depends on how you move the wire. If you move wires without moving the labels, then the labels simply stay where they are. if you block move wires you can easily choose if you also want to move the wires with the block or not.
@nickw:
I’m getting confused here It seems you are telling a a bunch of contradictory things. then “Forget the original post.” You say: “extra clutter” which I deem “essential information”.
All the slanted lines if you move a single component diagonally will detach the labels (Unless the attachment point of the labels is exactly on the endpoint of the wire! Have you tried that?).
But I can not believe you want all those slanted wires in your schematic anyway.
So simply do not move your components in this way (Or undo with [Ctrl+Z] if you did by accident).
"g"rab of a single component is only usefull for straight horizontal or vertical movements.
I have not gotten a single word of feedback about the block move, which can easily avoid most part of your “problems” with detached labels. It really seems to me that you sould experiment more with the multiple ways you can create and move / copy blocks.
You seem fixed on the single idea of having invisible wire labels which stay fixed on the wire.
I hope this feature never makes it into KiCad. I want to be able to see my wire labels. Everywhere! Always!
It’s simple and effective.
These invisible wire labels are also incompatible with KiCad. It is now very easy to copy a whole bunch of wires from the address bus of your SDram to the Databus of the SDram. If invisible wire labels are copied implicitly with it then that opens up a bunch of cans with wormholes.
The simplicity with wich it works now is one of the charms of KiCad.
I like it very much that you can "m"ove a component to a bunch of loose wires and then "g"rab the component and drag / stretch the wire endpoints along.
I do not see why these “invisible wire labels” would make anything
I also get 0.0 feedback about the library of writing the schematic in code instead of with KiCad, which might wel be worth it for you. You can generate your netlists from simple text files, which seem to me a good alternative for schematics which mosty consist of big data & address busses. But you probably have not even condidered this for >2s. The project seems to be SKiDL: https://forum.kicad.info/t/skidl-a-python-based-schematic-design-language/3743/4
When re-reading your posts I found this argument:
This is a bad idea. Having to click hundreds of wires one by one just to be able to see their net names and check if the net name is still compatible with the pin that the wire is connected to is a tedious job.
It is simply not compatibley with the easy and intuitive way you can move wires and components around in KiCad.
In my opinion the KiCad design team is doing an excellent job in making great software and this whole “problem” is so trivial that it is not worth much development effort.
I think that we can agree that we disagree here, and I think I am done with this conversation.