kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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
>

Attachment: signature.asc
Description: OpenPGP digital signature