kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/07/2014 11:41 AM, jp charras wrote:
> Le 07/07/2014 14:48, Dick Hollenbeck a écrit :
>> On 07/07/2014 02:34 AM, jp charras wrote:
>>> Le 07/07/2014 06:20, Dick Hollenbeck a écrit :
>>>> I added back annotation to Eeschema directly from Cvpcb when they are both running under
>>>> Kicad.exe.
>>>>
>>>> I could have done it row by row.  Instead I did it as a group batch when you "save" under
>>>> cvpcb, on the idea that if you were to abort cvpcb without saving, you would not want to
>>>> affect your schematic.
>>>>
>>>>
>>>> For the TODO list, I think we have a problem with the hierarchical format.  Here is a
>>>> takeout from a nested schematic, used six times in the hierarchy:
>>>>
>>>> $Comp
>>>> L R R1
>>>> U 1 1 520135B0
>>>> P 5400 3350
>>>> AR Path="/5201406D/520135B0" Ref="R1"  Part="1"
>>>> AR Path="/52014588/520135B0" Ref="R2"  Part="1"
>>>> AR Path="/52014893/520135B0" Ref="R3"  Part="1"
>>>> AR Path="/520134DE/520135B0" Ref="R4"  Part="1"
>>>> AR Path="/52015233/520135B0" Ref="R5"  Part="1"
>>>> AR Path="/520155E6/520135B0" Ref="R6"  Part="1"
>>>> F 0 "R2" V 5500 3450 60  0000 L CNN
>>>> F 1 "R" V 5300 3450 60  0000 L CNN
>>>> F 2 "Discret:R6" H 5520 3450 60  0001 C CNN
>>>> F 3 "" H 5400 3350 60  0001 C CNN
>>>> 	1    5400 3350
>>>> 	0    -1   -1   0
>>>> $EndComp
>>>> $Comp
>>>>
>>>>
>>>> If CVPCB sets only R3, and not the others, then the back annotation does not stick.  This
>>>> is not new that I can tell, I believe it failed this way when doing back annotation with
>>>> the *.cmp file also.  The code between the two means is similar.
>>>>
>>>> I used an s-expression on the KIWAY express, and parsed it with the DOM s-expression
>>>> parser in about 5 lines of code.
>>>>
>>>> See SCH_EDIT_FRAME::backAnnotateFootprints()
>>>>
>>>> Jean-Pierre, what do you think?
>>>>
>>>>
>>>> Dick
>>>
>>> If fact, it is hard to fix this kind of issue, because this is not
>>> really a bug, and it exists with .cmp files.
>>> You are using a complex hierarchy, therefore the *same* schematic sheet
>>> (and therefore the same data) is used 6 times.
>>>
>>> Cvpcb (and Pcbnew) are seeing a flattened schematic, because they are
>>> using a netlist, which is always built from a flattened schematic
>>> representation.
>>> In this case, R1 to R6 are the same component in schematic (therefore
>>> only one footprint field, one doc field ...) and 6 different reference
>>> fields.
>>> However there are 6 different components for Cvpcb, and you can set 6
>>> different footprints  (and in Pcbnew, you also can have 6 different
>>> footprints, for the same schematic component)
>>>
>>> In your example, R1 to R6 should have the same footprint, to be
>>> compatible with a schematic backannotation.
>>>
>>> (If not, this is the last footprint name read in the back-annotate file
>>> which is stored in schematic)
>>>
>>> This is not really a bug, but a limitation of complex hierarchies.
>>> But is it really a limitation ?
>>> When your are using complex hierarchies you are doing that because you
>>> want your changes (schematic modification, change a component value, or
>>> a footprint name ...) made only once but reproduced 6 times on your board.
>>>
>>> In other words:
>>> * If you want to back-annotate a complex schematic: R1 to R6 should have
>>> the same footprint.
>>> * If you want to design a board: R1 to R6 can have different footprints.
>>>
>>> You can fix that "issue", only by creating constraints in CvPcb, for
>>> instance do not accept different footprints for R1 to R6 (which have the
>>> same time stamp), or displaying only one component ( for instance only
>>> R1 ), but it is a unnecessary constraint for Pcbnew (although it is not
>>> a really strong constraint).
>>>
>>> This is more a decision to take.
>>>
>>
>>
>> Jean-Pierre,
>>
>> My poorly phrased, open ended question did not mean to put you on the defensive about
>> Tim's hierarchical sheet design.  (It has served adequately for a number of years.  A
>> modern approach will move the bindings into the site of instantiation and out of the thing
>> being instantiated.)
>>
>> Since you did not comment on the patch, I will check it off my to do list for milestone
>> B).  When I wear my user's hat, it saves me a step, so obviously I like it.
>>
>>
>> Dick
> 
> Sorry, I was thinking you had trouble with the complex hierarchy and CvPcb.
> 
> My explanations were also more for the readers of this ML than for you
> (I know you know how eeschema works).
> 
> About the patch, exporting the footprint selection from CvPcb to
> Eeschema when it is called with eeschema running and using the IPC is a
> good idea.
> Perhaps the export could be made by an other tool: one tool to write the
> .cmp file, and a specific tool (only visible if the export is possible)
> to export from Eeschema.
> I can do this minor change, if you want.


I assume you know that sending KIWAY express mail to a KIWAY_PLAYER not present is harmless.

By tool I assume you mean button...

I don't see why you want to make me click another button.  I was trying to reduce that.

Having another button that does something else (or half of what this one does) is fine, if
I can ignore it.

But if a guy has CVPCB setup not to exit on save, then I don't see the purpose of the
other button, because Save will get it into eeschema now and keep the CVPCB open.

This is my use case behaviour.  I was obviously frustrated before.


> Using S expression when exchanging data (using a file, the IPC or the
> clipboard) is certainly the easier and faster way.
> 
> This is the ROI of all your work on S expression and DSN lexer. Thanks.
>