kicad-developers team mailing list archive

[Seth Hillbrand <seth.hillbrand@xxxxxxxxx>]

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