kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #35788
Re: Indeterministic netlist export for multiunit components
-
To:
<kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Maciej Sumiński <maciej.suminski@xxxxxxx>
-
Date:
Fri, 18 May 2018 16:52:22 +0200
-
Authentication-results:
spf=pass (sender IP is 188.184.36.50) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
-
Autocrypt:
addr=maciej.suminski@xxxxxxx; prefer-encrypt=mutual; keydata= xsBNBFKfmAwBCAC9tak+4mDO1WiNnAwegusPBMEdl+sV35XeaU4PGSt33mPSlXB2klamg4ih QUykvuWqNEg2KyTvCSKNfnHTpzeeFegEsIwWFdhbIc4uUAD6CHl4+uGTXQiMh1+IJkgLmwuD RCEx9mSKbdzzTKz05w+fzzT3mNfko8NICWlcmhFgo2RXnQRTqFg7CNNBpx4kr4+AWIvb+Rha AVMLVJj1s05+STGyFucu6sZmTmOC53ZtkV8HchJeGuQL0LPkjvX0VKGE3gkvuP4iLBcgFtNC Kcu/L6FmWd24m2IhWaHXoWLBiVFw7gGzUdB7gSAiNO1+SoWX+99rbud7RvqV49vOgoqbABEB AAHNKU1hY2llaiBTdW1pbnNraSA8bWFjaWVqLnN1bWluc2tpQGNlcm4uY2g+wsB5BBMBAgAj BQJSn5gMAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQFHAa7WGlsnU/JQf5AYW0 oFH+jOykZvlRkRZMoqw1vZGOHeRPK92vbjeiau/hALYX1FBvZMx+JMmVHN7DkRIY7bVoiJ6N n4Byn//BSd9F9eXjAphYVuBg2Xe5wp3/l9/z2Iw8KeLpfKAtfIybgpycvTuUxFIxm9mtpPt+ AoNFKBDhfLcpZLJTW7AwwpnzP+GDdjszjnW6rMt8Aq55liR+y/TZfz/tTEDcUcSPLlJBTmda TmkO5aPxPmeCeDMOT3YEd+bK57V5b7RgtqTdIT6CW7tjQKBPJbIGa8PQ0tUfz0yCBEPWghnY w+B/2JeArrRXDui78cGgTDy1ocQNAm3havk2WO2qykxziY6Owc7ATQRSn5gMAQgAxw+MRllT IPNnCeOAbRgX1KRzo7+7WpSIbmhrBzLY0O1SyIa7U05E6+4jDHDfDpSLqc61an1+M69e6l9Z E3ve3hymtj5ucXZQnveQ5klD6z5FBC/04of/YyrS+h6iRSM0nOmu1JOIqM0S2OzwsKRsS86r jCtRE5OxoBDCIB4xNPitezs4uvLoVfO3mVYUhiPRZMtTCInEi+tlM+AmaPjRkPAfhd0wsOjk oxkuJWEnZ8U8oHpeL0uqANZgLlIiT5yJMWsyyqlK01hdFbuIydIFFiyXJw1HDTXWX+tMxJrX VEvQJZALof9RU/jntqGltnQXArUgPMSGGu1f+7AH/CuMyQARAQABwsBfBBgBAgAJBQJSn5gM AhsMAAoJEBRwGu1hpbJ1maAH/RZPbvXaNIOouHZlnlkq/WORHxjkKfve+AbE62Ed8yFIwlAj tyZGKeEG9hDJl6f9BxDv+9qunTfWfXQuHxNIpdXstkxQIx4m043Kx3h7VdEmg53ybeGNgpvz BYk5HdgCH3yP6UbGNiel6xZOywmvpru3pEKNg4mJhzxm9JCG+djrvbRh+BZNOkDBgaSiCAuJ q6Ffo9Qk/qfl6Uim9G7GKSS4930ZQ2GoVObe+jXixOhWXFSDhGKX5meABmELJ9XTcW3Pp6XC 0KXOE2p0EHQPmFvXdU6OePI72jTgRzPJXRXbPkL0/NUfbZfxS/xnAG8jmODc2ufbtrvE2jPu INX35u4=
-
In-reply-to:
<aef745a4-9a7d-0418-6fbf-cabc5093d79e@gmail.com>
-
Openpgp:
preference=signencrypt
-
Spamdiagnosticmetadata:
NSPM
-
Spamdiagnosticoutput:
1:99
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
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-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
>>
>
> _______________________________________________
> 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
>
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References