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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
