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 <[email protected]> >>>> 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: [email protected] >>>> SB ELDI ltd. Riga, Latvia >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
