kicad-developers team mailing list archive

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

Hello!

The conceopt is amazing, the idea of realtime really intrigues me. parallels to how when I use vias, 
I have a component for them, and when for some reason I have to change the minium via size, then 
I just replace all instances of the VIA-0.25mm with another footprint VIA-0.30mm for example. 

How I would like to use PDR is similar to how I use footprints. Assign a layout to a schematic. 
Basically I would want a new type of "component/part/layout" that I can add to either schematic 
or pcbnew item. But instead of having a separate symbol and footprint, this would mean a file/folder
containing both a symbol and layout(s) ( .sweet + .pretty = .cake ? ), I will call them cakes from now on =) 

This way when updating the layout, It would be easy to propagate it to every other .cake object in 
the layout the same way you do with footprints, keeping the KiCAD workflow intact.

the functionality to link cakes together could be added on top of this, ex. select all of cake X type
and then select an option to mirror changes made to cake X, local to the PCB only. 

The way to create cakes could be all/any or either of the following.

To generate a .cake file/folder one would either select PCB objects, righ click and get a meny to create 
snippet/layout/cake from a menu, and this would then create a layout and a schematic from the selection.

another way would be to choose schematic symbols and then right click and generate snippet/layout/cake from that.

A third way would be to convert a kicad project into a snippet/cake/layout. 

- Kristoffer



On 2017-01-13 14:47, Clemens Koller wrote:
> 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 <kristofferodmark90@xxxxxxxxx>
>>>>>> Date: 12/01/2017 12:41 (GMT+01:00)
>>>>>> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
>>
> 
> _______________________________________________
> 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
>