kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

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
>