Le 18/05/2018 à 17:35, Kristoffer Ödmark a écrit : > I think another stop gap measure is to have the ERC handle this, but > otherwise I am for Orson's patch.
This is also my opinion. And Orson's patch is very acceptable. > > Better a defined bad behavior than an undefined random behavior is my opinion > :) > > On Fri, May 18, 2018, 16:53 Maciej Sumiński <[email protected] > <mailto:[email protected]>> 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] > <mailto:[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] > <mailto:[email protected]> > >>> SB ELDI ltd. Riga, Latvia -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
