Le 17/04/2018 à 04:41, Jon Evans a écrit : > I have confirmed that there are no technical challenges with the migration > plan proposed by Orson. > I made some quick test code that automatically performs the migration > silently (i.e. by choosing a > label randomly from the available ones to keep) > Before I go too far down this path (i.e. making a nice GUI for the migration > that lets the user > control it, etc), does anyone have any other concerns with this? > JP, maybe you either created this feature or remember its creation, do you > have any input?
There is a long time since I wrote it, but I am thinking this feature is just a side effect of the fact the netlist handles bus connection between hierarchical sheets: When the bus XX[0..8] is connected to the pin sheet ZZ[0..8], the connection is made between 2 bus with different names. This is very similar to your sample. A similar case is connecting 2 different labels by the same wire: this is a common case with hierarchical sheets and/or global label like hidden power input pins (that are a type of global label) > > Thanks, > Jon > > On Mon, Apr 16, 2018 at 9:48 AM, Jon Evans <j...@craftyjon.com > <mailto:j...@craftyjon.com>> wrote: > > I think the logic you describe wouldn't be too bad to implement. > I already have logic that collects all of the labels attached to a bus > subgraph (an set of > visually-connected bus wires) > I could just split the bus name from the vector numbers, figure out what > the size of the output > vector should be, and propose a new name to the user. > I guess it would need a dialog box because the user should get to choose > what name comes out > (there might not always be an obvious "winner", for example if each of > the three buses in the > example had the same width) > > If everyone else is on board with this approach, I'll make a test > implementation to share. > > -Jon > > On Mon, Apr 16, 2018 at 9:39 AM, Maciej Sumiński <maciej.sumin...@cern.ch > <mailto:maciej.sumin...@cern.ch>> 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 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 > <mailto: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 > <mailto: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 > <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 -- Jean-Pierre CHARRAS _______________________________________________ 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
