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 <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. Borshch mailto: 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 >>> >> >> >> >> >> _______________________________________________ >> 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
