kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey Jeff,

I believe Brian has proposed annotating by the physical position on the
board layout and back annotating the schematic accordingly.  The problem
I see is that we do not have back annotation support implemented yet.
I'm guessing his implementation directly modifies the schematic file
which I would be opposed to unless it uses the schematic file plugin for
loading and saving the schematic to ensure file integrity.  The ideal
solution would be to wait until the back annotation feature is
implemented and push the updated references back to the schematic from
the board editor.  It's not a trivial change.

Cheers,

Wayne

On 5/10/2018 1:54 PM, Jeff Young wrote:
> Hi Brian,
> 
> Re-annotation is usually done in Kicad from Eeschema rather than Pcbnew.
> 
> The current annotation dialog supports two ordering mechanisms: "by x
> position" and "by y position".  If I understand what you’ve done
> correctly it could be added as a third option “rules based sorting” (or
> something).
> 
> We’d then have to add a dialog for editing the rules.  How complicated
> are they?
> 
> Cheers,
> Jeff.
> 
> 
>> On 2 May 2018, at 22:43, Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx
>> <mailto:brian@xxxxxxxxxxxxxxxxxxxxx>> wrote:
>>
>> Sorry if this is a duplicate: I originally sent if from my
>> non-registered email address.
>>
>> * *
>>
>> *Proposed Geographic PCB Re-Annotation for Kicad 6*
>>
>> I wrote a standalone program called RenumKiCadPCB which does a
>> rules-based geographical renumbering of PCB components and
>> back-annotates the schematic hierarchy and netlist.
>>
>> As it stands, this is an external program written in c.
>>
>> Having looked at the Kicad codebase I believe it can be incorporated
>> into Kicad as a standard function. Because this is common in
>> commercial electronic CAD I believe it would be appreciated by the
>> user base. Manual geographic re-annotation is time consuming and
>> source of potential error. 
>>
>> Currently the freestanding code works like this (summary):
>>
>>  1. *Drops into a primitive text based menu system for set up;*
>>  2. Parses the schematic hierarchy to determine storage requirements
>>     and file paths;
>>  3. Parses the PCB file to locate all components and their locations;
>>  4. *Creates a sorted “change list” based upon the rules for sort
>>     direction and the results of step 2;*
>>  5. Makes backups of the schematics, PCB, and netlist;
>>  6. Updates all schematic symbol reference designations in accordance
>>     with the “Change List”;
>>  7. Updates the PCB reference designations and nets in accordance with
>>     the “Change List”;
>>  8. Updates the Netlist reference designations and nets in accordance
>>     with the “Change List”;
>>  9. Writes out the updated files.
>>
>> There are various “traps”, etc., if errors are detected.
>>
>> Besides the issues of being a standalone program, the need to parse
>> the various file formats (SCH, Kicad_PCB, netlist) means that if
>> simply ported into Kicad the code would have to be constantly updated
>> in order to accommodate even small changes to the file formats.
>>
>> Having spent some time looking at the Kicad code base, I am pretty
>> sure all but step 1 (the menu) and step 4 (creation of a rules-based
>> change list) can be replaced by calls to existing Kicad functions, in
>> particular those used for search and replace, editing text, etc.. I
>> assume it is possible to spawn eeSchema from PCBNew in order to do the
>> search and replace on the schematic hierarchy and to regenerate the
>> netlist.
>>
>> The Netlist Importer menu in PCB new would make a good prototype for
>> the new menu.
>>
>> Use of existing Kicad functions would probably result in the code
>> running slower than it currently runs ( << 1 second for a large board)
>> but that should not be a problem since this is the sort of thing which
>> is rarely run more than a couple of times during the life of the project. 
>>
>> Nevertheless, use of existing functions ensure the geographical
>> reannotation would be robust against any future changes to file
>> formats, etc., since reference designations and coordinates are
>> inherent characteristics in an ee CAD system.
>>
>>  
>>
>> *_Risks_*
>>
>> I have to note that my participation has some risk:
>>
>>  1. I am old (60) and have never written code as part of a large,
>>     collaborative project: most of my programming experience is
>>     limited to embedded designs;
>>  2. I have only a passing familiarity with c++;
>>  3. I am not used to the sort of documentation associated with Kicad;
>>  4. These imply a steep learning curve for an old guy;
>>  5. As such, it will probably take me much longer than a skilled
>>     programmer to do this.
>>
>>  
>>
>> Therefore, it would be helpful if there was a mentor I could turn to
>> for some guidance, if the developers accept that this is a good idea.
>>
>> I would appreciate any feedback. If you think this would not be a good
>> thing to pursue, please let me know.
>>
>>  
>>
>> Regards
>>
>>  
>>
>> Brian Piccioni
>>
>> Documented Designs
>>
>>  
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto: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
>