kicad-developers team mailing list archive

["Sergey A. Borshch" <sb-sf@xxxxxxxxxxxxxxxxxxxxx>]

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. Borshch            mailto: sb-sf@xxxxxxxxxxxxxxx
    SB ELDI ltd. Riga, Latvia