kicad-developers team mailing list archive

["Brian Piccioni" <brian@xxxxxxxxxxxxxxxxxxxxx>]

Seth

That certainly is much simpler!

After doing some experimentation, if I manually update the schematic and push an update to the PCB using "Match Footprints by Timestamp" I retain the component connectivity, etc., and only change the reference designation, which is the desired effect.

The only negatives I would see is that we'd lose the "sort by reference designation option" which probably be a rarely used option. 

Thanks for the guidance on this: I am in the early phase of understanding how Kicad works internally so I apologize if I appear more incompetent than I really am. 

Regards, 
Brian



-----Original Message-----
From: Seth Hillbrand <seth@xxxxxxxxxxxxx> 
Sent: January 7, 2019 11:18 PM
To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>
Cc: 'Wayne Stambaugh' <stambaughw@xxxxxxxxx>; kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] [KiCad-developers] Hoping to contribute but I have some questions

Hi Brian-

I haven't used your tool but from the description, I think that it should run primarily from Eeschema.  The steps would look like:

1) (optional) Update PCB from Schematic
2) Request x/y pairs from pcbnew via KiMail
3) Renumber components in Eeschema
4) Update PCB from Schematic

This keeps the renumbering routine localized in Eeschema where the netlist is maintained and prevents duplication of effort with back-annotation.  This may or may not meet Wayne's requirements.  It also reduces your coding requirements substantially as you are not trying to re-code a bunch of update functions (it is not just component
refdes) in pcbnew.

Best-
Seth


Am 2019-01-07 17:22, schrieb Brian Piccioni:
> Wayne
> 
> I don't think a new file format is necessary. I can transfer a change 
> list from PCBNew to eeSchema via Kimail. This would simply be a string 
> or something and never surface (though, for an audit trail it might be 
> useful to have the changes written out as a log file, at least 
> optionally). Once this change list has been checked by eeSchema (in 
> case the schematic is not synched to the PCB), the changes would be 
> implemented in PCBNew and eeSchema. Then the equivalent of Update PCB 
> back to the PCB.
> 
> So, to summarize:
> 1) Generate a change list in PCBNew;
> 2) Using Kimail send the change list to eeSchema for quality control 
> (in case the schematic is out of synch with the board;
> 3) Once the change list has been checked, update the reference 
> designations on the PCB;
> 4) Using Kimail, direct eeSchema to update the reference designations 
> as per the change list;
> 5) After updating the schematic, eeSchema invokes an "UpdatePCB" which
> 	a) generates a new netlist;
> 	b) transfers that netlist to PCBNew via Kimail;
> 	c) opens a menu to import the netlist to PCBNew.
> 
> Note that the netlist changes still flow from eeSchema to PCBNew, 
> however, since the reference designations on both the schematic and 
> the PCB have been changed in exactly the same manner, the connectivity 
> is not changed.
> 
> I have done this manually using edit commands in PCBNew and eeSchema 
> and it seems to work fine.
> 
> To reiterate, I am pretty virtually certain this can be done without 
> requiring a new file format and will ensure the schematic and PCB 
> remain in sync with the netlist.
> 
> Of course, I may be misunderstanding your point or not be well enough 
> versed in how things work.
> 
> Nevertheless, if I work on the code and hit a brick wall I can either 
> look for a solution or abandon the effort in shame.
> 
> Regards
> Brian
> 
> 
> -----Original Message-----
> From: Wayne Stambaugh <stambaughw@xxxxxxxxx>
> Sent: January 7, 2019 12:30 PM
> To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>; 
> kicad-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [KiCad-developers] Hoping to contribute but I have some 
> questions
> 
> On 1/7/2019 9:49 AM, Brian Piccioni wrote:
>> Wayne
>> 
>> I looked at the source over the weekend within the context of your 
>> comment. In eeSchema there is a command to "Update PCB" with a 
>> modified netlist. This command is passed from eeSchema to PCBNew by 
>> Kimail. At this stage my rough program design has evolved to a sort 
>> of state machine where there are several interactions between PCBNew 
>> and eeSchema via Kimail (i.e. passing the change list, checking it 
>> for errors, committing the change list if no errors, etc).
> 
> This is the issue that I was talking about.  Currently netlist changes 
> are unidirectional from the schematic editor to the board editor.  In 
> order to push annotation changes from the board editor to the 
> schematic editor, you (or someone else) will have to implement this in 
> order to back annotate the revised references from the board editor to 
> the schematic editor.  The other option is to save an intermediate 
> netlist file from the board editor (which I also believe doesn't exist
> yet) and import the changes into the schematic editor.  These would be 
> the only two solutions that I would accept but my preference is the 
> former.  I want to avoid yet another intermediate file format.
> 
>> 
>> Since I propose to do a "dry run" of the component changes in 
>> eeSchema to check for errors it seems to me that executing "Update PCB"
>> immediately after re-annotating the PCB and schematic would ensure 
>> coherency with the netlist.
>> 
>> As this is pretty much was a PCB designer would do if he re-annotated 
>> manually it should work under program control as well.
>> 
>> Would this address your concern or is there something else I am 
>> missing?
>> 
>> Regards
>> 
>> Brian
>> 
>> -----Original Message-----
>> From: Kicad-developers
>> <kicad-developers-bounces+brian=documenteddesigns.com@lists.launchpad.
>> net> On Behalf Of Wayne Stambaugh
>> Sent: January 5, 2019 8:07 AM
>> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Kicad-developers] Hoping to contribute but I have some 
>> questions
>> 
>> On 1/4/19 6:18 PM, Tomasz Wlostowski wrote:
>>> On 04/01/2019 18:51, Brian Piccioni wrote:
>>>> I am still keen to attempt to incorporate geographical component 
>>>> annotation into KiCad. In general, it is preferable for component 
>>>> annotation to be done relative to the PCB and in some logical order 
>>>> (left/right, top to bottom, etc). Thereafter this information is 
>>>> imported to the schematic. I wrote a standalone utility
>>>> (RenumKicadPCB) which does this but ideally, we’d want the function 
>>>> built into Kicad.
>>>> 
>>>> I understand this would be viewed as a “rogue effort” but lack of 
>>>> geographical component annotation is a major missing feature and my 
>>>> hope is that if my code works the developers might consider adding 
>>>> it or something like it into the project. Otherwise I’ll just 
>>>> maintain my own variant of the two affected applications for 
>>>> limited use.
>>>> 
>>>> I am not used to working in c++ or working on large projects. 
>>>> Nevertheless, I figured I’d give it a try. I have been studying the 
>>>> source for a few weeks and have developed a strategy which would be 
>>>> very simple to implement if I had more skill/experience.
>>>> 
>>>> The first thing I want to do is to add the ability for eeSchema to 
>>>> import a “was/is” file to update schematic annotation. Since 
>>>> renumbering the PCB can be done manually or with a plugin this 
>>>> seems like a good first step. Since an annotation function already 
>>>> exists in eeSchema, all I would have to do it provide an option for 
>>>> replacing annotation with a was/is rather than the annotation 
>>>> generated by eeSchema’s annotate function.
>>>> 
>>>> I see a clear path to doing so however, the scope of Kicad and my 
>>>> limited experience with c++ and large projects mean it is not going 
>>>> to be easy for me. I am not that adept at navigating Doxygen files 
>>>> so I have a few questions regarding the source code (these are 
>>>> limited to eeSchema at the moment).
>>>> 
>>>> 1)	Where are the file IO functions? I have searched for (for 
>>>> example) LoadProjectFIle and find the prototype but not the actual 
>>>> function. Similarly I find the prototype for SaveEEFile() but not 
>>>> the actual function.
>>>> 
>>>> 2)	I would like to copy as much of the existing code and dialogs as 
>>>> possible (i.e. make new dialog based off another dialog) but when I 
>>>> open, for example, dialog_annotate_base.h I see
>>>> 
>>>> 	///////////////////////////////////////////////////////////////////////////
>>>> 	// C++ code generated with wxFormBuilder (version Jun  5 2018)
>>>> 	// http://www.wxformbuilder.org/
>>>> 	//
>>>> 	// PLEASE DO *NOT* EDIT THIS FILE!
>>>> 
>>>> ///////////////////////////////////////////////////////////////////
>>>> /
>>>> /
>>>> //////
>>>> 
>>>> But I can’t find the “source” from which this file is generated. 
>>>> Where is it?
>>>> 
>>>> 3)	There is a guide on the Kicad documentation “Tool framework” 
>>>> which describes adding a tool to PCBNew. Is there a similar guide 
>>>> to adding a tool/function to eeSchema? How do I go about this?
>>>> 
>>> 
>>> Hi Brian,
>>> 
>>> Others have already answered to your questions so here's my offer: I 
>>> believe geographical annotation is a very useful feature so I can 
>>> offer a bit of my help. Point me to:
>>> - the latest sources of your tool,
>>> - a sketch of the user interface (dialogs), can be a hand-made 
>>> drawing
>>> - a brief description of how you want all this to work (in terms of 
>>> user experience).
>>> 
>>> Once I have this information, I'll try making a basic port of your 
>>> code to Kicad codebase to the stage where you could take it over and 
>>> contribute further features/fixes on your own.
>>> 
>>> Tom
>>> 
>> 
>> There is a lower level piece of the puzzle that is missing and that 
>> is back annotation from the board editor to the schematic editor.  
>> This is non-trivial because you have create a netlist from the board 
>> information and pass it back to the schematic editor.  This would be 
>> the only solution that I would accept.  I want to avoid multiple 
>> ad-hoc solutions for back annotation purposes.
>> 
>> Cheers,
>> 
>> Wayne
>> 
>> _______________________________________________
>> 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