kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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 <maciej.suminski@xxxxxxx
> <mailto: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
>     <mailto: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 <mailto:sb-sf@xxxxxxxxxxxxxxx>
>     >>>    SB ELDI ltd. Riga, Latvia



-- 
Jean-Pierre CHARRAS