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.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 >> > > > > > _______________________________________________ > 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