kicad-developers team mailing list archive

[Kristoffer Ödmark <kristofferodmark90@xxxxxxxxx>]

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.suminski@xxxxxxx> 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-sf@xxxxxxxxxxxxxxxxxxxxx> 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-sf@xxxxxxxxxxxxxxx
> >>>    SB ELDI ltd. Riga, Latvia
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>