kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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