Bug, DRC Track Width adjusts itself?

This is the third time tonight, and I’m working on narrowing it down.

I was attempting to create a Template for different specifications for different fab houses.

I KNOW that Track Width was set to 0.006 and had NOT been changed by me.

I KNOW that Diff Pair Width was set to 0.012 and had NOT been changed by me.

I KNOW that Diff Pair Gap was set to 0.012 and had NOT been changed by me.

Ever since a 4.0 stable release I have had grid and DRC differences. Although I am currently running the 09SEP17 build, I have reason to suspect that underlying parts of this issue crept into the code nearly a year ago.

I mainly use the inch grid. I suspect that if I mainly used the metric grid I’d probably not have any issues; as no other users on this forum have mentioned issues with this nightly.

ON EDIT: This is how I know these were set to OSH Park settings>

I was working out a whole list of “Template” settings to submit to the forum. Well, that’s no longer going to happen tonight.

1 Like

Keep testing, once you know how to replicate, file a report on the tracker :wink:

Do you ever change between Metric and Imperial grid pitches? Or, are any of your available track widths (or via sizes) expressed as a Metric value, even though your grid pitch is defined in Imperial units?

In your first illustration, I will wager that those strange numbers - the ones carried out to about 28 decimal places - are actually “nice” values when expressed in Metric units. I may have noticed something similar to this several months ago, but (as I recall) I traced it down to my using Imperial units for most of the project, but drafting one footprint using a Metric grid.


1 Like

I swap between the two units all of the time; changing grids and measurement display. I have both imperial and metric parts.

I suspect the design rules either are not quite making the complete round-trip from one system to the other and back again, or perhaps are getting reset to default values at some point in the journey. I wish I could suggest an efficient method to isolate the bug, but the only thing that comes to mind is to repeatedly check the design rules as you work.


1 Like

It’s not that issue. It happens even if I remain using only imperial units.

The neat trick about this bug is that it changes the default track width and sets it as the “Default” which then gets displayed in the menu bar.

I’ve been using 10mill traces that get changed to 0.9##### which is not a big enough change to see when laying out traces.

I found out how to duplicate the bug reliably with my settings as they are.

I’m sorta guessing what the Diff Pair settings should be. My board has both imperial and metric parts. The imperial parts are placed on an imperial grid, and the metric parts were placed on a metric grid. The board has fill zones surrounding the board on the imperial grid.

Set the above settings.
Run DRC.
Save the file.
Close PcbNew.
Re-Open PcbNew.


I’ve duplicated this at least 5 times in a row.

Application: kicad
Version: (2017-09-08 revision 19ad350c1)-makepkg, release build
wxWidgets 3.0.3
libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.60.0
Curl: 7.54.1
Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:

ON EDIT: It happens when I press the B key to rebuild the zones, save, exit, and re-open.

1 Like

I am unable to re-create using your steps. Can you show what your global rules are? Also, is there a pcbnew board you could attach?

I had this problem a few weeks ago. I download and compile from source now and then, and with the version I have now, after a short test, the problem seems to have gone away.

Application: kicad
Version: (2017-10-12 revision e0b9a2141)-master, release build
wxWidgets 3.0.2
Platform: Linux 4.10.0-37-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.62.0
Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:

I would, except that further testing has proven that it has nothing to do with any individual board. I have tested with an extremely simple, all imperial, board file and it still has this bug.

If no one else has this bug in a more current nightly, I’m going to consider it “already fixed” and not bother to report it.

So, please, if anyone has a more recent version, and can confirm that this bug no longer exists, please reply such here.