← Back to team overview

kicad-developers team mailing list archive

Re: Discussion: Hidden Pins, Net labels

 

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

This sounds like the best option to me - keep the feature around but
throw a DRC error if you try to use it. This keeps old designs working
(albeit with warnings) and discourages use of hidden connections in
new designs.

Eventually, if the project reaches a consensus in the future, the
creation of new hidden-pin components can be disabled in the UI (or
maybe require an explicit preference change / warning dialog to
enable); existing ones will continue to work for compatibility.

On 06/02/16 09:12, Thor-Arne wrote:
> I think the multiple netnames on the same net should be included in
> the roadmap v5 DRC check. This should as a minimum throw a warning
> as this might break the finished pcb.
> 
> It might also affect the hidden pins issue as one might have
> several supply voltages connected to VCC pins. However, it's better
> to get warned by this in eeschema than risking having parts
> supplied with 5V when it should have been 3.3V.
> 
> I see no issues with this for backwards compability.
> 
> -----Original Message----- From: Wayne Stambaugh Sent: Saturday,
> February 06, 2016 4:52 PM To: kicad-developers@xxxxxxxxxxxxxxxxxxx 
> Subject: Re: [Kicad-developers] Discussion: Hidden Pins, Net
> labels
> 
> 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-net
s-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)

iQIcBAEBAgAGBQJWtip2AAoJEDRhermzHH18co0P/jTITkWt0E8DzHU6x0aNTCv+
iF4iqp0u2rWgQGrTxsd3KpWPpc2n8MD7/e4o6n2KJgRiR1vRPdweuG6Wt+tTLoXI
bZFDpCNVDNT9cMAQ1jEvAB0AXYbOQFHTNk5a9+FP7jLzVrFYMGpbI5uIdGHsUwHH
8AJVLUbvjS3BXH0tOSGv3WN3Xfk/ljkC/psFygDjYyLYsNk7CkrykQBUma8J2ody
NYJdCU9Cl6fb0cuXGo2ZAyfVYnZnU2OGze0YkaOUUIaaMu2fg6qj3rdvquh1X5pu
iPsqPyxeaLitKH2m5AIE2Yi+Nq07GaWyEqY0Ct+MZ254m0Sy/lepa+nPNkEcR3b9
OGCVjiu+aQpFK5QlXXm2NYVlgvggPSGEehojngEM3Oyl7V/dgLNmxCv2OmpH8xHp
yReIpGNo5JwQOtMQIYI5jp2qT6+dEJIHb7ivT0rd/SUaPKtoOnQ5yd5pV76uyl79
+1Igvx91N1QC5hb8RWAnxzjg5tweyrB9SSC4AjyP3thxyW/ACBNHGhnOPjXO0I0u
SY2WsnGXzpq4E0asVZjCM98sUCVrb0UBQeNAGTgA+ymoyb4I42X/GcY7r7dJHGTS
RmMPk3Frk8uHgneR759c1TA8hjPKNowd1hENLeY0aRHTtyajPDwQBUO/zYQYSMIA
YURvNWPAK5hK/Vy97V2C
=Cl/t
-----END PGP SIGNATURE-----


References