Comment 12 for bug 999057

Revision history for this message
Mark Haun (haunma) wrote :

Thanks Orson,

Sadly I'm not in a position to donate code but I would donate some cash. Is there some place to do that online?

I know everyone thinks "their bug" is the most important, but in this case I'm right... really! :) I am serious about the suggestion to put these proposed features in front of some working EEs, people who do layout for a living, and ask them to help you rank the priorities. I realize no one who does this professionally is going to switch from Altium [yet], but I think you might be surprised what floats to the top in such an exercise.

The push-and-shove stuff is awesome, and is going to save a LOT of time in layout, but in my experience (using a build from last year), the via issue is more than just a time waster. If I knew I could get the result I want, by spending 10x or 100x of the time it would take in another layout package, this would not be such a problem. But when I tried to string the vias along a track as suggested, pcbnew would delete old vias somewhat unpredictably whenever I tried to move things around later. It also would not allow adjacent vias to touch, which is another show-stopper. (E.g., often when placing your array of grounding vias under a QFN package, they will need to touch in order to satisfy the PCB house design rules and still have enough vias.) For my next project I will need to use some vias in an LVDS diff pair, and I am guessing the code will insist on having the vias centered on the traces, which will not allow me to get the impedance matched correctly. These are just a few of the problems, off the top of my head. I have pretty much accepted the fact that the boards I create with KiCAD will be electrically inferior.

Basically, until vias are treated as first-class objects which can exist independently of any net, this is going to be a problem. IMO it is one of the few things gEDA got right, i.e. they take it as a given that the vias, and all copper generally, will stay wherever the user placed them; then, they run a connection engine to figure out which nets are actually connected to one another, and whether or not this matches the netlist. There may be a better way to do it, but it needs to allow equivalent flexibility w.r.t. via and copper polygon placement.

I am still curious if the footprint-as-via technique, mentioned above by Mansour, will let you cover the whole thing with soldermask. That might be the best workaround in the short term.