kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 4/16/2018 9:39 AM, Maciej Sumiński 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'm OK with removing this as well but we definitely need a migration
plan.  Users netlist connectivity should not be broken between versions
of KiCad.

> 
> 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)

This seems like a reasonable solution.

> 
> I believe such method keeps the connectivity data intact. Obviously it
> would have to be approved by the user, no silent changes.

This is also a must.  Users tend not to like things silently changed.  I
would consider using our message panel control in a dialog and show all
of the bus net 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
>