kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

The use of fields for arbitrary data is indeed powerful.  It should also
be limited to passing information to external tools such as simulators
and scripts such as Tom's proposal.  Anything that is supported as a
feature in KiCad should be part of the schematic file format and fully
supported by the schematic editor.  The problem with using fields is the
user has to know how to define all of the attributes correctly which
requires thorough documentation.  I don't see this as a good solution
for the average user.  This is a bit like using regular expressions.
They are really powerful but only a small number of users (typically
developers) will actually know how to use them effectively.

On 5/3/2016 7:13 PM, Strontium wrote:
> My 2c.
> 
> One of the fantastically useful features of eeschema is components have
> an "arbitrary" list of key:value pairs (fields) attached to them as
> attributes.
> 
> Can I suggest that such a feature attached to objects on the PCB would
> be even more powerful/useful.
> 
> It would mean that changes like the ones suggested would not require
> further format changes to the pcb file, these attributes can be
> added/deleted at will as they are just a key:value pair.  It would also
> make the file format backward/forward compatible, pcbnew wont care what
> the key:values are, it can read/edit/propagate them.  If functionality
> exists to utilise them then it can use it, if not, they are passive,
> just like eeschema.
> 
> Further, the key:value pairs in eeschema could be imported into the
> matching pcb objects, so that there is only 1 place that needs to be
> edited to set them (the schematic). (I actually think that should be the
> proper place to set them)
> 
> And by objects I mean both components AND nets. At the moment only
> components have "fields" on the schematic, the ability to attach them to
> nets would be mighty handy.
> 
> It would also be super useful for python scripting, because you can
> tag/parametrise your objects on the pcb and your scripts can then,
> easily, only do things with the appropriately tagged entities.
> 
> FOR EXAMPLE:
> 
> On the schematic, a key value pair is added to a net:
> IMPEDANCE:50
> This attribute is set as visible, so when the schematic is printed its
> OBVIOUS that the net needs to be 50Ohm impedance. (It would be great on
> schematic if the visible flag had 3 states: invisible, value only,
> key+value)
> 
> On the PCB, a python script is run "adjust_impedance", it scans all nets
> looking for ones with the "IMPEDANCE" key, and then adjusts the width of
> the trace to have that impedance, as required. And if it can't, it
> generates a list of nets which are not the correct impedance, based on
> the board parameters as set in the schematic.
> 
> ALL of the features suggested below would be easier to implement with
> such a unified attribute system between schematic/pcb AND would mean
> that fewer changes need to be made to the file formats long term.
> 
> Steven J
> 
> 
> 
> On 03/05/16 20:40, Tomasz Wlostowski wrote:
>> Hi all,
>>
>> Recently there has been a lot of discussion on these features. Here's a
>> short proposal how we could hit all three birds with one stone:
>>
>> Changes to SCH:
>> - none
>>
>> Changes to netlist import:
>> - auto_generate flag for SCH components - when set, invokes a Python
>> script/C++ plugin which updates the PCB footprint of the component
>> depending on its SCH parameters (e.g. produces a microstrip footprint
>> based on Width/Length parameters defined on SCH).
>> - write some microwave component generator plugins (or port the existing
>> tools). Perhaps a good job for Python.
>>
>> Changes to PCB:
>> 1) Add two flags to each graphical primitive within a footprint:
>> - net_tie: DRC treats the primitive as non-conducting and doesn't throw
>> a short circuit error (see drawing A)
>> - net_inherit = pad_number: the primitive will take the net of the pad
>> with given pad_number (see drawing B)
>> 2) Add new 'anchor' virtual pad type.
>> - indicates the point to attach a trace/via when routing the component.
>> - exists on a single copper layer.
>> - has no physical copper.
>> - has an optional direction vector which denotes how it can be connected
>> with a trace/other anchor pad (see drawing C)
>> - has a circular perimeter (maybe other shapes in the future if needed).
>> Objects intersecting the graphical primitive outside the anchor
>> perimeter are considered colliding by the DRC (see drawing D) even if
>> they have the same net.
>> 3) modify .kicad_pcb/footprint formats to support the above:
>> - extend fp_* entities: net_tie & net_inherit flags
>> - extend pad entity: add anchor pad type, perimeter radius and direction
>> vector.
>> 4) modify DRC to support the above (we can benefit from the work already
>> done by JP)
>>
>>
>> Advantages:
>> - microwave footprints generated straight from the schematics.
>> - net ties for free (since based on the same idea as microwave components)
>> - custom footprint copper shapes almost for free (costs one extra flag &
>> some changes in netlist importer)
>> - minimum changes to file formats & data structures.
>>
>> The attached drawing shows use cases for all of the above and explains
>> the concept of anchors.
>>
>> Looking forward to your feedback,
>> Tom
>>
>>
>> _______________________________________________
>> 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
>