kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

I have confirmed that there are no technical challenges with the migration
plan proposed by Orson.
I made some quick test code that automatically performs the migration
silently (i.e. by choosing a label randomly from the available ones to keep)
Before I go too far down this path (i.e. making a nice GUI for the
migration that lets the user control it, etc), does anyone have any other
concerns with this?
JP, maybe you either created this feature or remember its creation, do you
have any input?

Thanks,
Jon

On Mon, Apr 16, 2018 at 9:48 AM, Jon Evans <jon@xxxxxxxxxxxxx> wrote:

> I think the logic you describe wouldn't be too bad to implement.
> I already have logic that collects all of the labels attached to a bus
> subgraph (an set of visually-connected bus wires)
> I could just split the bus name from the vector numbers, figure out what
> the size of the output vector should be, and propose a new name to the user.
> I guess it would need a dialog box because the user should get to choose
> what name comes out (there might not always be an obvious "winner", for
> example if each of the three buses in the example had the same width)
>
> If everyone else is on board with this approach, I'll make a test
> implementation to share.
>
> -Jon
>
> On Mon, Apr 16, 2018 at 9:39 AM, Maciej Sumiński <maciej.suminski@xxxxxxx>
> wrote:
>
>> I agree this a slightly confusing feature, which requires reading the
>> user manual to discover. I vote for removal, but we need a clever
>> migration plan to do so.
>>
>> I am not sure how easy would it be to implement it, but how about the
>> following automatic fix:
>> - determine the superset of connected buses (PCA[0..15] in the user
>> manual example)
>> - determine the other bus names (ADR[0..7] and BUS[5..10])
>> - rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)
>>
>> I believe such method keeps the connectivity data intact. Obviously it
>> would have to be approved by the user, no silent changes.
>>
>> Cheers,
>> Orson
>>
>> On 04/16/2018 05:05 AM, Jon Evans wrote:
>> > I thought about various ways that we could actually make this feature
>> work,
>> > but the more I thought about it, the more I thought that we would be
>> > bending over backwards to support something that shouldn't exist in the
>> > first place (in my opinion).
>> >
>> > Does anyone have a justification for this feature existing?  I'm not
>> trying
>> > to sound negative here, but if there is no benefit to it, and
>> eliminating
>> > it makes the rest of the behavior simpler to code and more logical and
>> > consistent, we should choose that path.
>> > If an ERC is not enough of a migration, we could also give a more
>> specific
>> > one-time nag dialog telling the user in detail what they are going to
>> have
>> > to do to fix their buses.
>> >
>> >
>> > -Jon
>> >
>> > On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand <
>> seth.hillbrand@xxxxxxxxx>
>> > wrote:
>> >
>> >> Hi Jon-
>> >>
>> >> The major issue I think we would need to address is migration.  I don't
>> >> think that only an ERC warning is sufficient in this case.  Users will
>> >> rightfully expect that their old schematics will generate valid
>> netlists
>> >> when opened in a newer KiCad.
>> >>
>> >> One option here would be to translate the implicit net connections into
>> >> explicit ones when bus junctions are encountered.   Unfortunately, I
>> think
>> >> that this feature is lightly used, so we might not get much user
>> feedback
>> >> until they encounter problems and then the problems will be very bad
>> >>
>> >> An alternative might be to increase the functionality of the bus
>> >> junction.  Spitballing here but we might add a "mapping table" dialog
>> that
>> >> allowed the user to specify the winning name and mapping order.  That
>> >> should address your points 2-3 although point 4 might be the issue.  I
>> >> think we could have a default mapping that follows the expected
>> convention
>> >> but allow users to change it by double-clicking on the junction and
>> editing
>> >> the mapping table.  Then previous users could keep their functionality
>> >> while still allowing the arbitrary member arrays you are building.
>> >>
>> >> Thoughts?
>> >> -S
>> >>
>> >>
>> >> 2018-04-15 16:40 GMT-07:00 Jon Evans <jon@xxxxxxxxxxxxx>:
>> >>
>> >>> Hi all,
>> >>>
>> >>> I am proposing to remove some behavior from KiCad as part of my bus
>> >>> connections changes.  I know we generally don't remove features in new
>> >>> releases without good reason, but I think this is an exceptional case.
>> >>>
>> >>> The user manual describes a way in which you can connect multiple
>> >>> different buses together with junctions.  If you aren't already
>> familiar
>> >>> with this behavior, please check out the manual:
>> >>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
>> >>> s-labels-power-ports
>> >>>
>> >>> The section in question is called "Global connections between buses"
>> and
>> >>> comes with the following image and describes how these bus wires with
>> >>> different labels are connected together:
>> >>>
>> >>> Allowing this kind of behavior is problematic for a number of reasons:
>> >>>
>> >>> 1. It means that net wires and bus wires behave differently, since net
>> >>> wires can't have more than one label.  This is potentially confusing
>> for
>> >>> users.
>> >>>
>> >>> 2. It means that junctions need a lot of special logic in order to
>> >>> resolve which "branch" of a bus is called what name (for example,
>> what if
>> >>> one of those three branches in the above image didn't have a label?
>> What
>> >>> would its nets be called?)
>> >>>
>> >>> 3. Maybe most importantly, it breaks the label->netlist paradigm,
>> since
>> >>> an electrical net will only have one label in the eventual netlist,
>> and
>> >>> there is no way to determine which label should "win"
>> >>>
>> >>> 4. I don't think there's a way to map this behavior onto the new bus
>> >>> system I have built that allows arbitrary bus members (instead of
>> just a
>> >>> sequential vector) in a way that would make any sense to the user.
>> >>>
>> >>> My proposed changes in this area are as follows:
>> >>>
>> >>> 1. Remove this section from the user manual.
>> >>>
>> >>> 2. In my new connectivity algorithm, treat all connected bus wire
>> >>> segments as being part of the same bus (meaning they all will have
>> the same
>> >>> "name")
>> >>>
>> >>> 3. Add an ERC warning about having more than one label attached to a
>> bus
>> >>> (the warning would appear in the case of the example picture above)
>> >>>
>> >>> 4. Add a note to the user manual stating that this warning is new for
>> 6.0
>> >>>
>> >>> The only downside that I can see in this approach is that any users
>> who
>> >>> relied on this feature will suddenly get new ERC warnings.  But I
>> think
>> >>> that this is an "anti-feature" in that it creates confusion instead of
>> >>> adding value, so we should nudge anyone who uses it towards a
>> different
>> >>> approach.
>> >>>
>> >>> Anyone see any issues with this plan?
>> >>>
>> >>> Thanks,
>> >>> -Jon
>> >>>
>> >>> _______________________________________________
>> >>> 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
>>
>>
>