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. > _______________________________________________ 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
