kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/2/2016 12:56 PM, Andy Peters wrote:
> 
>> On Aug 2, 2016, at 8:30 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>>
>> Moving this to a new thread.
>>
>>> On 8/2/2016 7:16 AM, Chris Pavlina wrote:
>>>> My implementation had a large number of symbols, would have allowed
>>>> user-supplied arbitrary symbols if I had finished it, and automatically
>>>> selected a symbol based on net name _exactly_ as Clemens suggested. All
>>>> of these issues are solved.
>>>
>>> How difficult would it be to apply the same selection criteria for power
>>> symbols?  The more you explain what you have done with power label the
>>> more it seems like you could have done the same thing with power
>>> symbols.  This would save implementing a new object and the file
>>> formatting to support it.  Maybe I'm missing something here but I just
>>> don't see how a new label type that looks like a power symbol is
>>> different from a power symbol that already provides the same functionality.
>>
>> It provides the same functionality. I just think it's more consistent
>> from the user's perspective - see my comment earlier about them /being/
>> labels, functionally speaking - and not that much more trouble to
>> implement.
> 
> One user’s perspective (mine).
> 
> A power symbol is NOT a component. It doesn’t have a footprint, it doesn’t go on the BOM. So it should not be in a component (symbol) library.

You are correct.  A symbol (power or otherwise) is not a component.  It
is a symbolic representation of a component or anything else that needs
to represented that is useful when designing PCBs.  Power symbols are
useful for ERC.  What about net ties?  There is no component involved
with a net-tie yet it has a footprint that represents the user's desired
connection pattern in a PCB.  I've seen other EDA products allow for
virtual (in BOM but not in netlist) symbols for creating BOMs that
include hardware that are not directly part of the PCB.  Sure, we could
represent each of those objects differently both internally and what we
present to the user but they are all so similar in scope that the symbol
concept makes sense.  If we want to present these "special" symbols to
the user as something else, I'm fine with that but I'm not sure how
useful that is but internally they can still be represented as symbols.

> 
> It really is (or at least should be) nothing more than a specialized global net label.
> 
> -a