Wayne

My prior approach was to 
1) verify that the was/is change list produces no errors on the schematic 
(since it is derived from the PCB there can be discrepancies).
2) if there were no errors, update the PCB and schematic reference designations
3) update the netlist with the new reference designations.
4) direct the user to re-import the netlist, which rebuilds the associations.


Obviously 3) and 4) can be problematic for a variety of reasons. What I would 
propose is to simply regenerate the netlist from within eeSchema and reimport 
that into PCBNew. 

I should point out that what I am proposing is currently done manually. In 
other words, somebody would manually change all the reference designations in 
PCBNew and either simultaneously make the change in eeSchema or keep a 
handwritten was/is list to do it subsequently. The manual approach is not only 
a huge amount of work, it is fraught with the potential for error. The way to 
test coherency between the PCB and schematic is to update the netlist, reimport 
it, and, if possible, run a DRC. Once a schematic's reference designations get 
out of whack with the PCB it can be really hard to fix. I don't make large 
boards and these two issues were why I wrote my utility in the first place. 

Automating the process is not only a huge timesaver but it greatly reduces the 
odds of an error. 

In any event, regardless of the approach, netlist coherency can be resolved by 
re-creating the netlist from the updated schematic in eeSchema and re-importing 
it into PCBNew. This is what would have to be done if somebody did the 
reannotation manually.

I have been looking at cross-probing.cpp and I see a clear path to the solution 
by adding a small number of additional message types. This could include 
directing the eeSchema to generate a netlist, cross-application error 
reporting, etc..

Does that make sense or am I missing something?


Thanks

Brian

-----Original Message-----
From: Kicad-developers 
<kicad-developers-bounces+brian=documenteddesigns....@lists.launchpad.net> On 
Behalf Of Wayne Stambaugh
Sent: January 5, 2019 8:07 AM
To: kicad-developers@lists.launchpad.net
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
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

Reply via email to