Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Reece R. Pollack]

Thanks, Maciej. Are you going to get me a pony too? :-)

Orson's proposal looks grand, as long as I can add existing nets/buses 
to a new bus, rather than having to define the big bus and its members 
first and then create aliases for the bus members.


On 04/20/18 11:18, Maciej Sumiński wrote:

Hi Reece,

Have a look at an earlier message regarding bus upgrades [1].

Cheers,
Orson

1. https://lists.launchpad.net/kicad-developers/msg32423.html

On 04/20/2018 05:15 PM, Reece R. Pollack wrote:

Let's not forget the pending wishlist item Bug #1419146
 to support buses of
named members.

You shouldn't have to remember that I2C_DATA is better known as I2C_0
and I2C_CLOCK is I2C_1. Or was I2C_CLOCK = I2C_0 and I2C_DATA = I2C_1?

Extending this idea so a bus can contain another bus makes sense. Let's
take an LCD display. In addition to the 4 or 8 data lines, there are
several control lines that should be part of the bus. I want an LCD bus
that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And
while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it
named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.

-Reece

On 04/15/18 22:39, Seth Hillbrand 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 >:

     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 

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Maciej Sumiński]

Hi Reece,

Have a look at an earlier message regarding bus upgrades [1].

Cheers,
Orson

1. https://lists.launchpad.net/kicad-developers/msg32423.html

On 04/20/2018 05:15 PM, Reece R. Pollack wrote:
> Let's not forget the pending wishlist item Bug #1419146
>  to support buses of
> named members.
> 
> You shouldn't have to remember that I2C_DATA is better known as I2C_0
> and I2C_CLOCK is I2C_1. Or was I2C_CLOCK = I2C_0 and I2C_DATA = I2C_1?
> 
> Extending this idea so a bus can contain another bus makes sense. Let's
> take an LCD display. In addition to the 4 or 8 data lines, there are
> several control lines that should be part of the bus. I want an LCD bus
> that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And
> while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it
> named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.
> 
> -Reece
> 
> On 04/15/18 22:39, Seth Hillbrand 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 > >:
>>
>>     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 

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Reece R. Pollack]

Let's not forget the pending wishlist item Bug #1419146 
 to support buses of 
named members.


You shouldn't have to remember that I2C_DATA is better known as I2C_0 
and I2C_CLOCK is I2C_1. Or was I2C_CLOCK = I2C_0 and I2C_DATA = I2C_1?


Extending this idea so a bus can contain another bus makes sense. Let's 
take an LCD display. In addition to the 4 or 8 data lines, there are 
several control lines that should be part of the bus. I want an LCD bus 
that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And 
while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it 
named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.


-Reece

On 04/15/18 22:39, Seth Hillbrand 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 >:


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@lists.launchpad.net

Unsubscribe : https://launchpad.net/~kicad-developers

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[jp charras]

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

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Jon Evans]

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?

Thanks,
Jon

On Mon, Apr 16, 2018 at 9:48 AM, Jon Evans  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 
> 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>
>> > 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 :
>> >>
>> >>> 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 

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Jon Evans]

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

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Wayne Stambaugh]

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

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Maciej Sumiński]

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

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Jon Evans]

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

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Seth Hillbrand]

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 :

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

[Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Jon Evans]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp