kicad-developers team mailing list archive

[Andrew Zonenberg <azonenberg@xxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I do the same thing - power flags and hidden pins are banned in my
designs. To supply power to a net I set the "power output" flag on the
pins of the connector going to the battery/power plug.

On 06/02/16 09:23, André S. wrote:
> Ok, I see your point regarding not breaking old designs.
> 
> However: the current KiCad broke mine, since it does regard hidden
> pins different than "the old KiCad" (around 2013). The old KiCad
> connected a visible "hidden pin" only to the connected net. The
> current KiCad still connects it to "VDD" regardless of the
> connected net and therefore connects two different named nets.
> Which then forbids the use of "VDD" for a power net, when you use a
> KiCad library part with hidden pins in your design and connect its
> power pin to a no-"VDD" net.
> 
> BUT if I did "the right thing" right from start, KiCad would have
> warned me, that I connected two "power nets". Which it does when I
> place a "power flag" on each net. (Which is one way where KiCad
> forces its "true way" where other tools have the "power flag" built
> into the power net symbols.)
> 
> I learned my lesson on this one: do not use KiCad library parts,
> create your own.
> 
> Regarding multiple names on (not power) nets. There was a
> discussion some time ago. If I remember correctly, most people that
> use that feature would be OK with net-aliases (which is what they
> use that feature for) and having a fixed name on that net. 
> Currently when a net has a name and you add a new label it may
> occur that KiCad uses the new label name for the net. In the PCB
> the trace then gets a new name, which may not be what the user
> intended. Also with the current implementation you may accidentally
> connect two nets and have _no_ way to check this with ERC.
> 
> My proposal on this is: Newer KiCad versions can check for multiple
> names on a net and raise an error/warning when it sees one. 
> Therefore the user has a way to see accidentally connected nets. 
> Regarding not breaking old designs: One way: KiCad will need a
> dialog window where the user can add aliases to the net to keep
> current functionality. This dialog  may be accessible from the ERC
> report window to give the user a way to do it the "right way". Net
> aliases are then handled like net labels but do not (re)define the 
> name of the net in the netlist. OR second way: The user ignores the
> error/warning and works as before.
> 
> André
> 
> On 06.02.2016 16:52, Wayne Stambaugh wrote:
>> I would not have allowed that to be implemented.  One thing I try
>> to avoid is forcing users down the "one true way" path of pcb
>> design whenever possible.  I prefer to give users the flexibility
>> to design as they see fit even if it means that kicad has a
>> steeper learning curve. I don't pretend to be wise enough to know
>> what the "one true way" is and I really don't like someone else
>> forcing it upon me so it would be hypocritical of me to force it
>> upon someone else.  If you are comfortable with hidden pins, use
>> them.  If not, don't.
>> 
>> On 2/6/2016 9:59 AM, Thor-Arne wrote:
>>> I agree with Chris on the hidden pins issue, old design should
>>> not be broken.
>> That is also a no-no for the project.  One of the goals of kicad
>> is to make every effort to maintain backwards compatibility.
>> 
>>> When it comes to net names I think they should be forced to be
>>> unique.
>>> 
>>> Anyway, are we going to collect features requests now? Would it
>>> be better to have a wanted-feauture list on github instead of 
>>> the mail list so nothing gets lost?
>> Take a look at the release 5 (current development cycle) road
>> map. Maybe we can add it to one of the existing tasks where it
>> makes sense. Please keep in mind, we cannot endlessly add tasks
>> to the release 5 road map.  We need to be realistic about what we
>> can achieve given our current manpower.  I can always add new
>> tasks to the global road map for future dev cycles.
>> 
>>> 
>>> -----Original Message----- From: Chris Pavlina Sent: Saturday,
>>> February 06, 2016 3:30 PM To: André S. Cc: KiCad Developers 
>>> Subject: Re: [Kicad-developers] Discussion: Hidden Pins, Net
>>> labels
>>> 
>>> Eh. I agree 100% about hidden pins being Bad, anyone using them
>>> surely should be tarred and feathered. But I'm not sure it's
>>> our place to enforce good schematic drawing practices. If
>>> people want to use KiCad to draw terrible, horrible schematics,
>>> they'll find a way. Personally, I'm *strongly* against breaking
>>> old projects, the feature should be kept around at least as a 
>>> legacy support feature for old projects that are imported.
>>> 
>>> I just don't use hidden pins, they're strictly forbidden in my
>>> libs and I would never use them for anything other than
>>> implementing power symbols.
>>> 
>>> On the fence about net names.
>>> 
>>> On Sat, Feb 06, 2016 at 03:22:04PM +0100, André S. wrote:
>>>> Hi everyone,
>>>> 
>>>> this issues are still on my wishlist for KiCad: - Ban hidden
>>>> Pins. - Disallow multiple labels on the same net. Especially
>>>> the combination of those two is a source for non-obvious 
>>>> design bugs.
>>>> 
>>>> Wayne recently stated that now the planning for release 5 has
>>>> started, so I just thought I bring it up again.
>>>> 
>>>> I wrote a blog entry why I think those two topics should be
>>>> addressed, you can find it here (warning: wall of text ahead
>>>> ;)): 
>>>> http://transistorgrab.de/2016/02/05/why-hidden-pins-are-evil-and-ne
ts-should-only-have-one-name/
>>>>
>>>>
>>>>
>>>>
>>>> 
I'm really interested that at least there is a definite conclusion for
>>>> KiCad and that this conclusion is then put somewhere obvious
>>>> in the documentation with all the pitfalls that come with
>>>> that features and how to avoid them.
>>>> 
>>>> Thanks in advance for anyone taking part in the discussion.
>>>> :)
>>>> 
>>>> Best Regards, André
>>>> 
>>>> _______________________________________________ Mailing list:
>>>> https://launchpad.net/~kicad-developers Post to     :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>>>> https://launchpad.net/~kicad-developers More help   :
>>>> https://help.launchpad.net/ListHelp
>>> _______________________________________________ Mailing list:
>>> https://launchpad.net/~kicad-developers Post to     :
>>> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>>> https://launchpad.net/~kicad-developers More help   :
>>> https://help.launchpad.net/ListHelp
>>> 
>>> _______________________________________________ Mailing list:
>>> https://launchpad.net/~kicad-developers Post to     :
>>> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>>> https://launchpad.net/~kicad-developers More help   :
>>> https://help.launchpad.net/ListHelp
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~kicad-developers Post to     :
>> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>> https://launchpad.net/~kicad-developers More help   :
>> https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~kicad-developers Post to     :
> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWti2VAAoJEDRhermzHH189A0P/34Jf0MJ1CB4dbNEQj4zEGiQ
daCAjit1rQRjNr0n4ESjB03ehPMIyFauXjA3fjmGCZnhkgUWALYQdB3Zl87aIm3h
YC30+ATFPbBHEUB4Quctq1JP19tp0ylO9mGFAVximcCZHnyZONmKMF2ZjTMlGC5c
nJ8lxtcBLRNR2LOXeY23XAEuSoClgO1A4S0ltWpFdG0wOyi3o6GBWuOmq8p/pOcq
VHUwLv892QCrbrPumrvlRDHYY0fQWU65mgvg/BrBouOoyXfE6pX8w5NmJ3L0OxsB
2gv92i+/cNt9iTKUa56PdSETW9DAn0dnkB7krQIAiiyemCoQcCeGrz7xydebavww
v4FsoVEb7ZfbEW6HUjI6GVCkAw1xbnEp6VXIKR3m700reb+BC5fMBJS+cLfsyakX
vG11+/mgYfiperO+SiP5vlTEIMdJpD8GVyuO9113EPeW3zHlcCCJMfMm3zDW+vMF
jFjXAmpH+o0o1MOyfD4x/5zu/CMspKr3/2ja5OX5Tcfcqugy0AK8XKX6tU39cBKm
p7SqzsODSH9B/m46n4QucYNPgygagKo+cR/nw0xb4ZOLgsGXSWhzeoKk665M5tTp
Y3PoUz11Ac7jVk4uZve93+nsIoEm3nFimrJ/IT2RMn0a/kf7YydrI+kg989t+klc
q6ClJBo2Mlvgm+w0jem3
=XEqP
-----END PGP SIGNATURE-----