I think another stop gap measure is to have the ERC handle this, but otherwise I am for Orsons patch.
Better a defined bad behavior than an undefined random behavior is my opinion :) On Fri, May 18, 2018, 16:53 Maciej Sumiński <maciej.sumin...@cern.ch> 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