Documented Designs

V0.300 RenumKiCadPCBV0300-fixed  (NOTE: THIS IS AN UPDATED ZIP WITH A FIXED EXE FILE) is a substantial rewrite in order to process errors better and to fix bugs which popped up in stress testing.

User Jano reported “The make RenumKiCadPCB don’t works out of the box, instead I was able to compile with: gcc RenumKiCadPCB.c -o RenumKiCadPCB -lm”

I don’t know if this is an issue across Linux versions but, just in case I have updated the manual in the zip.

Now everything is done in memory before writing to files.  If there are warnings, it asks whether to commit changes. After all, some errors, like mounting holes on the PCB which are not on the schematic, are not critical, even though you really should fix errors (including ERC and DRC).

If there are no errors (or if the user decides to “commit”), all related files are backed up and the new ones are written.

I fixed a number of issues associated with/exposed by weird file content in TERES_PCB1-A64-MAIN_Rev.C.pro.

I have stress tested with https://github.com/OLIMEX/DIY-LAPTOP/tree/master/HARDWARE/A64-TERES/TERES-PCB1-A64-MAIN_Rev_C which is the most complex KiCad project I have come across.

The Olimex Rev C files themselves have issues:

ERC and DRC show errors. I was able to fix all the ERC errors:
1) Resistor networks in the schematic have sections with different modules than                     the PCB
2) There is an excess PWR_FLAG on a power connector.

Also (bug reported to the developers) LCD.SCH has a “phantom” instantiation which does  not show up in ERC. The phantom instantiation meant parts were labeled U? but didn’t show up as not annotated. Even though renumKiCadPCB works, it flags errors such as this.

There are blank reference designations (i.e. “”) on the PCB.

The good news is, all these errors exposed issues with RenumKiCadPCB!

The Olimex PCB fails DRC with 9 errors as distributed. After creation and importation of a netlist this becomes 27 errors. The new errors appear to be associated with zones, a well established KiCad bug (see MANUAL.TXT).

I couldn’t figure out Olimex’s license, otherwise I’d post the fixed files (renumbered!)

After RenumKiCadPCB is run on the original files or the fixed files the DRC errors are the same, respectively. I assume, therefore, that RenumKiCadPCB is working. (famous last words …)

The Kicad “pour error” described in MANUAL.TXT still seems to be present in Kicad V5 nightly builds. The way you fix it (in V5 nightlies) is to “Edit” the zone (which I find a pain in the butt to do – type “E” exactly on the edge zone outline).

Make sure Net Filtering Display: Show All is selected and rename the zone net.

I remain hopeful the developers will decide to incorporate RenuKiCadPCB functionality into the software. It should be easy to do (but I don’t know how). Again, if there is anybody out there willing to do encourage the KiCad development group, please do.

Similarly, I would welcome anybody with requisit c++ or GUI programming skills to put a wrapper on the code.

PLEASE LET ME KNOW OF ANY BUGS!

I was hoping to produce a version of RenumKiCadPCB in a few days but moved things up after I got a bug report (plus fixed code!) from Sean Happel. Long story short a function I wrote to scan for component fields like F0, F1, and so on, didn’t care if the field started on a new line.

V0.205 fixes this bug with Sean’s code and now updates the netlist file. Previously RenumKiCadPCB updated the board and schematics but left the netlist alone since I figured it was trivial to regenerate the netlist. Admittedly this was pretty stupid of me as I often forgot to update the netlist before importing it.

Here is the source, manual, and Windows executable for V0.205: RenumKiCadPCBV0.205

So, now all the relevant files are updated with the proper reference designations.

There may be other bugs in the code: stress testing on Olimex Diylaptop project fails. order to debug a large project like that I have decided to make some relatively significant changes to the code so the updated files will not be committed if there are errors unless directed by the user. In other words, if there are errors in the input files, the user will be asked to commit the changes or abort updating the files.

I hope to release V0.206 once I have fixed that *and* figured out why Diylaptop fails. Of course, if other bugs are reported I’ll fix those first.

The Kicad “pour error” still seems to be present in Kicad V5 nightly builds, however I don’t know how to fix the error in V5.

Also, it seems to me the best time to run RenumKiCadPCB is prior to routing the board rather than just before making the Gerbers, which is what I have been doing. That way any missing component issues will beresolved early. No sense routing a board if the schematic and PCB have different parts!

I have suggested to the folks at KiCad to assign someone to incorporate RenumKiCadPCB into the code base. This should be easy enough to do but I lack c++ and GUI skills so I can’t do it alone. If there is anybody out there willing to do encourage the KiCad development group, please do.

Similarly, I would welcome anybody with c++ or GUI programming skills to put a wrapper on the code. A GUI would likely widen its appeal.

Thanks for using the code, and thanks for the bug reports!

 

Thanks to Phil Guiet for finding this bug and providing me with the Kicad files to track it down!

I was unaware that you can change the layer names in PCBnew. Well, I knew you could change the layer names but I wasn’t aware that the file structure would carry those names instead of F and B (Front and Back).

Therefore if you changed the top and bottom layers to something other than F or B RenumKiCadPCB would crash – which is never good. Now the software keeps track of which layers the modules are on, regardless of name. And it should no longer crash.

This is the link to V0.204 (source, manual, and a Windows EXE) RenumKiCadPCBV0204

Please let me know of any other bugs.

User Jano has found that the compilation instructions for RenumKicadPCB under Linux Mint should include -lm (see https://documenteddesigns.com/2017/03/27/renumkicadpcb-v0203/)

“I just compiled and used your utility successful! Thanks. Just a note to compile I needed to ad -lm at the end of the gcc order: gcc RenumKiCadPCB.c -o RenumKiCadPCB -lm my system is linuxmint 18.3, after that it worked perfectly.”

My understanding is that -lm usually includes a library module (i.e. -lmMingw32) and I’m not a gcc guru so I don’t know what the -lm by itself does, but if you have problems give it a try.

Thanks Jano!

I figured I’d post a photo of a board I’m working on.

It is an I2C to 20×4 LCD /keyboard  interface with support for an ESP8266-01 module plus the serial interface modules.

I ordered the solder paste screen from Elcrow and figured I’d give it a try. A couple years ago I picked up a convection toaster over from Walmart and modified it so the fan would run always on.

There are lots of tutorials and such about making a complex controller for “toaster oven reflow” but my approach is simple: I figured out the setting on the temperature dial so the solder melts then I made two marks on the dial: that point and a bit cooler.

I “pre-heat” the board at the cooler setting then move the dial to the “melt” setting for about 5 minutes, then move back to “pre-heat” after the solder melts, then after a couple minutes and shut the unit off.

This seems to work fine. My view is that the fixation with temperature ramps and the like is because those parameters are for volume production and that makes a huge difference if you are making a thousand units an hour.

This board was manually assembled using my technique. I had a bit of problem with the solder paste, probably because I used a silicone spatula (for cooking) rather than a proper spreader. The solder paste was about 3 years old but kept in the refrigerator.

The picture was taken straight out of the oven, after I removed a bridge across Q1. The assembly is not perfect but that is mainly because of hand assembly and solder paste application, not the oven. In particular, I’d be happier if U4 was aligned properly but the soldering seems OK.

The board was designed and laid out with Kicad.

I wasn’t expecting to post a new version so soon but while preparing some features I discovered an actual bug! Here it is RenumKicadPCBV0203

The bug showed itself when sorting on reference designations and the component orientation was not typical. Unfortunately the Kicad file formats are not very well documented and I did not realize that the reference designation offset was relative to the module’s angular rotation, not absolute. Therefore if the ref des offset was 0.1, 0.2, that doesn’t mean it was 0.1 to the right and 0.2 down relative to the module – it means it was 0.1, 0.2 relative to the original grid of the component. Its actual location is a trigonometry problem which is simple enough to figure out once you figure out what is going on.

So, the adjustment is

X offset = (( Ref_X_Offset * cos( modangle )) + ( Ref_Y_Offset * sin(modangle )));

Y offset = (( -Ref_X_Offset* sin(modangle )) + ( Ref_Y_Offset * cos(modangle )));

In addition to this bug fix, I removed the “Verbose” and “Show Change Array” menu options and instead create three log files:

1. _coord.txt, which shows the module or reference designation coordinates and their “rounded to grid function;
2. _update.txt which shows the nets, reference designations, etc., which will be renamed, and to what
3. _change.txt which is just the reference designation change plan and show how modules were renamed by the code.

These files are pretty small and making them does not seem to have a significant impact on run time. They make it a lot easier to figure out the decisions the software made and its easier to ask for a file than to ask someone to “cut and paste” from a DOS terminal screen.

Besides the obscure bug corrected in the V0203, which I discovered, I am not aware of any errors made in sorting, file updating, etc.. Thus far unexpected results are not the fault of the software but a mismatch between the options used and the design. I actually found the bug because my “test project” ice-zum, has the reference designation for C1 in the place of C2 and vice versa so when sort on modules it showed C2 C1. It was only while correcting that design mistake I realized there was an unrelated bug.

I also cleaned up the code “map to grid” is done only once.

As always feel free to contact me if you have any issues, can’t get it to work right, etc..

 

Note: RenumKiCadPCB has been updated several times to enhance usability and fix bugs. Please check documenteddesigns.com for the most recent version.

 

This RenumKiCadPCBV0202 is the updated Windows 64 application and source code for V0.202 of RenumKiCadPCB.

I moved sorting from the confusing “jog” implementation to a grid based implementation. All module and ref designation locations are rounded to the nearest specified grid point (X, Y) prior to sorting. So a module at 23.1235, 19.568 would be sorted as 23.25, 19.50 if the grid is specified as 0.25.

Note that this does not actually move modules or text: RenumKiCadPCB only changes the names of things not their positions.

Also the “Sort on” default has been changed to “Sort on Modules” based on feedback I received from Nick Barton of Black Magic Amplifiers.

Although I usually sort by Reference Designations, Nick – who is a pro – believes “Sort on Modules” is a far more typical use case.

As always, you can change the “Sort on” parameter from the menu and since V0.201 these choices are “sticky” and saved for the next use.

Note that, unless reference designations, module coordinates are somewhat arbitrary and this may lead to strange results. For example if a diode has the cathode as the origin, two diodes side by side with one rotated (see below)

would be seen as separated by 1 cm (1/2″) on the Y axis whereas the reference designation text would be “on grid” and properly dealt with.

Dealing with “Bad” Renumbering

While there may be bugs in the code (please contact me directly if there are) most reports of “bad” renumbering are due to two reasons:

1. Sorting of reference designations instead of modules or modules instead of reference designations; and
2. Sorting of too fine a grid (or jog in older versions).

RenumKiCad PCB approaches the problem mathematically and if you have placed parts or reference designations 1 mm apart on the sort axis and the sort grid (or jog) is less than 1 mm it will see the parts as being on different lines and number them accordingly.

Remember – the software doesn’t know if you have done a coarse through hole design on a 2.54 mm (0.1″) grid or an ultra-fine pitch layout with 0.1 mm (0.005″) grid, nor does it know whether you have your module origins all in the “right place”.

The options to sort on modules or reference designation and to change the grid are there to provide flexibility.

So if you get a “bad” sort order, try changing the sort target from modules to reference designations and/or adjust the sort grid.

Usually increasing the sort grid fixes things up to a point as making it too large has the opposite effect as all parts will appear to be at the same point.

So try increasing it to 0.25, 0.5, or 1 until you get the desired result. Because the sort works on the original data you can simply run RenumKiCadPCB over and over again on your design until you get what you want.

Always make backups of the original.

I don’t know of any bugs which would ruin your project but I am not responsible – or even want to feel bad – if it does.

The only way I can improve this software is if you provide feedback. Please let me know if you use it and, especially if there are any issues.

 

Note: RenumKiCadPCB has been updated several times to enhance usability and fix bugs. Please check documenteddesigns.com for the most recent version.

I have added a feature to RenumKicadPCB. The program now stores parameters in a file called Renumparameters.txt in the directory it is invoked from. This means you don’t have to keep reentering the path to the file, etc..

Here is a zip file with the instructions for use, source code, and a windows 64 executable renumkicadpcbv0-201

Note: RenumKiCadPCB has been updated several times to enhance usability and fix bugs. Please check documenteddesigns.com for the most recent version.

 

This file RenumKiCadPCBv0200 is V0.200 of RenumKiCadPCB.

RenumKiCadPCB processes a KiCad PCB file and renumbers all the component reference designators ending in numbers based on where they are located on the PCB. It then processes the schematic hierarchy and updates the component reference designators to match. This makes working on a board much easier since you can locate all the components.

V0. 200 includes a number of improvements including a rudimentary text based menu driven interface as well as the original command line. Some command line arguments have been changed to make more sense and some defaults have been changed as well.

V0.200 was also developed on MinGW instead of Cygwin so there is no need for a separate DLL – the executable is stand alone.

To run to the program simply type RenumKiCadPCB (command line arguments are now optional).

I have made and tested the file on Windows (executable included) and Ubuntu Linux. It should work on Apple but I have not tested it.

I hope to port the code over to a proper GUI once I figure out how to set up the compiler, etc..

Let me know if there are any issues, bugs, feature requests.

 

 

Note: RenumKiCadPCB has been updated several times to enhance usability and fix bugs. Please check documenteddesigns.com for the most recent version.

This RenumKiCadPCB.V0103 is an updated version of RenumberKiCadPCB. Earlier today I posted v0.102 and 0.103 updates net names to correct some (but not all) issues associated with netlist imports and pours.

Since I take a second pass on the file to update nets it takes about 100mSecs longer.

Thanks to Andy_P at https://forum.kicad.info/ 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.

Thanks also to PCB_Wiz on https://forum.kicad.info/ who graciously proved a link to this project https://github.com/FPGAwars/icezum/tree/master/src-kicad (which is a beautiful project by the way).

After running V0.101 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. One netlist is flagged no connects even though they appear to be connected. The name of the problem net is neither in the original (pre-run) PCB file or the post run file.

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.