kicad-developers team mailing list archive

["Kristoffer Ödmark" <kristofferodmark90@xxxxxxxxx>]

>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).

This is not really a problem, as long as every pad doesnt need an anchor. Might be a poblem with the 
NETlist though. 

>Of course, we can start a pad shape support without a full and good shape editor/importer.
>(A basic shape editor is already available).

That seems like a good plan, to get a sense of the demand for the editor etc.

- Kristoffer





On 01/16/2017 04:30 PM, 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.
> 
> 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.
>>>
>>
> 
> 

-- 
 -Kristoffer