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