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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
