kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 16/01/2017 à 17:53, Wayne Stambaugh a écrit :
> 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.


Of course, yes.
Anyway, using a Gerber source is not what I prefer.

>   Maintaining duplicate code is a maintenance nightmare.

Of course, yes, yes, yes.

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

An other idea is to use bitmap2component to convert a shape (from a picture) to a polygon.
This is sometimes useful.

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


-- 
Jean-Pierre CHARRAS