I figured out what the problem is with the netlist import issue.
The schematic is correct and the PCB is correct. KiCad seems to generate netlist names on the basis of the lower reference designation (or randomly, I don’t know). The schematic wires are not named they are just lines until the netlister names them. (though I think you can name them). So when it recreates the netlist it names it C57 instead of C64. KiCad PCB is OK with that but then it doesn’t jiive with the pour name it creates.
That is done in order to construct the hierarchy since the root sheet always has the same name but with a .sch extension. I could write code to strip the extension but it is easier to simply not use it.
One thing about getting other people to use software is they (very correctly) use it differently. The programmer gets into a rut of running tests but he always does it the same.
Andy’s file name problem happened when you ran the code in the same directory as the files. I never did that.
Last night I wrote code to rename Nets. This AM I realized I could consolidate the code and make it much cleaner and faster. Maybe I fixed a bug, or maybe this bug will show up when somebody else tries it.
I hope people use the code and find all the bugs. I wrote it because it took me hours to back-annotate a small board without errors.
Thanks for spotting the problems. I don’t know how to handle the zone issue but maybe something will come up.
On a renumbered board, zoom to U1 and see the large Pad17 (was U6)
There are also a cluster of 4 Pad-Vias, there and they are named Net-(U1-Pad17) using v.104 & fresh master.
On the tests above, that cluster was stuck at Net-(U6-Pad17), v.104 seems to fix that.
The problem as I understand it is the zone net tag is correctly updated to net C64 but when a new netlist is created it calls the net C57 instead of C64. This is the netlist program’s decision.
So the schematic is OK, the PCB is OK before the import, but for some reason when KiCad picks up the netlist it looks for a Net C57 and doesn’t associate that with the zone C64. Maybe there is a workaround but I don’t see there is a problem with the files.
Ah, yes, now I follow
Your update is locally correct, but if you want it to also remain correct after a NET import, (which is a good idea) then you will need to clone the Auto-Generate selection used by SCH netlist generate.
You could get the eeschema source and see how they choose the seed ?
Fingers crossed it is ref-des based and not sheet-placement based.
Unfortunately, the KiCad code is written in c++, which I am not good at, and almost entirely undocumented so it would be an enormous amount of work to reverse engineer.
I will wait for further feedback before determining how big a problem this is, especially as it is so easy to correct in KiCad’s PCB application.
I will make a not to strip file extensions in a future edition. I am really keen to hear what Andy thinks because he seems to have a complicated design with channels, etc…
The help menu needs mentioning that complete paths should be put in parenthesis, otherwise it won’t deal with spaces in folder/file-names.
For me it also didn’t want the extension there (had tested with test.sch and test.kicad_pcb but in each case it couldn’t find test.sch.sch or test.kicad_pcb.kicad_pcb).
Besides that it seems to work.
Win7 64bit
KiCAD BZR6971
sheet structure:
2 layer board with 247 devices (21 different designators) placed on front and back
Ran it with options -m and -v.
Good job on ignoring things like mousebites (with REF** for example) that have been placed in PCBnew
I had 2 devices in the schematic that I removed in PCBnew and got two warnings like this for each:
Schematic refdes xyz not found in change array!
No idea if that warning also covers other cases, but that’s what triggered it for me.
Beats doing it by hand, right. I run about 300 mSec on a complex board.
Yes, the PCB is annotated first so it builds the change list from the PCB. Then it goes back and changes the schematics. If the schematics have changed it will flag those as errors. I put this in for debugging but I guess it can be helpful to show the database is out of whack.
So far I haven’t had the desire or need to do this kind of thing (populated above board for the first time by hand 2 days ago), but your program does such a nice job I’ll definitely use it in future (as I found I was hunting around the printed assembly layout in the search for device XYZ way too often).
I used to be an electronics designer (not a PCB designer) My last board I designed professionally had about 400 components. You can imagine tracking down R61 if they aren’t in order.
Then imagine a modern board with 1000 components on the front and back …
With my software you can label all the back components B_R61 or whatever.
I am pretty sure professional packages do this automatically so I was surprised KiCad doesn’t.
I ran a quick test, and tried R1,J2, which gives “Net-(J2-Pad9)”
then a flip of R1 to A1, no other changes in placement or wire order, then gives this :
appears to be a simple ASCII sort ?
I tested rename based on starting letters of 0 <- : <- A <- J -< a
A002 <- A1
A1 <- A100
A001,A1 complains for re annotate, as it seems to resolve those as the same.
I think the problem is that PCB deals with that sort of things as being “normal”. So it says "hey - here is net A2-Pad1 but it connects the same as J2-Pad9 on the PCB so I’ll load it and call it J2-Pad9.
However it doesn’t appear to subsequently remember to do the same with filled zones.
So it sees a new net which connects to many of the same things as J2-Pad9, but not all the same things (because of the zone) and it doesn’t rename it. Then it flags the two as separate.
