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.hillbr...@gmail.com> > 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 <j...@craftyjon.com>: >> >>> 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@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
