kicad-developers team mailing list archive

["Brian Piccioni" <brian@xxxxxxxxxxxxxxxxxxxxx>]

Jeff

 

Thanks for the reply.

 

I don’t think I explained it correctly. eeSchema does schematic annotation which is then exported to the PCB via netlist. This results in the PCB annotation being essentially randomized.

 

For example I might have a PCB with annotation

 

R1       R3       R2       R4.

 

For an engineer, you want the PCB annotation to be “geographical”

 

R1       R2       R3       R4.

 

That way when you are working on the schematic you know where to find the components on the PCB. 

 

Currently, this is done manually with PCBNew. You manually rename every component on the board and go back to the schematic and make all the changes.

 

So you renumber R3 -> R2, R3->R3 in the PCB and schematic.

 

This is lot of work for a board with any components and a significant potential for error.

 

The software I wrote automatically renumbers the PCB geographically with a number of options (i.e. top to bottom, left to right or top to bottom right to left, etc.) then goes back and back-annotates the schematic.

 

Most professional PCB CAD systems I’ve used have this function. KiCad does not. So this would be an entirely new feature and, although my code has had limited distribution, people seem to really like it.

 

A few people have written macros which try but they don’t handle hierarchies and so on.

 

Having looked at the KiCad code base, most of the hard parts of my software (in particular traversing the hierarchy and parsing the PCB, Sch, and Net files) are not required if it becomes integrated with KiCad. 

 

So, in summary

 

1.	This would be a new and desired feature for V6;
2.	A person with a good knowledge of c++ and Kicad would find it easy to do.

 

If you wish I could give you a small project or prepare some screen grabs if I haven’t made it clear.

 

Thanks

 

Brian

 

 

 

From: Jeff Young <jeff@xxxxxxxxx> 
Sent: May 10, 2018 1:54 PM
To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>
Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] Proposed Geographic PCB Re-Annotation for Kicad 6

 

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> https://launchpad.net/~kicad-developers
Post to     :  <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe :  <https://launchpad.net/~kicad-developers> https://launchpad.net/~kicad-developers
More help   :  <https://help.launchpad.net/ListHelp> https://help.launchpad.net/ListHelp