kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

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-sf@xxxxxxxxxxxxxxxxxxxxx> 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. Borshch            mailto: sb-sf@xxxxxxxxxxxxxxx
>    SB ELDI ltd. Riga, Latvia
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp