Bulk DRC Settings - Python Code

[BlackCoffee]

Listing in Software per ‘Software’ description… ‘other curious Quirks’

Amusing myself… Recently, another User’s Post discussed DRC bulk setting changes and I spent some time fooling with Python code for it…

Except for one User, there were no additional follow-up posts and, though I did not intend to mess with it further, my new Telescope project needed to use DRC setting’s for JLCPCB (otherwise, I seldom bother with DRC if I’m milling the PCB).

True, it’s very easy to “Import Settings from Another Project” in the Board-Setup panel - I did that. But, curiosity pushed me to look at the default kicad_pro file. Although I have noticed ‘this’ before, I did not look into it further and just let Kicad do it’s thing.

But, that old ‘Curiosity’ thing nagged at me - observation of ‘this’ is as follows:

It’s not really ‘random’ but sort-of is…

Example:
Loading a new project shows default “minimum_uVia diameter as 0.2” in the panel. It shows it as 0.2 but, the kicad_pro file shows it as 0.19999999999999998". That’s dimensionally the same, for practical PCB purpose’s.
But, ‘why’ does it do it and ‘why’ for only some values, not all? It happens with some other values, I’m just using uVia for example…

If I manually change the 0.19999… to 0.2, then the kicad_pro file reflects this.

So, the question is: Why does Kicad take an initial default value of 0.2 and replay it as 0.19999… in the file but not do it if that 0.2 is entered by User? From where does that default 0.2 come from (is it really 0.019999… and rounded up for the panel)?

Side note: as seen in below video, I’m nearly finished with this fun coding effort - not shown is displaying of only the Rules section of kicad_pro file (it’s turned Off for testing purposes). When turned On, the file contents shows only the Rules section for cleaner visibility. And, Double-Clicking a value will auto-populate the Search field.

When finished, those six DRC-Set’s will contain custom rules and will fully replace/Transfer All the current Rules in the file. I’ve only built Rules-files for JLCPCB and some of my projects (as there were no posts from users, I did it for my own needs). I will also include a Tolerance-Fidelity input or slider that will tweak the panel’s values by Percentage.

[qu1ck]

I have no comment on drc stuff but the 0.19999999999999998 you are seeing instead of 0.2 is obviously floating point precision artifact, someone just forgot to do rounding somewhere.

[paulvdh]

KiCad uses 32 bit integers with nanometer resolution on the PCB, and it would be only logical to do do that for via parameters too. 0.199999999998 is most likely a floating point rounding artifact. Some functions (for example trigonometry) works with floating point only. Rounding to the nearest nanometer (6 digits more then mm) would be a logical step, but if you round numbers too often, then this can also cause calculation artifacts. Floating point numbers act quite strange in some ways.

[BlackCoffee]

@qu1ck @paulvdh … Yes, I suspect it’s somewhere in the ‘Kicad behind the scenes’ calc’s.

That said, I Just created a New Project:
• Having no footprints placed, I opened kicad_pro in text editor, no Rules content.
• I Placed one Footprint and one Track, set Track width min (to 0.345) in DRC settings and saved, then opened kicad_pro and now the Default Rules/etc are in the kicad_pro file.

The file shows the ‘artifact’ of 999999…etc but, the question is, 'an artifact of what calculation’ ? Or, artifact of whatever happens, such as Kicad grabbing some values and populating the Panel… Even so, if that’s what is happening, why does it take the value(s) and do something to them such that it changes? I understand the 8,16,32,64,128 bit Floating, Double, Integer accuracy errors.

I suppose it’s ‘the way it is’ but, it doesn’t happen for all the values in the panel. I also understand coding one thing is not necessarily the same as coding another thing… Not to mention different Platforms/systems…

Except for the .345 I entered, all other values are Virgin panel values that get messed with… screenshot. What happens on other systems with Kicad?

Not a problem for me, just Curious…

[qu1ck]

Floating point numbers don’t need calculations to be inaccurate. They literally can not represent some simple values accurately, for example 0.5 is exactly 0.5 because it’s 1/2 and 2 is something evenly divisible in binary while 0.3 or 0.2 is not because 3/10 or 1/5 is not evenly divisible in binary.

Write a simple program in C that reads a floating point and prints it back, you will see that.

quick@r710:~/src/test_fp$ cat test_fp.c
#include <stdio.h>

int main() {
  double a;
  scanf("%lf", &a);
  printf("%.20lf\n", a);
  return 0;
}

quick@r710:~/src/test_fp$ gcc test_fp.c -o test_fp
quick@r710:~/src/test_fp$ ./test_fp
0.2
0.20000000000000001110
quick@r710:~/src/test_fp$ ./test_fp
0.5
0.50000000000000000000

[BlackCoffee]

yes, yes, yes I understand all that. My point, though not stated, is why have a Value-Field in the panel that handles round-off from a Kicad_pro file, rather than pushing out the full number string (of course, we’d hate that, all those useless digits). But, why not also truncate them in the kicad_pro file? Apparently some values get truncated/round off.
The panel’s values are for User Input and aren’t calculated (except for the initial values in the Kicad_pro file. Thus, they’re coming from code. Most likely, declared-hard values. Kicad can’t calculate what a User’s min-track width setting is without the User’s input. So, it gets some default value(s)…

Oh, I know the answer to that (I was a Debug consultant to Microsoft and Oracle)… OMG!

[paulvdh]

I’m thinking it may be a bug. My rationale is that KiCad uses coordinates with nanometer resolution, and I would expect settings in the project file to have this same resolution. Maybe it’s worth reporting, but today I’m not thinking clear enough about details anymore. Maybe I’ll revisit this topic tomorrow.

[BlackCoffee]

@paulvdh I agree, a Bug.

Below image shows my entries of stupid values with several digits - some (10 of them) show up as entered while 3 others get messed up, for example 0.0345 gets 0.3449999… There are a few other’s (not DRC) in the file with the same ‘bug’.
There are two 0.345 values I entered but, only one got messed up… go figure.

I can live with it for my coding by using conditional check’s and, what can I say, it’s Open-source software and Free so, I haven’t a right to complain, I guess…

I stopped paying thousands of dollars for various CAD program Maintenance contracts and happily live with FreeCAD’s bug’s…

[paulvdh]

I just did a:
paul@cezanne:~/projects/kicad$ grep "999" ./*/*.kicad_pro

And it turns out that at least 12 of my projects have these silly numbers in them.

Another grep shows mixed results for both “normal” and “silly” numbers for the same variable between different projects.

paul@cezanne:~/projects/kicad$ grep "min_via_diameter" ./*/*.kicad_pro
./00aa_lib/00aa_lib.kicad_pro:        "min_via_diameter": 0.5,
./00aa_module.pretty/00aa_module.pretty.kicad_pro:        "min_via_diameter": 0.5,
./7-Segment/7-segment.kicad_pro:        "min_via_diameter": 0.4,
./beyerdynamic_A1_clone_kit/beyerdynamic_a1_clone_kit.kicad_pro:        "min_via_diameter": 0.5,
./breakout_soic8/breakout_soic8.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./display_8x8_595_002.kicad_pro/display_8x8_595_002.kicad_pro.kicad_pro:        "min_via_diameter": 0.4,
./display_8x8_595_003/display_8x8_595_003.kicad_pro:        "min_via_diameter": 0.4,
./display_8x8_595/display_8x8_595.kicad_pro:        "min_via_diameter": 0.4,
./integrator/integrator.kicad_pro:        "min_via_diameter": 0.5,
./kelvin_varley/kelvin_varley.kicad_pro:        "min_via_diameter": 0.4,
./LED_PT4115/LED_PT4115.kicad_pro:        "min_via_diameter": 0.4,
./Load_Programmable_Resistors/Load_Programmable_Resistors.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./Motor_Controller/Motor_Controller.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./motor_stspin32f0/motor_stspin32f0.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./Motor_TO252/Motor_TO252.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./Motor_ZZQ161121/Motor_ZZQ161121.kicad_pro:        "min_via_diameter": 0.5,
./opamp_offset/opamp_offset.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./Power_smps_HV/Power_smps_HV.kicad_pro:        "min_via_diameter": 0.39999999999999997,
./scara_slipring_encoder/scara_slipring_encoder.kicad_pro:        "min_via_diameter": 0.39999999999999997,

There are also 8 projects with “silly numbers” in this setting, so silly numbers change location depending on moon phases or whatever. From the number of lines. about half the projects do not have the “min_via_diameter” variable at all in it’s project file.

It’s both weird / unexpected and seemingly harmless. I don’t know whether this would be worth reporting or fixing. KiCad developers already have many bugs, feature requests and ideas to divide their attention over then they have time to implement them. On the other side of the equation, there could be some bugs lingering here and I’d like to see a “robust” implementation.

In the mean time, when working with floating point numbers, you should never ever compare for equalness, but always compare against some range. (Bigger or smaller then some limit, from X to Y, etc).

[BlackCoffee]

@paulvdh

when working with floating point numbers, you should never ever compare for equalness,

Yep, I don’t compare numbers beyond the significant number of digits I need (as a ‘former’ rocket scientist, I/we tested this kind of stuff (and influence of EMI and Nuclear Radiation/Bombardment) on Chips, circuits and other… in ‘Live’ influence testing and watched stuff change within the Blink of and Eye, literally!

I taught Tolerance Stackup/Buildup so, this kind of stuff both interests and, bug’s me, when I see Code/designs and others talk about number’s and significant digits needing to be, example: 25.03629553mm, for something as stupid as a machined gizmo from a machine with a tolerance machining ability of 0.001 Inch (0.0254mm). In these Modern Day’s, I refer to these folks as ‘iPhone’ people…, no offense to anyone

[bask185]

Is it this what caused that annoying bug which tossed DRC errors on clearences all the time? Most annoying one was it.

[BlackCoffee]

I can’t say for certain but, probably yes… if the item’s value being checked is close to one of those funky values…

[der.ule]

I cannot be certain but it may be the reason why opening old schematic files with the new v8 version places almost all symbols off grid and thus the reason for the new “align to grid” command.

[paulvdh]

@bask185

Is it this what caused that annoying bug which tossed DRC errors on clearences all the time? Most annoying one was it.

Do you have any specifics? I remember one bug when pads fitted exactly with the design rules (for example 0.5mm pitch QFP with 0.2mm track width and 0.3mm clearance) which trew DRC errors when the footprint was rotated. I spend around 10 minutes to find it on gitlab, but no results.

My bet is on “something else”. KiCad works internally with 32 bit integers and nanometer resolution. Counting the nines, these silly numbers have deviations that are 10 orders of magnitude smaller.

These silly numbers are far beyond even atomic scale.

For comparison:

0.39999999999999997   // [mm] Silly KiCad number for"min_via_diameter" (Copy / Paste from project file).
0.000001              // [mm] Resolution of KiCad files, 1nm.
0.0000001             // [mm] Size of hydrogen atom (sort of 1 Angstrom, 100pm)
0.000000000001        // [mm] Size of nucleus of an hydrogen atom ( 1fm scale)

Atom

And though the numbers are just silly. I guess it is worth making a bug report so some of the developers have a little memory jog about how to handle number rounding and truncation. I can’t exclude it was not related to such bugs

[BlackCoffee]

I looked at some old 2021 files, the format (indentation) is different and so are the numbers. Example below.

One did have the weird number of 0.0999999999999 for a value that should be 0.1 but that’s the only weird number. (other numbers were correct but carried the full number of decimal places

On the ‘logic’ aspect, if I were coding a conditional or looping statement such as:

“if X<= min_value_DRC”,

and I set my X (say it’s Track width min) to 0.2
and the min_value_DRC got weirded out to 0.199999999999, then logic suggests it would through an Error/not-pass-the-test of 0.2

Yeah, I think it worth a Bug report…
Notice the Date at the top of this one… 2015

ADDED: Added Video of what I’m referring to (Pass, Fail DRC).
Two Tracks both have Width=2mm, One case, Conditional checks for 2mm, other case it checks for Weird Value, 1.9999999etc… The Top one is already selected to show it’s Width in Panel on left side.

[bask185]

@paulvdh

Do you have any specifics?

Not at this time. If I encounter it, I’ll make a screenshot. As far as I know it was a quite common bug, there has been atleast 1 thread about it that I can remember…

After you started a board, run the board setup, you could just route like you normally do and place vias and what not. And as soon as you run DRC you get these errors that soms via’s and tracks have clearance errors. Saying that the clearence is for example 0.199999999999999mm (I did not count the 9s) while the board was configured for 0.2mm. It was a quite a common thing in the beginning of V7 iirc.

It was often easy to fix by dragging a few things or you could just ignore the error… or turn it off

Kind regards

Bas

[dsa-t]

Note that this rounding bug was fixed 5 months ago.

[kicad_pro]: Use the same (rounded) numbers as seen in the GUI (#17070) ·...

[dsa-t]

@bask185

Is it this what caused that annoying bug which tossed DRC errors on clearences all the time? Most annoying one was it.

The values read from the kicad project were rounded to nanometers anyway, so this was a purely visual bug.

[dsa-t]

@der.ule

opening old schematic files with the new v8 version places almost all symbols off grid and thus the reason for the new “align to grid” command.

Please file a bug report if you have examples.

[der.ule]

Not exactly sure when it happened, but I have had to rework some old schematics and the first step is to correct the connections, maybe I am doing something wrong, so far I just did it and kept at it.

EDIT: Just to be clear, it is a bit different to what I describe, the schematics open fine, but when editing somehow they go off-grid.