kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 1/16/2017 10:30 AM, jp charras wrote:
> Le 16/01/2017 à 14:18, Kristoffer Ödmark a écrit :
>> For basic work, maybe reusing zones functionality in the footprint editor 
>> will be enough, and then the anchors would be added by regular circular or
>> rectangular pads. Similar to how one would add custom paste layers today.
>>
>> For more advanced, I vote svg or gerber import.
>>
>> SVG is a common file format, and there are 
>> good svg editors. The olther alternative would be to look at some antenna 
>> design software and see what formats they commonly export to, and choose that.
>>
>> When ordering a design pcb antenna, gerbers arrive in the inbox. Gerbers, 
>> Gerbers seems like a good thing to support. Just my thoughts. 
>>
>> I dont know how practical python scripts are, or if I would trust them without 
>> having some kind of visual feedback, from example a svg or gerbviewer anyway. 
>>
>> - Kristoffer
>>
> 
> We can use the footprint editor to help the custom pad shape creation, of course.
> Or use the footprint editor in a modified mode (less tools) to edit the shape.
> However, I am not sure this is the best way for strange complex shapes.
> 
> SVG is a candidate (moreover I found a SVG library (which is .hpp headers only, therefore no new
> dependencies) to handle SVG format).
> DXF import, already supported in Kicad can be an other candidate.
> 
> Gerber is not so easy to import, due to some tricky features (negative objects, aperture macros).
> I am reluctant to duplicate the Gebview code in Pcbnew.

Please do not duplicate the gerber code in Gerbiew in Pcbnew.  If we
need to convert gerber files to board objects, please factor this code
out of Gerbview into a reusable object or library.  Maintaining
duplicate code is a maintenance nightmare.

> 
> Currently, the pad editor dialog has a visual feedback, so python scripts could be (theoretically)
> used (the current footprint wizard API is a good base).
> 
> Of course, we can start a pad shape support without a full and good shape editor/importer.
> (A basic shape editor is already available).
> 
> One constraint is the fact a custom pad shape (which can be build from a set of basic shapes: lines,
> circles, rings, polygon) is the fact the final shape should be only one polygon (with holes).
> Otherwise it is not *one* pad shape.
> So all pad shape edition must be made from the pad editor dialog (or at least controlled by it).
> 
> A pcb antenna can be in some cases a custom pad.
> But because it often has 2 different pads, it is more a microwave component with a copper shape
> connected to 2 (or more) different pads (like a net tie) (etched component in Gerber)
> 
> Hi, CERN guys,
> I remember someone at CERN worked on (or was willing to work on) SVG import.
> 
> Is it a work in progress?
> 
> 
>>
>> On 01/16/2017 01:41 PM, jp charras wrote:
>>> Le 03/05/2016 à 14:40, Tomasz Wlostowski a écrit :
>>>> 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
>>>
>>> Hi, Tom
>>>
>>> I am now willing to rework on the custom pads, and commit my (old) work.
>>>
>>> I carefully read you very interesting proposal.
>>> I agree with some of ideas, but not of all.
>>>
>>> OK for anchor pad idea (like in the custom pad), but just why is the interest of "has no physical
>>> copper" and "exists on a single copper layer"
>>> It could be interesting, especially in net ties and microwave graphic items, to be able to connect
>>> any item on any copper layer.
>>>
>>> An other remark: net ties and microwave graphic items can connect more than one or 2 pads.
>>>
>>> But after spent a lot of time to think about you proposal, I am thinking custom pads differ from Net
>>> ties and microwave graphic items.
>>> * a pad used in a net tie or microwave footprint can be moved, rotated, and layers changed ...
>>> without the need to propagate these changes to associated graphic items
>>> * associated graphic items are just graphic items, on a copper layer, and are not necessary flashed
>>> in Gerber files (they have just a "etched component" attribute, if they belong to more than one net)
>>>
>>> But a custom pad is closely linked to the graphic shape:
>>> * They are part of the anchor pad, so they must be moved, rotated, and layer(s) changed ...
>>> according to the pad anchor changes.
>>> * Ideally, the entire pad shape should be flashed in Gerber files, for technical reasons.
>>> * also clearance for solder mask, solder paste and zones is handled in a different manner for custom
>>> pads than net tees.
>>>
>>> So using separate entities for graphic shape and the anchor pad simplify the edition of the shape,
>>> but create numerous issues for anything else than shape edition.
>>>
>>> Therefore, your proposal is very interesting for graphic shapes linked to a pad in net ties and
>>> microwave applications, but is not perfect for custom pads.
>>>
>>> In may current work, the main issue is the custom pad shape edition.
>>> for many shapes, the pad shape dialog is a reasonable way to enter ashape.
>>> for complex shapes (a spiral, a microwave filter, an inductor) I am thinking the footprint editor is
>>> not the right way to build the shape.
>>> As you said a python script, or a svg import, is a better way.
>>>
>>> I am waiting for comments, especially for custom pads.
>>>
>>> Thanks.
>>>
>>
> 
>