I just discovered this Kicad “bug” and I really do mean bug. I ended up with two partially overlapped copper pours/fills that are two different nets. Sorry, but there is absolutely no way that two different nets should ever be able to connect together (unless clearly specified in a net class). I really feel the Kicad team have lost their way here, and this needs to be rectified. Wow, this is so dangerous and could easily go unnoticed in a complex/multi-layer board design.
I experimented with the zone priority settings, and found that if I set the two pours to the same priority, again they overlap, so this is an easy mistake to make and I see no benefit from having this. Anybody working in CAD would (reasonably) expect that two nets shall never cross paths anywhere, especially in an automated copper pour.
Sorry guys, I do enjoy using Kicad, but as I said, I think this concept is dead wrong.
Sorry, but KiCad assumption is different. As an test I made a schematic consisting of two resistors connected paralel between VCC and GND. At PCB KiCad allows me to place first of them over the second with its GND pad on that second VCC pad. If KiCad would not allow me for that it would seriously complicate the process of elements positioning.
The same comment once more.
Me not. I don’t feel so.
Reading that I actually got scared that DRC did not notice it. I made a test at those my simple project placing the small VCC zone inside the bigger GND zone.
My KiCad DRC reports: “Error: Copper areas intersect.” for each VCC zone corner being inside GND zone.
If your KiCad DRC not reports these errors than … I don’t know… may be installing the latest version could help (I made this tests with V 6.0.7)
If it will be not allowed than for example to change two zones priority form 1,2 to 2,1 you will have to use temporarily a third priority value as KiCad would not allow you to set 1,1 even for a while.
So, thanks to KiCad allows you set two zones the same priority, you can do things simpler and faster - you have to do two priority editions and not three to have that change done. Still don’t see the benefit? This is the same kind of advantage as:
allowing to position one element on another even their pads with different nets collide,
allowing to pre-arrange footprints even you don’t have even the single line at Edge.Cuts
allowing to position elements out of Edge.Cuts rectangle,
allowing to position elements at big whole you made in your PCB,
and many, many other unaccepted in final project situations during working on your design.
You are simply not restricted during work.
Software that keeps you from doing something every now and then is really annoying.
Can’t you imagine how your work with PCB would look like if KiCad would not allow you to do any action that makes temporarily a conflict with one or another rule. I can.
You should always use DRC anyways, and it handles this as an error. KiCad allows many things while editing which can lead to “dangerous” situations, but DRC should catch them.
The logic behind the zone priority handling is that KiCad can’t possibly know which zone should “avoid” and which should fill the space, unless the user tells. Trying any kind of guessing logic will fail for some situations, and that’s an even more dangerous situation: KiCad made a decision AND it’s not noticed by DRC. What if the guess was wrong?
Absolutely not true. Virtual net ties are a common where you intentionally short nets in the pcb editor but leave them unconnected in the schematic. This is usually in high power designs where zero ohm resistors will cause more harm than good and “net tie” objects may be too generic or cumbersome if you are talking large unique tie points.
I will say you seem to lack experience in CAD because screwing up like this is also quite normal in CAD I have screwed up designs in EAGLE due to the exact overlap and not running DRC. And I had a PCB designer in Mentor Graphics PADS at work hand me a design where one layer out of 10 had a major short due to overlapping nets because they failed to run DRC. Luckily the fab caught it both times because they run their own sanity check on the gerbers.
If it happens to give you a quantum of solace, the development version has been just changed so that a new zone automatically gets a unique priority value. Whether this is good or bad can be debated, one viewpoint is what I already said. The user is still responsible for checking the result and changing the values.
Just to point out that I have a near 3 decades worth of experience, including over 10 years in a global corporation, designing high power electronic designs/PCB’s. I started out using Orcad/Tango, then Protel 99 and ultimately Altium for several years. Never did I see it permissible to connect two unrelated nets in a PCB design for any of these CAD systems, unless the engineer clearly specified it in some sort of design rule exception or net class. It is inherently (and rightly) assumed that unique nets shall NEVER cross (copper) swords.
I know what you are talking about with regard to things like 0R links, but again, all the examples you mention are managed in the aforementioned CAD packages through proper DRC usage and net management. Permitting different nets to connect, well you may as well throw the entire concept of netlisting out the window and design the PCB’s the “old school 1980’s” way then (IE stare at schematic with your eyes and lay out the PCB to match). I should know, I’ve been there and done that too.
@marekr, you briefly mention too, that it is “quite normal to screw up in CAD like this…”. Well that’s exactly why we have netlists to begin with! To help prevent human mistakes in the first place, and the rules should be applied during interactive routing/fill placement, not at the end of your design when you run a DRC (for example). IE eliminate the human error at source and not be the ambulance at the bottom of the cliff. Just my humble opinion anyway.
On the positive side, I do like the “Zone priority level” setting feature, as this does clearly specify which fill region takes precedence over which. Historically I have had to manage this using keepout zones. A nice touch for Kicad. For instances where two (or more) zones overlap and share the same priority, it should simply be the case that the most recent pour only fills copper up to the edge of existing zones, following DRC clearance rules. In other words, operate like traditional CAD packages with no zone priorities at all. That way there are no netlist violations, and the designer can (at their discretion) decide whether or not they wish to prioritize certain fill regions over others.
There is no concept of “most recent” other than priority. Equal-priority zones on the same layer fill non-deterministically with respect to each other.
Currently we take the approach that this flexibility is worth the downside that it is technically possible to create shorting copper, because that shorting copper is detected by DRC. It is an explicit non-goal of KiCad to prevent all operations that create invalid boards – instead we want to catch all those problems in DRC. The reason for this is that many of these “invalid board” states are useful productivity shortcuts in a workflow (for example, a board might be “temporarily invalid” while you are in the middle of making a change).
And yet we do prevent interactive tracks from running through different (netlist) tracks. I understand what you are saying in terms of workflow shortcuts, but again, isn’t that why we have the ability to unfill zones for example?
I think too much reliance is put on running the DRC at the end of a design (or in the latter stages at least). The sooner you can grab problems, the better. I have always liked using/running the DRC, but at the same time the goal in Kicad should be that you don’t need to run a DRC at all, as problems are dynamically picked up and prevented on the fly. I understand this isn’t always achievable, and still, I do like using the DRC, but the DRC should be plan B, catch the problem the instant it happens should be plan A. This is how every professional/commercial package that I have used works.
Again, PCB development is a complex business and I understand/appreciate that everybody has a different approach (probably why they call it PCB artwork, as it’s part science part magic/art), so this is just my opinion and I’m not knocking Kicad here. In fact for the most part I thoroughly enjoy using it and appreciate all the work that goes into making it a very usable package (well priced too, hehehe).
This is not our goal. We may in the future pick up issues on the fly, but not prevent them. The router has modes that allow collisions just for this reason.
I have screwed up designs in EAGLE due to the exact overlap and not running DRC. And I had a PCB designer in Mentor Graphics PADS at work hand me a design where one layer out of 10 had a major short due to overlapping nets because they failed to run DRC. Luckily the fab caught it both times because they run their own sanity check on the gerbers.