As before it includes a Windows 64 exe as well as the source files and Linux make instructions.
Thanks to Andy_P who tested the program and correctly identified that it did not handle hierarchical sheets.
The program has been extensively rewritten to support hierarchies and (I believe) âchannelsâ or the same sheet repeated with different reference designators.
I also added the option to -c output a change list and leave the files alone and a -y option so you donât have to type Y/N to run the program.
After running V0.102 on PCB_Wizâs icezum project, it seems to work fine. There is an issue if I then create a schematic netlist from the updated files and import that into PCBNew and run the DRC. Three netlists are flagged no connects even though they appear to be connected.
I lack the KiCad skills to determine if this is a problem with my code or the way the original files were made (I have had KiCad complain about files it alone had made)It appears to be easy enough to correct but the project is too complex for me to understand. Note that this only occurs if you recreate the netlist.
If anybody has a similar problem and can reproduce it on a minimal project I can probably fix the code if there is a bug.
Please let me know if there are any issues & thanks for your interest
Here is the complete file set after my utility ran on it.
Just to be clear I did check to make sure there were no issues with your files before running the utility.
However, I canât understand where to begin figuring out what the problem is. These are the errors I get only after I import the a netlist from the updated schematic
Warning: Copper zone (net name âNet-(C67-Pad1)â): net has no pads connected.
Warning: Copper zone (net name âNet-(C62-Pad2)â): net has no pads connected.
Warning: Copper zone (net name âNet-(D10-PadK)â): net has no pads connected.
This is easy to find.
Press B to repour, and you see Net-(C57-Pad1) has not filled as expected. (as per error above)
Look carefully at the NET names, and Select the Fill border then E and you see
Fill is called (net name 'Net-(C67-Pad1), but traces are Net-(C57-Pad1)
ie the RefDes renumber has also regenerated net names and that means you will get Fill-disconnects, unless those fill areas are also renamed.
I think if the Fill areas have user-defined names, this will not be an issue.
If the design tagged fills to Auto-generated NET names, (as above) then some fix-up pass will be needed.
If kiCad had a Connect-Fill-To-Net by mouse select, that would also be much faster.
Not sure how hard it is to fix to have NET import house-keep Fill-name-mapping as well ?
I understand the words you are saying but I donât understand what they mean.
With respect to the NET names, KiCad seems to associate them when it imports the netlist.
In other words, I just change the reference designators and KiCad seems to take it from there. It is interesting that 9I think) the pour net names are not in the schematic.
So based on what I think you said, it does not seem to be doing that reliably with pours (?)
In your opinion is this an easy manual fix for the PCB designer? If so the fact my code takes less than 200 mSec to renumber and back annotate it may be a fair trade off.
Meanwhile I am going to try figure out what the format for pours is.
Yes, for auto-generated net names, it seeds with a node-name.
Thus you get a change when a RefDes changes.
SCH has no need to store the pour information.
The issue is on Pours with Auto-Generated names, which are moderately rare.
There are 21 pours reported in that file and only 3 fail, those where the auto-name moves.
Hehe, âeasyâ is relativeâŚ
Re-tag of NET could be easier, but it certainly is possible and practical.
The messages are clear.
You offered to send me your files (I promise I will keep them confidential and delete after the code is fixed) can you send me an email at briandocumenteddesignscom? (doing to avoid bots) the first * is @ the second is â.â
The other thing is I am unfamiliar with Apple paths, naming, etc., is there anything special about your path like embedded spaces? In windows you need to put those in âdoc/name with spaces/â to get the command line to parse correctly.
Iâm not quite following this remaining case.
If a net name is in neither, then it does not appear at all ?
Or do you mean a case where the Fill has a invalid/old NET name, still generates an error (which would be expected)
I notice one artifact in that icezum test case, which is where an auto-assigned net name, can cross link in error.
eg Net-(U6-Pad17) was valid for TXB0106, but during renumber a new U6 arrives which has a valid Pad17, and even with Single Pin nets disabled, on NET import, this cluster named Net-(U6-Pad17), will connect to U6-Pad17.
There is no zone here, and the TXB0106 has a single Pad17 in the NET file, but actually has 4 pads on the PCB.
I think that ( > 1 Pad) means the old Net preserves, and then it considers it passed the single pin net test, and thus happily connects to the now-wrong Net-(U6-Pad17), which is a single-ref in the NET file.
I fixed the problem but it is not clear my software is the issue.
All the modules, nets, etc., are fine. KiCad decided to essentially remove the fill from the polygon and add a new net called C57 instead of C64 (the original refdes is C67, so I donât know where it got C57). It also rips up the C64 tracks for good measure.
KiCad replaces all the nets which should be C64 with nets called C57 and it seems to connect everything, except the fill polygon remains C64. All you have to do is edit the polygon to change the net from C64-Pad1 to C57-Pad1, click OK and then B to refill.
Because my files are OK as near as I can determine prior to KiCad creating the net (all parts and nets are named properly) I am not sure the problem is with my software.
Maybe if other cases show up I can take it further.
Yes, the Zone-Net issues list also on the NET import, so you can see what needs fixing.
Harder to resolve is the other issue I mention above, where a part with more than one Pad, spawns a local net group, and that will connect in error, if any renumbered part happens to have a same Auto-Name.
The Import option of Remove single pin nets fails to fix this, (because the net exists > 1 Pad) so maybe another choice is to inhibit generate of Single Pin nets in Eeschema ?
Iâm not sure that is possible now, but it certainly should/could be an option in the next releases ?
