Hello, Kristoffer, Wayne, friends... Last night, I was drafting some rough concept based on my experience and based on my "ideal" dream of doing things. Just a few notes from my side:
- We need proper names for the things we implement. Physical Design Reuse (PDR) is just one example. channel, array, cluster, group, instance, hierarchical-something,... all these words can have different meaning and need to be considered. - Concept and documentation of usage should come before implementation. - Things to consider: * reuse on one board (i.e. channels of analog IOs) * reuse in one multiboard design. (rigid-flex or with flex or rigid connectors) * reuse across designs * reuse with different components/parameters/objects. The 60 channels were just an example of a PCB I did some time ago. But now - considering a redesign. When I need to tweak the circuits of my channels I would currently (in my commercial product) need to re-create all reuses based on a redesigned reuse, which is off course crap. So, ideally, there will be one master (template) layout/channel snippet and (in realtime *hoho*) all other channels will follow the change (as long as they are not locked or restricted or ?). These channels could be built as an array aligned on a gid x by y or laid out in polar coordinates. There could be a kind of anchor/origin for each channel (and it's elastic bounding box) containing its orientation x,y,rot,layer,instance where all objects of a channel are aligned relative to the anchor of the channel. - Anchors should assist when channel-spacing/positioning needs to be changed after the layout of the channels have been done. - It should be possible to flip channels from top to bottom side of the board and keep some inner layers properly connected (vias have netnames and connect where the layers fit.) - I don't want to care about component references. All reuse/grouping/copy&pasting has to be independent of component references. - Channels should be able to be broken and re-assembled, master/slave channels should be exchangeable. - There should be "ports" in each channel which do some kind of auto-connect to planes and/or to neighbouring channels when the traces align. Some "ports"/nets of a channel are global/external (power/gnd), some are interfacing (inputs/outputs) and some are internal nets. - Some Board.Channel.Reference.Pin naming could be useful to organize components in a channels. - The file formats need to be flexible to implement features without changing file formats (ever) again. :-) There are also some sketches which I would like to share, but unfortunately, I am running out of time again. :-( Call me crazy. My ideas must not be used for anything else than free software. Regards, Clemens On 2017-01-13 14:07, Wayne Stambaugh wrote: > Kristoffer, > > I was merely talking about getting your initial implementation correct > in Pcbnew to prevent issues with the full implementation down the road. > While I'm OK with opening up a full design specification, I think it's a > bit premature and will distract us from the immediate work at hand. > None of the schematic group linking work can happen until the new > schematic and symbol library file formats are complete. I want to keep > the focus on grouping in Pcbnew for the time being and not get bogged > down in a full implementation specification. > > Cheers, > > Wayne > > On 1/12/2017 3:38 PM, Kristoffer Ödmark wrote: >> I think Physical design reuse (PDR) is far out of scope of the group >> selection idea. However it Might be used. I actually put some thinking >> on howto implement some kind of PDR into Kicad without having to >> redesign everything existing already. Its in a google doc with comments >> enabled. >> >> [Google docs link] >> https://docs.google.com/document/d/1ivRRu7F2g6_WU9bgHlaUTaXZw02oluMh4NA41BqEM-8/edit?usp=sharing >> >> >> PDR discussions I think should be in a separate thread, since the amount >> of work to get there is quite a bit more, involves both eeschema and >> pcbnew, new file formatting, specifying workflows etc etc. >> >> Its called snippets in A****m, PDR in PADS. >> >> - Kristoffer >> >> On 2017-01-12 18:47, Clemens Koller wrote: >>> Hello! >>> >>> This feature looks really useful in production if it's implemented >>> properly. >>> Some comments from my side how things could be extended in the future: >>> >>> Group selection (also read: table-based/parametric-based selection!) >>> seems like a great feature and the step towards physical design reuse >>> (PDR). >>> With some intelligent grouping of routed components and >>> automatic/assisted selection of components based on netlist-topology >>> (or manual or table based selection) it is possible to create a >>> physical design reuse (or channels) by duplicating groups with the >>> same layout but different component references + different net names / >>> instances of net names. >>> An additional approach is intelligent "group editing" (table based - a >>> must have for complex designs!) where there is an automatic / assisted >>> rename of components and netnames to create reuses. This also applies >>> to the schematic entry, obviously. >>> >>> The word "intelligent" above means obviously, that there is some >>> infrastructure and coding work to consider. >>> >>> An example screenshot of one of my designs using a buggy commercial >>> product is attached. There are 60 similar channels. >>> Layouting these manually would be a hell of work, obviously. >>> >>> Regards, >>> >>> Clemens >>> >>> >>> On 2017-01-12 17:37, Wayne Stambaugh wrote: >>>> I think this feature would be useful but we should proceed with caution >>>> if we are going to include persistence. I'm guessing making groups >>>> persistent will require a change to the pcb file format. We should >>>> think this through thoroughly before moving forward. Is it possible >>>> that this grouping could be used for an a****m like room feature? If >>>> so, than we need to plan this out accordingly rather than just commit a >>>> new feature for the sake of convenience. >>>> >>>> On 1/12/2017 6:55 AM, Tomasz Wlostowski wrote: >>>>> I like it. Give me a few days to review it and I hope it will get >>>>> merged. You'll also have to make the groups persistent (save to file). >>>>> Recursive grouping (group of groups) would be also an advantage. >>>>> >>>>> >>>>> Cheers, >>>>> Tom >>>>> >>>>> Sent from my Samsung Galaxy smartphone. >>>>> >>>>> >>>>> -------- Original message -------- >>>>> From: Kristoffer Ödmark <[email protected]> >>>>> Date: 12/01/2017 12:41 (GMT+01:00) >>>>> To: [email protected] >>>>> Subject: Re: [Kicad-developers] Group selection idea >>>>> >>>>> Hey again, What would be the chances of seing this getting into the >>>>> master branches on launchpad, what would I have to add/change to get it >>>>> there? >>>>> >>>>> - Kristoffer >>>>> >>>>> On 2017-01-11 21:59, Kristoffer Ödmark wrote: >>>>>> Attaching Patch! >>>>>> >>>>>> ( Thanks Chris! ) >>>>>> >>>>>> On 2017-01-11 20:51, Kristoffer Ödmark wrote: >>>>>>> Hello! >>>>>>> >>>>>>> I hacked together a group selection concept looking like this: >>>>>>> https://youtu.be/eJp-aJ8i0H4 >>>>>>> >>>>>>> It can assign BOARD_ITEM to a specific group for easier selection and >>>>>>> group manipulation. I am open to suggestions on changes, this is >>>>>>> surely >>>>>>> not an optimal implementation. >>>>>>> >>>>>>> Useful when you may want to keep the relative position of >>>>>>> something on >>>>>>> the board like maybe a RF layout etc. >>>>>>> >>>>>>> It cannot currently save the group assignments between sessions, >>>>>>> since >>>>>>> that would require some changes to the file format. That would >>>>>>> need some >>>>>>> agreement that this is indeed wanted. >>>>>>> >>>>>>> it also doesnt work on zones right now. >>>>>>> >>>>>>> ps: I do not now the best way to attach a patch file. >>>>>>> I added my feature >>>>>>> commit >>>>>>> git pull >>>>>>> fix conflict >>>>>>> commit >>>>>>> >>>>>>> Anyone have any steps on how to get one patch file for this, now I >>>>>>> got >>>>>>> one patch file, and a merge. >>>>>>> >>>>>>> - 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
