I am not sure of anything. However the PCB and schematic files are fine until a netlist is imported. PCB seems to handle all the other renamed nets (but I haven’t checked all of them) except one where there is a pour.
If you look at before/after netlists they are similar but different. Sometimes net names will change sometimes the order nets are listed changes.
I think the problem is with how PCB handles net imports with pours and may be reproducible just by messing with the schematic.
None of this is really documented so it is not trivial to figure out.
Looks to me like you are very close.
The NET import knows nothing about Pours, so it is not surprising that needs your extra pass.
However, once that is done, the other effect is Auto-name re-seeding, and that seems to be by simple sorted Ref-name.
It does mean you need to collect the new set of RefDes for each net, and then re-seed after any part-renum.
I also note
“Net-(J2-Pad3)” <- “Net-(J2-Pad5)”
so the simplest would likely be a list of possible auto-names, based on all present nodes, and then sort & pick first.
You could even generate a exPCB NET file, as that is something PCB side does not currently do, and a NET file is a nice way to confirm nothing was added/lost in revisions.
You can compare that with the SCH NET, to confirm your seed is the same.
I can replicate the problem exactly without using my software on the original design.
Edit the ref des of L4 (power supply page) and C67 to L1004 and C1067. Do the same on the PCB (i.e. manually annotate the PCB/Schematic. Generate and import the netlist and exactly the same problem appears.
So it appears sometimes PCB does not properly handle netlists when there are pours involved and the netlist names change.
Yes, I’d say the KiCad PcbNew is importing NET info in a simpler manner.
If there is a Pour inside PCB that is Auto-Name tagged (somewhat rare, but possible), then any time a renumber shifts that Auto-named NET, you will have issues.
User-named Pours will be ok.
The NET file would need something like RENAME NET command, to cover this, instead it rebuilds a connection tree, and does not ’ go looking for’ other info to track this change.
That’s probably tolerable, as the workaround is possible.
You SW can raise the IQ of this whole process, if it does more of the housekeeping.
It already renames Pour areas, but does not (yet) track SCH auto-name seeding, so you can expect diverge when you import a new NET from renamed SCH.
Setting aside the possibility I screwed up I change only nets which have a reference designation. So I change a net with C6-Pad1 but not “DMA_ADDRESS_0”
Can you expand on this “change only nets which have a reference designation” ?
eeschema generates using the rules LowestSortedRefDes+"-Pad"+PadName, however, PCB side can get updates from other sources, and the master design may have imported from Eagle, Altium or others.
It could pay to check the hidden name rules for those packages ?
From memory some use “NN”+number, and some use “$$$” etc
The function of the program is to re name PCB component reference designations and back annotate that to the schematics. If schematics are not available because things were imported from other sources/net lists then they are not updated plain and simple.
Unless there is a reason to parse net names I am not going to expand the scope of the software unless I know it is widely used and there are problems with what it does.
I could have simply kept the development to myself otherwise.