Beware when moving stuff around

[JPortici]

one of my pet peeves of kicad is the impossibility of dragging multiple elements on the PCB, and dragging any component is useless anyway as tracks will happily overlap each other and sorry you can't drag anymore.
So you move, but if you are not 100% extra careful, or you don't unroute/reroute every time move can result to this.



Connected but not really connected, i caught it by accident. Would have been really fun to debug. DRC doesn't help me here, how can i catch them other than a manual review every time?

(Kicad v7.0.8 )

[jpanhalt]

I don't use KiCad yet, but as I understand what you said, it is a serious flaw. 

1) I assume that "pin" was attached to the track before you moved it.  Are you sure?  In Eagle it is possible to have a pin and net look connected, when they are not in the schematic.  ERC finds them usually.  Even if connected properly in the schematic, it is possible when  routing not to have them fully routed (i.e., a little segment of airwire remains).  Eagle pings when the route is connected.  What happens if a pin is not connected to a track and you move it?  The airwire becomes visible and stays connected to both pin and track.  I can understand things not being connected in the schematic or board, as that the the user's fault.  But in the board to have something disconnect when it is moved would be a disaster.  Is that what happened?

2) In Eagle, when one moves previously routed devices, the tracks stay attached.  If they cross another track, then DRC reports it.  Are you saying that you cannot move a previously routed device if the tracks cross?  That sounds like some "we know better than you" feature added by Microsoft.  Presumably, the workaround is to convert back to an airwire before moving.  What a PITA that would be.  What I frequently do is convert to airwire ("rip-up") only a segment of the track attached to a device I am moving.  I then handle ripup/rerouting as needed.

EDIT:
If Benta's supposition is correct, what you see with respect to lack of connections is what Eagle should do too.  Without a schematic, a board design is similar to a picture rather than an electrical design.  Although, the absence of airwires is not always proof there is no schematic.  I sometimes hide certain nets  (e.g., GND and VCC) to reduce clutter when routing signal.

[Doctorandus_P]

KiCad does check for this. All you have to do is add the minimum required width in: PCB Editor / File / Board Setup / Design Rules / Constraints and then fill in a value for the minimum connection width


Note that this does not generate a DRC violation if the connected track itself has a width that is narrower than the width you enter. For that you have the use Minimum track width entry box just above it.

[Benta]

Is this a PCB without schematic and netlist? It looks that way.
Otherwise you'd at least have ratsnest lines.

[LazyJack]

Why are you not getting ratsnest lines? You should be. Are you sure your schematic is ok?
Cleanup should remove the dangling traces.

[hpw]

The point is this, KiCad do not rely on NetList, just as using graphical behaviors!

Or simple do a component rotate and see how connections gets wired up. 

[Doctorandus_P]

@ Benta & LayzyJack:

The reason no ratsnest line is shown is because the track does reach the via and there is a copper connection between the two. And thus, the question becomes: How wide does the copper connection need to be before it is accepted as valid? And this is a simple value you can enter in the schematic setup as I have shown in my earlier post.

[janoc]

The point is this, KiCad do not rely on NetList, just as using graphical behaviors!

Or simple do a component rotate and see how connections gets wired up. 

That's completely nonsense. Of course KiCAD does rely on netlist, even though you don't generate it manually anymore as it used to be.

And, of course, that assumes you actually do draw a schematic for your board first. If you don't then ...   


That the OP didn't get a ratsnest line between the two bits and a DRC failure could be caused by several things, none of which is a bug but user error:

- Not having a schematic at all. No comment ...
- DRC disabled/misconfigured. No comment ...
- The trace is redundant and the two parts are connected by something else elsewhere on the board already.
- Ratsnest display disabled. This sometimes behaves a bit strange and even when enabled the ratsnest may not always appear reliably. So if it was enabled and the line didn't appear (and it is not one of the cases above), then this could be a bug.

There is also a big difference between dragging (leaves connections intact and will apply push-and-shove routing) and moving (breaks connections). Dragging doesn't always work because if the traces simply won't fit between the components anymore without violating the DRC constraint. I am not quite sure what is the software supposed to do in such case, though? Pushing components around too while dragging is most certainly not desired. 

[rhodges]

- The trace is redundant and the two parts are connected by something else elsewhere on the board already.

I have seen this after doing ground and power plane pours. It would be interesting to do EDIT -> "Unfill All Zones" (Ctrl-B) and see if the ratsnest line appears.

[Doctorandus_P]

It would be interesting to do EDIT -> "Unfill All Zones" (Ctrl-B) and see if the ratsnest line appears.

This will not happen. For an explanation, read the previous messages in this thread for an explanation.

[JPortici]

That the OP didn't get a ratsnest line between the two bits and a DRC failure could be caused by several things, none of which is a bug but user error:

- Not having a schematic at all. No comment ...
- DRC disabled/misconfigured. No comment ...
- The trace is redundant and the two parts are connected by something else elsewhere on the board already.
- Ratsnest display disabled. This sometimes behaves a bit strange and even when enabled the ratsnest may not always appear reliably. So if it was enabled

wrong
wrong (altough i'm using the defaults for minimum connection width. will check on that. If the default is 0.000000001mm or whatever minimum physical distance that's another problem as i think kicad should propose me with a sensible default as it does with almost every other option)
wrong
wrong

There is also a big difference between dragging (leaves connections intact and will apply push-and-shove routing) and moving (breaks connections). Dragging doesn't always work because if the traces simply won't fit between the components anymore without violating the DRC constraint. I am not quite sure what is the software supposed to do in such case, though? Pushing components around too while dragging is most certainly not desired. 

Diptrace version 3 doesn't have push and shove, so it will take the nearest node and extend/move from there. Anything that overlaps you have to rearrange manually, or unroute/route. This is only how i was used to work and i agree that usually PnS is much more efficient so i'm just going to unroute/reroute anyway.
But my pet peeve with drag is that even when doing movement that follows the direction of the last segment, kicad tends to screw up the trace so it overlaps something even at the first step, making drag useless most of the times for me

Doctorandus_P seems to get it

Edit: I can confirm that changing the minimum connection width in design rules, while it does not show the ratline because even one atom of contact is enough to hide it (fine with me), it does report the warning "copper connection too narrow", which is what i was looking for.

I will accept this as a PEBCAK even though i find it amusing that kicad comes with a default set of rules and constraints that are completely fine with cheap PCB services (which is what i use for prototypes so i didn't bother to change after a quick check) and yet this parameter has a default of "zero". The same can be said for minumum track size (because i think you REALLY want it to be a micrometer wide, track width is something you usually decide anyway) and minimum clearance (although the last one is probably overridden by net classes clearances)