We don’t understand each other. I can’t get sense from this what you said.
“taking care if a pad is routed” What is taking care, and how it takes care? What does it mean that “pad is routed”?
“or is part of the ratsnet” What do you mean by that? A pad is not a part of a ratsnest. A ratsnest is a bunch of graphical lines, showing some guess for how two split parts of a nest could be connected. Or rather, the lines show only that there are split parts, because it can’t really guess how the parts could be connected, only that they need connecting.
I’m not sure if I understand this, either. I suppose that the “forest of trees” refers to the “netlist” which can have one or more net items.
As far as KiCad, PCB and logic goes, each net item can be split into several subitems, namely split parts of the net. Each part then has one or more items (pads, zone areas, tracks…).
As far as I can see, this results to what I have suggested:
There should be only one higher level error message for each net: “Net x is split into n parts”.
The error message can have several lines. Each line describes one split part of that net.
Each line should indicate for the end user how to identify and find that part of the net.
Each line can of course be refined to for example subitems, a line for each item in that part of the net. But this or more an implementation detail for the software than logical necessity.
Software can’t really decide how the end user wants to identify the parts. It can only use some heuristics.
As Jon said, nets are really defined by pads, although in the PCB design there can be loose items which belong to a net but which aren’t connected to any pad. Heuristics is easy if there’s a lone pad: just mention that pad. It’s more difficult if there are several pads in that split part of the net, or if there are only e.g. tracks in that part.
You said,
I don’t see how that would be the case. I am thinking completely logically, from the viewpoint of the software, PCB and the end user. The only difficult thing here is how to represent each split area to the end user meaningfully. Otherwise the logic is same for the software, the PCB and the end user.
In the message above I didn’t think about the inner workings of KiCad, but the logic of the error message. The message shouldn’t reveal the graph to the end user or suggest a connection, but only tell about each node. The connections would be left to the end user (and to the ratsnest).
EDIT: by “node”, do you mean each KiCad item, or each split part? I thought about split areas.
We could change the wording of the error message if there was consensus that a different wording would be better. What we can’t change is the content of that message. Ultimately all we can know is that there is a collection of pads disjoint from another collection. We could say “C1.2 and 3 other pads are disconnected from C2.2 and 500 other pads” for example, but there is no way to decide on C1 and C2 in a way that will seem “correct” to everyone every time.
I am talking about KiCad internals because it seemed like aiotech-massimo was talking about internals also.
No, the Kicad netlist is net oriented, the more simple to manage, to see its content make a netlist (from schematic File/Export/netlist will make a .net file). At the end there is the net section listing all the nets that represents the wires of your schematic. So, the DRC to find errors has to make on the fly something similar to the netlist and the DRC knows if a pad (or pin if you prefer) is routed or not. The ratsnet is the visual representation of the netlist so, while we are routing the tracks on the board, Kicad removes the pins/pads we route from the ratsnet. It is not difficult to signal an error because there is a split copper zone, just say “hey there are 2 unconnected copper areas for GND”.of course 2 may be 3 or more.
OK, thanks Jon, that clarifies it. I totally agree. What I have proposed is a fix for the current (v6) message system which is a mess. I can’t propose a universal best solution for identifying the split areas using some represantive item(s), but some heuristics would be needed.
The message example you mention is more detailed then the message I would like to have. The important point to me is to receive an error message putting the user in a right direction to solve the error. My board is little but very dense so took about 30 minutes to find the origin of the error. Initially I checked the clearances at pad, footprint and board level, then I changed (with the same) footprint to see if may help and so on. Only after I was totally sure there were no errors related to pad 2 of C18 I started to check all the board and far from C18 I saw the split copper zone. Ironically there were only 2 capacitors on it C26 and C27. So, if I had read something similar to “there are 2 split GND copper zones” would been OK for me and much better if the message had contained the reference of 2 footprints (one for each split copper zone) so that I would found the problem quickly.
A message that some group of pads is not connected to some other group of the same net would be a lot easier for sloppy humans who make false assumptions to interpret.
The assumption aiotech-massimo made in the first screenshot
is quite common. I made that same mistake myself. When a “missing connection” message is shown, it is easily misinterpreted and confusion arises when it’s connected to a section of a zone. When the message shows that the problem is with “a group of pads”, then it’s already a clear hint to look at the bigger picture (which is not even shown in the small first screenshot).
A graph is like a tree data structure is a collection of nodes connected to each other through a set of edges. A tree follows some rule that determines the relationship between the nodes, whereas graph does not follow any rule that defines the relationship among the nodes. In practice a tree is an acyclic graph. The connectivity data is a collection of acyclic graphs so it is a forest of trees.
Connectivity data is cyclic… but I’m going to stop this discussion here. Since you seem to be familiar with computer science topics, I advise you to dive into the KiCad code and start messing with it yourself if you want to improve things.
(note for clarity: the ratsnest is a tree, but that’s a specific visual representation of connectivity rather than being the connectivity itself)
Considering that Kicad netlist is net oriented the connectivity data can not be cyclic. If it is… you have a problem somewhere in your algorithm. To be clear for everyone: a net oriented netlist is made of a set of nets data and each of them contains the pin references connected to that net. So, thinking to the GND net it will have a lot of pin references but the same pin can not be found in any other net so the netlist can not be cyclic and therefore the connectivity data can not be cyclic. Last but not least if the connectivity would be cyclic autorouting algorithms can not work.
No. The PCB editor knows what the current design netlist is at the start. What it has to make is a data structure representing what is physically connected together by copper, and then compare that to what net is assigned to each footprint pad (which comes from the netlist). This data structure has little to do with the structure of the netlist itself.
When you have a zone split into two regions, each containing pads, the physical connectivity will show these two regions that both have the same net info. It then can know that you have some kind of disconnect. What it can’t know is what you (the human) intended for the design.
OK, I see a main problem here. The graphic representation of footprints, pads, vias and any other physical object on the PCB (I mean the routed ones) has no so much to do with the logical connection between them or at least is loosely logical coupled with them. If you do not keep track of their logical connection I agree that DRC is in trouble to signal errors linked to logical connections. But I am surprised, because following the ratsnet to connect objects should not be difficult to put these objects in a data structure to represent the logical connection and update it while routing.
That’s exactly what we do! But that still doesn’t enable you to read the mind of the designer and know where they intended to connect the two disjoint sets of pads.
“That’s exactly what we do! But that still doesn’t enable you to read the mind of the designer and know where they intended to connect the two disjoint sets of pads.”
This does not matter so much, just signal that 2 or more sets of pads are disjointed. I do not think there is a different possibility then split copper areas to produce this error. So any info that may help to identify the disjoint copper areas is welcome.
Now, after your latest posts and the one by Paul, I think we are in the same page after all. " Just signal that 2 or more sets of pads are disjointed" – that’s basically what I have suggested. And also Paul: "A message that some group of pads is not connected to some other group of the same net would be a lot easier ". In the issue I suggested a message like this:
ERROR: Net [GND] is split into 5 parts
Track on B.Cu and 12 other items
Pad 2 of R4 and 3 other items
Unnamed zone on F.Cu and B.Cu
Pad 12 of U1
Pad 13 of U1
Would there be something wrong with that, and wouldn’t it be just what you wanted? If it doesn’t meet your needs, could you write a similar example message which could be showed in the DRC dialog?