Bulk DRC Settings - Python Code

Software
5

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
6

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!

7

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.

8

@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…

Screen Shot 2024-07-28 at 08.37.48
Screen Shot 2024-07-28 at 08.37.48756×504 65.9 KB

9

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).

1 Like
10

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 :innocent:

11

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

12

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

13

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.

14

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)

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

15

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.

Screen Shot 2024-07-30 at 06.54.50
Screen Shot 2024-07-30 at 06.54.50672×756 76.9 KB

16

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 :stuck_out_tongue:

Kind regards :wine_glass:

Bas

17

Note that this rounding bug was fixed 5 months ago.

1 Like
18

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

19

Please file a bug report if you have examples.

20

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.

21

Often it’s the other way around. First somehow they became off-grid (or on a finer grid), and later the grid is set to the most common 50mil [1.27mm] and symbols get aligned to that grid. Schematic symbols have a quite strict requirement for a 100mil grid between pins and sometimes (resistors, capacitors) shifted 50mil to the symbol anchor point. Maybe the new Grid overrides introduced in KiCad V8 changed the default so KiCad now puts things back on a 50mil grid.

A quick way to fix most grid problems in the schematic editor is:

  1. Set the grid to 50mil.
  2. Select everything, draw a box around the paper.
  3. Right click, and from the context menu select: Align Items to Grid.

In some occasions this can create shorts in your schematic, so watch out for that.

22

In this case it actually makes the matters worse, but selecting everything and moving it, mostly leaves everything on grid again, except for the couple of odd connections.

23

Also, instead of m to move, you can use g to drag, which keeps the wires attached. For several KiCad versions these drags are now ortogonal and it works well.

24

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.