Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Maciej Suminski]

Alright, I have just pushed the patch.

Cheers,
Orson

On 05/18/2018 08:47 PM, Wayne Stambaugh wrote:
> You patch seems like a reasonable approach as an interim fix.  Go ahead
> and merge it when you get a chance.
> 
> Cheers,
> 
> Wayne
> 
> On 05/18/2018 10:52 AM, Maciej Sumiński wrote:
>> How about my patch? I do not dare to go for the ultimate solution right
>> now, but is it acceptable as a stop gap measure for v5?
>>
>> Cheers,
>> Orson
>>
>> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
>>> The suggestions made are all good and valid but I think to some extent
>>> there will always be some ambiguity.  Users being users will make
>>> mistakes filling in field data which will cause issues when annotating
>>> and generating the netlist.  In complex designs with lots of multiple
>>> units symbols it's not always possible to know which units should be
>>> grouped together by reference.  More often that not, this cannot be
>>> known until board layout time.  This is something that I am all to
>>> familiar with because I do lots of designs with several dual and quad
>>> op-amps.  I don't think we will ever be able to completely do this
>>> without some ambiguity until some type of human brain interface is
>>> created to allow us to know what the user wants versus what the user
>>> specified.
>>>
>>> That being said, I suggest we define the behavior we want before we
>>> start coding so there is no ambiguity it what we hope to accomplish.  A
>>> simple bulleted list would be fine.  Once we define the desired
>>> behavior, we should get some user input so that we don't create
>>> something that doesn't work well for users.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 05/18/2018 08:44 AM, Jeff Young wrote:
 Hi Orson,

 The problem should become less prevalent over time: for 6.0 I plan on 
 fixing the multi-sheet undo issues so that we can update all units in 
 unison.  (Of course that still fails if you edit before annotating as we 
 then don’t know which units go with which.)

 But I agree that anytime we have a non-matching field across units it 
 looks like a bug to the user.  Your proposal is certainly an improvement 
 in that regard.

 I think the one thing that would be left would be to flag unit field 
 mismatches when annotating (or perhaps even try and group units by 
 matching their fields).  But that carries enough risk to relegate it to 
 6.0 along with the undo stuff.

 Cheers,
 Jeff.


> On 18 May 2018, at 12:16, Sergey A. Borshch  
> wrote:
>
> On 18.05.2018 11:14, Maciej Sumiński wrote:
>> Hi,
>> Recently I have found out that the netlist exporter uses an algorithm
>> that for multiunit components uses non empty field values from the last
>> processed unit [1]. The problem is that the processing order depends on
>> the order of the units in the item list, so completely random.
> I want to remind that there is another bug in netlist generator related 
> to units processing order: https://bugs.launchpad.net/bugs/1704083
>
>> Instead, I propose we try to get all field values from the first
>> available unit (e.g. unit A), and resort to other units only if there
>> are any fields left empty.
>>
>> To give an example of what can go wrong with such approach: recently I
>> generated BOM and assembly documentation, where unit A had 'Mounted'
>> field set to 'No'. I was surprised to find out that in the generated
>> output it has been marked as mounted, as the unit B had 'Yes' set for
>> the field. I would qualify it as a bug, but I seek your input before I
>> proceed with pushing my changes. See my proposal in the attached patch.
> I think there no need in Artificial Intelligence while generating netlist 
> from incorrect schematics, but all fields in component units must be 
> consistent instead. I mean that changing in schematics editor any field 
> in one unit must also change same field in other units with same RefDes. 
> Automatic annotation must take into account all fields values and assign 
> different RefDes to units which differs with fields values.
> One more proposal - manual RefDes change shoud not be allowed with 
> appropriate warning if unit(s) with new RefDes already exist in 
> schematics and belongs to another component type or has different fields 
> value(s). It would be best helpful if warning message will show that 
> units belongs to different component types or which field value differs 
> if component type is the same.
>
>
> -- 
> Regards,
>  Sergey A. Borshchmailto: sb...@sourceforge.net
>SB ELDI ltd. Riga, Latvia
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Wayne Stambaugh]

You patch seems like a reasonable approach as an interim fix.  Go ahead
and merge it when you get a chance.

Cheers,

Wayne

On 05/18/2018 10:52 AM, Maciej Sumiński wrote:
> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
> 
> Cheers,
> Orson
> 
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
>> The suggestions made are all good and valid but I think to some extent
>> there will always be some ambiguity.  Users being users will make
>> mistakes filling in field data which will cause issues when annotating
>> and generating the netlist.  In complex designs with lots of multiple
>> units symbols it's not always possible to know which units should be
>> grouped together by reference.  More often that not, this cannot be
>> known until board layout time.  This is something that I am all to
>> familiar with because I do lots of designs with several dual and quad
>> op-amps.  I don't think we will ever be able to completely do this
>> without some ambiguity until some type of human brain interface is
>> created to allow us to know what the user wants versus what the user
>> specified.
>>
>> That being said, I suggest we define the behavior we want before we
>> start coding so there is no ambiguity it what we hope to accomplish.  A
>> simple bulleted list would be fine.  Once we define the desired
>> behavior, we should get some user input so that we don't create
>> something that doesn't work well for users.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 05/18/2018 08:44 AM, Jeff Young wrote:
>>> Hi Orson,
>>>
>>> The problem should become less prevalent over time: for 6.0 I plan on 
>>> fixing the multi-sheet undo issues so that we can update all units in 
>>> unison.  (Of course that still fails if you edit before annotating as we 
>>> then don’t know which units go with which.)
>>>
>>> But I agree that anytime we have a non-matching field across units it looks 
>>> like a bug to the user.  Your proposal is certainly an improvement in that 
>>> regard.
>>>
>>> I think the one thing that would be left would be to flag unit field 
>>> mismatches when annotating (or perhaps even try and group units by matching 
>>> their fields).  But that carries enough risk to relegate it to 6.0 along 
>>> with the undo stuff.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
 On 18 May 2018, at 12:16, Sergey A. Borshch  
 wrote:

 On 18.05.2018 11:14, Maciej Sumiński wrote:
> Hi,
> Recently I have found out that the netlist exporter uses an algorithm
> that for multiunit components uses non empty field values from the last
> processed unit [1]. The problem is that the processing order depends on
> the order of the units in the item list, so completely random.
 I want to remind that there is another bug in netlist generator related to 
 units processing order: https://bugs.launchpad.net/bugs/1704083

> Instead, I propose we try to get all field values from the first
> available unit (e.g. unit A), and resort to other units only if there
> are any fields left empty.
>
> To give an example of what can go wrong with such approach: recently I
> generated BOM and assembly documentation, where unit A had 'Mounted'
> field set to 'No'. I was surprised to find out that in the generated
> output it has been marked as mounted, as the unit B had 'Yes' set for
> the field. I would qualify it as a bug, but I seek your input before I
> proceed with pushing my changes. See my proposal in the attached patch.
 I think there no need in Artificial Intelligence while generating netlist 
 from incorrect schematics, but all fields in component units must be 
 consistent instead. I mean that changing in schematics editor any field in 
 one unit must also change same field in other units with same RefDes. 
 Automatic annotation must take into account all fields values and assign 
 different RefDes to units which differs with fields values.
 One more proposal - manual RefDes change shoud not be allowed with 
 appropriate warning if unit(s) with new RefDes already exist in schematics 
 and belongs to another component type or has different fields value(s). It 
 would be best helpful if warning message will show that units belongs to 
 different component types or which field value differs if component type 
 is the same.


 -- 
 Regards,
  Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia


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

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[jp charras]

Le 18/05/2018 à 17:35, Kristoffer Ödmark a écrit :
> I think another stop gap measure is to have the ERC handle this, but 
> otherwise I am for Orson's patch. 

This is also my opinion.
And Orson's patch is very acceptable.

> 
> Better a defined bad behavior than an undefined random behavior is my opinion 
> :)
> 
> On Fri, May 18, 2018, 16:53 Maciej Sumiński  > wrote:
> 
> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
> 
> Cheers,
> Orson
> 
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> > The suggestions made are all good and valid but I think to some extent
> > there will always be some ambiguity.  Users being users will make
> > mistakes filling in field data which will cause issues when annotating
> > and generating the netlist.  In complex designs with lots of multiple
> > units symbols it's not always possible to know which units should be
> > grouped together by reference.  More often that not, this cannot be
> > known until board layout time.  This is something that I am all to
> > familiar with because I do lots of designs with several dual and quad
> > op-amps.  I don't think we will ever be able to completely do this
> > without some ambiguity until some type of human brain interface is
> > created to allow us to know what the user wants versus what the user
> > specified.
> >
> > That being said, I suggest we define the behavior we want before we
> > start coding so there is no ambiguity it what we hope to accomplish.  A
> > simple bulleted list would be fine.  Once we define the desired
> > behavior, we should get some user input so that we don't create
> > something that doesn't work well for users.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 05/18/2018 08:44 AM, Jeff Young wrote:
> >> Hi Orson,
> >>
> >> The problem should become less prevalent over time: for 6.0 I plan on 
> fixing the multi-sheet
> undo issues so that we can update all units in unison.  (Of course that 
> still fails if you edit
> before annotating as we then don’t know which units go with which.)
> >>
> >> But I agree that anytime we have a non-matching field across units it 
> looks like a bug to the
> user.  Your proposal is certainly an improvement in that regard.
> >>
> >> I think the one thing that would be left would be to flag unit field 
> mismatches when
> annotating (or perhaps even try and group units by matching their 
> fields).  But that carries
> enough risk to relegate it to 6.0 along with the undo stuff.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 18 May 2018, at 12:16, Sergey A. Borshch 
>  > wrote:
> >>>
> >>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>  Hi,
>  Recently I have found out that the netlist exporter uses an algorithm
>  that for multiunit components uses non empty field values from the 
> last
>  processed unit [1]. The problem is that the processing order depends 
> on
>  the order of the units in the item list, so completely random.
> >>> I want to remind that there is another bug in netlist generator 
> related to units processing
> order: https://bugs.launchpad.net/bugs/1704083
> >>>
>  Instead, I propose we try to get all field values from the first
>  available unit (e.g. unit A), and resort to other units only if there
>  are any fields left empty.
> 
>  To give an example of what can go wrong with such approach: recently 
> I
>  generated BOM and assembly documentation, where unit A had 'Mounted'
>  field set to 'No'. I was surprised to find out that in the generated
>  output it has been marked as mounted, as the unit B had 'Yes' set for
>  the field. I would qualify it as a bug, but I seek your input before 
> I
>  proceed with pushing my changes. See my proposal in the attached 
> patch.
> >>> I think there no need in Artificial Intelligence while generating 
> netlist from incorrect
> schematics, but all fields in component units must be consistent instead. 
> I mean that changing
> in schematics editor any field in one unit must also change same field in 
> other units with same
> RefDes. Automatic annotation must take into account all fields values and 
> assign different
> RefDes to units which differs with fields values.
> >>> One more proposal - manual RefDes change shoud not be allowed with 
> appropriate warning if
> unit(s) with new RefDes already exist in schematics and belongs to 
> another component type or has
> different fields value(s). It would be best helpful if warning message 
> will show 

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Kristoffer Ödmark]

I think another stop gap measure is to have the ERC handle this, but
otherwise I am for Orsons patch.

Better a defined bad behavior than an undefined random behavior is my
opinion :)

On Fri, May 18, 2018, 16:53 Maciej Sumiński  wrote:

> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
>
> Cheers,
> Orson
>
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> > The suggestions made are all good and valid but I think to some extent
> > there will always be some ambiguity.  Users being users will make
> > mistakes filling in field data which will cause issues when annotating
> > and generating the netlist.  In complex designs with lots of multiple
> > units symbols it's not always possible to know which units should be
> > grouped together by reference.  More often that not, this cannot be
> > known until board layout time.  This is something that I am all to
> > familiar with because I do lots of designs with several dual and quad
> > op-amps.  I don't think we will ever be able to completely do this
> > without some ambiguity until some type of human brain interface is
> > created to allow us to know what the user wants versus what the user
> > specified.
> >
> > That being said, I suggest we define the behavior we want before we
> > start coding so there is no ambiguity it what we hope to accomplish.  A
> > simple bulleted list would be fine.  Once we define the desired
> > behavior, we should get some user input so that we don't create
> > something that doesn't work well for users.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 05/18/2018 08:44 AM, Jeff Young wrote:
> >> Hi Orson,
> >>
> >> The problem should become less prevalent over time: for 6.0 I plan on
> fixing the multi-sheet undo issues so that we can update all units in
> unison.  (Of course that still fails if you edit before annotating as we
> then don’t know which units go with which.)
> >>
> >> But I agree that anytime we have a non-matching field across units it
> looks like a bug to the user.  Your proposal is certainly an improvement in
> that regard.
> >>
> >> I think the one thing that would be left would be to flag unit field
> mismatches when annotating (or perhaps even try and group units by matching
> their fields).  But that carries enough risk to relegate it to 6.0 along
> with the undo stuff.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 18 May 2018, at 12:16, Sergey A. Borshch <
> sb...@users.sourceforge.net> wrote:
> >>>
> >>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>  Hi,
>  Recently I have found out that the netlist exporter uses an algorithm
>  that for multiunit components uses non empty field values from the
> last
>  processed unit [1]. The problem is that the processing order depends
> on
>  the order of the units in the item list, so completely random.
> >>> I want to remind that there is another bug in netlist generator
> related to units processing order: https://bugs.launchpad.net/bugs/1704083
> >>>
>  Instead, I propose we try to get all field values from the first
>  available unit (e.g. unit A), and resort to other units only if there
>  are any fields left empty.
> 
>  To give an example of what can go wrong with such approach: recently I
>  generated BOM and assembly documentation, where unit A had 'Mounted'
>  field set to 'No'. I was surprised to find out that in the generated
>  output it has been marked as mounted, as the unit B had 'Yes' set for
>  the field. I would qualify it as a bug, but I seek your input before I
>  proceed with pushing my changes. See my proposal in the attached
> patch.
> >>> I think there no need in Artificial Intelligence while generating
> netlist from incorrect schematics, but all fields in component units must
> be consistent instead. I mean that changing in schematics editor any field
> in one unit must also change same field in other units with same RefDes.
> Automatic annotation must take into account all fields values and assign
> different RefDes to units which differs with fields values.
> >>> One more proposal - manual RefDes change shoud not be allowed with
> appropriate warning if unit(s) with new RefDes already exist in schematics
> and belongs to another component type or has different fields value(s). It
> would be best helpful if warning message will show that units belongs to
> different component types or which field value differs if component type is
> the same.
> >>>
> >>>
> >>> --
> >>> Regards,
> >>>  Sergey A. Borshchmailto: sb...@sourceforge.net
> >>>SB ELDI ltd. Riga, Latvia
> >>>
> >>>
> >>> ___
> >>> 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
> >>
> 

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Maciej Sumiński]

How about my patch? I do not dare to go for the ultimate solution right
now, but is it acceptable as a stop gap measure for v5?

Cheers,
Orson

On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> The suggestions made are all good and valid but I think to some extent
> there will always be some ambiguity.  Users being users will make
> mistakes filling in field data which will cause issues when annotating
> and generating the netlist.  In complex designs with lots of multiple
> units symbols it's not always possible to know which units should be
> grouped together by reference.  More often that not, this cannot be
> known until board layout time.  This is something that I am all to
> familiar with because I do lots of designs with several dual and quad
> op-amps.  I don't think we will ever be able to completely do this
> without some ambiguity until some type of human brain interface is
> created to allow us to know what the user wants versus what the user
> specified.
> 
> That being said, I suggest we define the behavior we want before we
> start coding so there is no ambiguity it what we hope to accomplish.  A
> simple bulleted list would be fine.  Once we define the desired
> behavior, we should get some user input so that we don't create
> something that doesn't work well for users.
> 
> Cheers,
> 
> Wayne
> 
> On 05/18/2018 08:44 AM, Jeff Young wrote:
>> Hi Orson,
>>
>> The problem should become less prevalent over time: for 6.0 I plan on fixing 
>> the multi-sheet undo issues so that we can update all units in unison.  (Of 
>> course that still fails if you edit before annotating as we then don’t know 
>> which units go with which.)
>>
>> But I agree that anytime we have a non-matching field across units it looks 
>> like a bug to the user.  Your proposal is certainly an improvement in that 
>> regard.
>>
>> I think the one thing that would be left would be to flag unit field 
>> mismatches when annotating (or perhaps even try and group units by matching 
>> their fields).  But that carries enough risk to relegate it to 6.0 along 
>> with the undo stuff.
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 18 May 2018, at 12:16, Sergey A. Borshch  
>>> wrote:
>>>
>>> On 18.05.2018 11:14, Maciej Sumiński wrote:
 Hi,
 Recently I have found out that the netlist exporter uses an algorithm
 that for multiunit components uses non empty field values from the last
 processed unit [1]. The problem is that the processing order depends on
 the order of the units in the item list, so completely random.
>>> I want to remind that there is another bug in netlist generator related to 
>>> units processing order: https://bugs.launchpad.net/bugs/1704083
>>>
 Instead, I propose we try to get all field values from the first
 available unit (e.g. unit A), and resort to other units only if there
 are any fields left empty.

 To give an example of what can go wrong with such approach: recently I
 generated BOM and assembly documentation, where unit A had 'Mounted'
 field set to 'No'. I was surprised to find out that in the generated
 output it has been marked as mounted, as the unit B had 'Yes' set for
 the field. I would qualify it as a bug, but I seek your input before I
 proceed with pushing my changes. See my proposal in the attached patch.
>>> I think there no need in Artificial Intelligence while generating netlist 
>>> from incorrect schematics, but all fields in component units must be 
>>> consistent instead. I mean that changing in schematics editor any field in 
>>> one unit must also change same field in other units with same RefDes. 
>>> Automatic annotation must take into account all fields values and assign 
>>> different RefDes to units which differs with fields values.
>>> One more proposal - manual RefDes change shoud not be allowed with 
>>> appropriate warning if unit(s) with new RefDes already exist in schematics 
>>> and belongs to another component type or has different fields value(s). It 
>>> would be best helpful if warning message will show that units belongs to 
>>> different component types or which field value differs if component type is 
>>> the same.
>>>
>>>
>>> -- 
>>> Regards,
>>>  Sergey A. Borshchmailto: sb...@sourceforge.net
>>>SB ELDI ltd. Riga, Latvia
>>>
>>>
>>> ___
>>> 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: 

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Wayne Stambaugh]

The suggestions made are all good and valid but I think to some extent
there will always be some ambiguity.  Users being users will make
mistakes filling in field data which will cause issues when annotating
and generating the netlist.  In complex designs with lots of multiple
units symbols it's not always possible to know which units should be
grouped together by reference.  More often that not, this cannot be
known until board layout time.  This is something that I am all to
familiar with because I do lots of designs with several dual and quad
op-amps.  I don't think we will ever be able to completely do this
without some ambiguity until some type of human brain interface is
created to allow us to know what the user wants versus what the user
specified.

That being said, I suggest we define the behavior we want before we
start coding so there is no ambiguity it what we hope to accomplish.  A
simple bulleted list would be fine.  Once we define the desired
behavior, we should get some user input so that we don't create
something that doesn't work well for users.

Cheers,

Wayne

On 05/18/2018 08:44 AM, Jeff Young wrote:
> Hi Orson,
> 
> The problem should become less prevalent over time: for 6.0 I plan on fixing 
> the multi-sheet undo issues so that we can update all units in unison.  (Of 
> course that still fails if you edit before annotating as we then don’t know 
> which units go with which.)
> 
> But I agree that anytime we have a non-matching field across units it looks 
> like a bug to the user.  Your proposal is certainly an improvement in that 
> regard.
> 
> I think the one thing that would be left would be to flag unit field 
> mismatches when annotating (or perhaps even try and group units by matching 
> their fields).  But that carries enough risk to relegate it to 6.0 along with 
> the undo stuff.
> 
> Cheers,
> Jeff.
> 
> 
>> On 18 May 2018, at 12:16, Sergey A. Borshch  
>> wrote:
>>
>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>>> Hi,
>>> Recently I have found out that the netlist exporter uses an algorithm
>>> that for multiunit components uses non empty field values from the last
>>> processed unit [1]. The problem is that the processing order depends on
>>> the order of the units in the item list, so completely random.
>> I want to remind that there is another bug in netlist generator related to 
>> units processing order: https://bugs.launchpad.net/bugs/1704083
>>
>>> Instead, I propose we try to get all field values from the first
>>> available unit (e.g. unit A), and resort to other units only if there
>>> are any fields left empty.
>>>
>>> To give an example of what can go wrong with such approach: recently I
>>> generated BOM and assembly documentation, where unit A had 'Mounted'
>>> field set to 'No'. I was surprised to find out that in the generated
>>> output it has been marked as mounted, as the unit B had 'Yes' set for
>>> the field. I would qualify it as a bug, but I seek your input before I
>>> proceed with pushing my changes. See my proposal in the attached patch.
>> I think there no need in Artificial Intelligence while generating netlist 
>> from incorrect schematics, but all fields in component units must be 
>> consistent instead. I mean that changing in schematics editor any field in 
>> one unit must also change same field in other units with same RefDes. 
>> Automatic annotation must take into account all fields values and assign 
>> different RefDes to units which differs with fields values.
>> One more proposal - manual RefDes change shoud not be allowed with 
>> appropriate warning if unit(s) with new RefDes already exist in schematics 
>> and belongs to another component type or has different fields value(s). It 
>> would be best helpful if warning message will show that units belongs to 
>> different component types or which field value differs if component type is 
>> the same.
>>
>>
>> -- 
>> Regards,
>>  Sergey A. Borshchmailto: sb...@sourceforge.net
>>SB ELDI ltd. Riga, Latvia
>>
>>
>> ___
>> 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

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Jeff Young]

Hi Orson,

The problem should become less prevalent over time: for 6.0 I plan on fixing 
the multi-sheet undo issues so that we can update all units in unison.  (Of 
course that still fails if you edit before annotating as we then don’t know 
which units go with which.)

But I agree that anytime we have a non-matching field across units it looks 
like a bug to the user.  Your proposal is certainly an improvement in that 
regard.

I think the one thing that would be left would be to flag unit field mismatches 
when annotating (or perhaps even try and group units by matching their fields). 
 But that carries enough risk to relegate it to 6.0 along with the undo stuff.

Cheers,
Jeff.


> On 18 May 2018, at 12:16, Sergey A. Borshch  
> wrote:
> 
> On 18.05.2018 11:14, Maciej Sumiński wrote:
>> Hi,
>> Recently I have found out that the netlist exporter uses an algorithm
>> that for multiunit components uses non empty field values from the last
>> processed unit [1]. The problem is that the processing order depends on
>> the order of the units in the item list, so completely random.
> I want to remind that there is another bug in netlist generator related to 
> units processing order: https://bugs.launchpad.net/bugs/1704083
> 
>> Instead, I propose we try to get all field values from the first
>> available unit (e.g. unit A), and resort to other units only if there
>> are any fields left empty.
> >
>> To give an example of what can go wrong with such approach: recently I
>> generated BOM and assembly documentation, where unit A had 'Mounted'
>> field set to 'No'. I was surprised to find out that in the generated
>> output it has been marked as mounted, as the unit B had 'Yes' set for
>> the field. I would qualify it as a bug, but I seek your input before I
>> proceed with pushing my changes. See my proposal in the attached patch.
> I think there no need in Artificial Intelligence while generating netlist 
> from incorrect schematics, but all fields in component units must be 
> consistent instead. I mean that changing in schematics editor any field in 
> one unit must also change same field in other units with same RefDes. 
> Automatic annotation must take into account all fields values and assign 
> different RefDes to units which differs with fields values.
> One more proposal - manual RefDes change shoud not be allowed with 
> appropriate warning if unit(s) with new RefDes already exist in schematics 
> and belongs to another component type or has different fields value(s). It 
> would be best helpful if warning message will show that units belongs to 
> different component types or which field value differs if component type is 
> the same.
> 
> 
> -- 
> Regards,
>  Sergey A. Borshchmailto: sb...@sourceforge.net
>SB ELDI ltd. Riga, Latvia
> 
> 
> ___
> 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

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Sergey A. Borshch]

On 18.05.2018 11:14, Maciej Sumiński wrote:

Hi,

Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item list, so completely random.
I want to remind that there is another bug in netlist generator related to units 
processing order: https://bugs.launchpad.net/bugs/1704083



Instead, I propose we try to get all field values from the first
available unit (e.g. unit A), and resort to other units only if there
are any fields left empty.

>

To give an example of what can go wrong with such approach: recently I
generated BOM and assembly documentation, where unit A had 'Mounted'
field set to 'No'. I was surprised to find out that in the generated
output it has been marked as mounted, as the unit B had 'Yes' set for
the field. I would qualify it as a bug, but I seek your input before I
proceed with pushing my changes. See my proposal in the attached patch.
I think there no need in Artificial Intelligence while generating netlist from 
incorrect schematics, but all fields in component units must be consistent 
instead. I mean that changing in schematics editor any field in one unit must 
also change same field in other units with same RefDes. Automatic annotation 
must take into account all fields values and assign different RefDes to units 
which differs with fields values.
 One more proposal - manual RefDes change shoud not be allowed with appropriate 
warning if unit(s) with new RefDes already exist in schematics and belongs to 
another component type or has different fields value(s). It would be best 
helpful if warning message will show that units belongs to different component 
types or which field value differs if component type is the same.



--
Regards,
  Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia


___
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] Indeterministic netlist export for multiunit components

[Maciej Sumiński]

Hi,

Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item list, so completely random.

Instead, I propose we try to get all field values from the first
available unit (e.g. unit A), and resort to other units only if there
are any fields left empty.

To give an example of what can go wrong with such approach: recently I
generated BOM and assembly documentation, where unit A had 'Mounted'
field set to 'No'. I was surprised to find out that in the generated
output it has been marked as mounted, as the unit B had 'Yes' set for
the field. I would qualify it as a bug, but I seek your input before I
proceed with pushing my changes. See my proposal in the attached patch.

There is a discussion regarding sharing the field values among all units
[2], but I see there is a technical problem preventing such solution
right now.

Cheers,
Orson

1.
https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/netlist_exporters/netlist_exporter_generic.cpp#L94
2. https://bugs.launchpad.net/bugs/1765771
From 6ee2a072853de33ab72e5874998bb2b49f22c981 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Thu, 17 May 2018 17:10:26 +0200
Subject: [PATCH] Deterministic algorithm for picking field values in multiunit
 components

The original algorithm picked the value from the last component having
non empty value for a given field, but the processing order was
dependent on the layout of the components in the memory. It means that
for each component, the field values could have been taken from any
unit, randomly.

The patch improves the algorithm, trying to get all values from the unit
with the lowest number and resorts to other units only when there are
field values left empty.
---
 .../netlist_exporters/netlist_exporter_generic.cpp | 31 ++
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/eeschema/netlist_exporters/netlist_exporter_generic.cpp b/eeschema/netlist_exporters/netlist_exporter_generic.cpp
index 9556b2a22..2cf4cbc06 100644
--- a/eeschema/netlist_exporters/netlist_exporter_generic.cpp
+++ b/eeschema/netlist_exporters/netlist_exporter_generic.cpp
@@ -91,17 +91,18 @@ void NETLIST_EXPORTER_GENERIC::addComponentFields( XNODE* xcomp, SCH_COMPONENT*
 {
 if( comp->GetUnitCount() > 1 )
 {
-// Sadly, each unit of a component can have its own unique fields.  This block
-// finds the last non blank field and records it.  Last guy wins and the order
-// of units occuring in a schematic hierarchy is variable.  Therefore user
-// is best off setting fields into only one unit.  But this scavenger algorithm
-// will find any non blank fields in all units and use the last non-blank field
+// Sadly, each unit of a component can have its own unique fields. This
+// block finds the unit with the lowest number having a non blank field
+// value and records it.  Therefore user is best off setting fields
+// into only the first unit.  But this scavenger algorithm will find
+// any non blank fields in all units and use the first non-blank field
 // for each unique field name.
 
 COMP_FIELDS fields;
 wxStringref = comp->GetRef( aSheet );
 
 SCH_SHEET_LIST sheetList( g_RootSheet );
+int minUnit = comp->GetUnit();
 
 for( unsigned i = 0;  i < sheetList.size();  i++ )
 {
@@ -117,26 +118,34 @@ void NETLIST_EXPORTER_GENERIC::addComponentFields( XNODE* xcomp, SCH_COMPONENT*
 if( ref2.CmpNoCase( ref ) != 0 )
 continue;
 
-// The last guy wins.  User should only set fields in any one unit.
+int unit = comp2->GetUnit();
+
+// The lowest unit number wins.  User should only set fields in any one unit.
 // remark: IsVoid() returns true for empty strings or the "~" string (empty field value)
-if( !comp2->GetField( VALUE )->IsVoid() )
+if( !comp2->GetField( VALUE )->IsVoid()
+&& ( unit < minUnit || fields.value.IsEmpty() ) )
 fields.value = comp2->GetField( VALUE )->GetText();
 
-if( !comp2->GetField( FOOTPRINT )->IsVoid() )
+if( !comp2->GetField( FOOTPRINT )->IsVoid()
+&& ( unit < minUnit || fields.footprint.IsEmpty() ) )
 fields.footprint = comp2->GetField( FOOTPRINT )->GetText();
 
-if( !comp2->GetField( DATASHEET )->IsVoid() )
+if( !comp2->GetField( DATASHEET )->IsVoid()
+&& ( unit < minUnit || fields.datasheet.IsEmpty() ) )
 fields.datasheet = comp2->GetField( DATASHEET )->GetText();
 
 for( int fldNdx =