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).
Yes, correct interpretation.
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.
I am not talking about the netlist, I am talking about the connectivity, meaning how things are connected together (or not) by copper on the PCB.
Do you agree that DRC to find connectivity errors has to make something similar or at least organized as the netlist?
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?
Basically it is OK for me.
Note that the reporting is different for 7.0. If the net is split and each part has a zone, the missing connection will always be reported between the two zone parts (as opposed to between a random pad and a zone part). Additionally, the ratsnest line is optimized to be a reasonable approximation of the shortest line between the two zone parts.
People seem happy enough with it so far, but then the nightly users are more used to KiCad’s quirks, so I’m not sure that’s much data…
Aye, I just created a simple test project for this and just mentioning that parts of a zone are not connected makes me quite happy enough in this regard.
If you want to try it for yourself, I can save you a few minutes by using this test project:
2022-11-23_asdf_split_zone.zip (12.3 KB)
Yes, it is OK, may we have this type of report also in Kicad 6?
KiCad is in feature freeze for the forthcoming version 7 as of 1st October with, I believe a release date scheduled before the end of Jan 23. New functionality won’t get added to V6 but the new version should be available soon - and can be tried already if you install a nightly version. Generally, after feature freeze, the nightly versions are pretty stable and, although you might not want to use them in a production environment, they are pretty solid. The more eyes on the nightly versions, the sooner bugs get found and fixed so, hopefully, the release version will be fairly bug free.
This was considered a bug fix and so would have been a candidate for back-porting to 6.0. However, it does the optimizations in parallel, and a multi-threading bug was just found & fixed in it. So that resets the clock on its “chill” period in master, and with the release of 7.0 forthcoming it’s unclear if there will be enough time for it to chill and then get back to 6.0.x. (Once 7.0 is released as a stable version we stop back-porting fixes to 6.0.x.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.