Auto-enforce-DRC : cannot draw with exact clearance

[Sirichai Pornsarayouth]

[Problem]
I'm using pcb-gtk on Ubuntu 12.04. For example, I set global clearance to 10 mil, set grid size to 10 mil and draw the first 10 mil line somewhere on PCB. When Auto-enforce-DRC is turned on, I could not draw a second line 20 mil away from the first line.

[Further details]
However when I tried to draw a second line >20 mil away from the first line and using the enabled Auto-enforce-DRC to draw a 45-degree line to the first line and continue the second line on parallel with the first line ( \_ ), the parallel line could be placed on exact 20-mil away from the first line.

Then if I try to draw the third line over the second line (snap to the center of the second line), I can successfully draw the third line on exact 20-mil away from the first line (still could not on the other side of the first line). However If I save file.pcb and close the program and reopen the file again, I could not draw the third line over the second line (snap to the center of the second line).

I routed half of my PCB using Auto-enforce-DRC enabled. After I closed and reopened file.pcb again on the next day, DRC reports clearance error on lines with exact 10 mil spaced. Also It is very difficult to modify those lines (on dense PCB).

Thank you very much

[David Austin (david-d-austin)]

There's profound issues with the use of Auto-enforce-DRC and the internal rounding that takes place.

As an easy workaround, I suggest adding a preference setting for a tiny amount of extra clearance to add when "Auto-enforce-DRC" is used.

[Bert Timmerman (bert-timmerman)]

Picked from the geda-user mailing list:

Spent several days trying to fix this bug:
https://bugs.launchpad.net/pcb/+bug/1013358

I was convinced that it is due to rounding errors somewhere in find.c/search.c,
when DRC clearance and grid spacing are the same. But turns out, it is not.
Please, see the trivial patch in attachment. Looks like it solves the
described problem.

I'm suspicious if the bug is fixed _that_ simple (taking into account my
shallow knowledge of codebase).

It would be great if someone explain what was the intention of "PCB->Bloat +
1" in that place? Maybe it is vital for some other actions, not related to
this bug?

Thanks!

--
Best regards,
Anton Dubniak

[Peter Clifton (pcjc2)]

Looks like a good fix to me - I'll commit it today - just waiting for a companion patch as discussed with the author on IRC.

Peter

[Peter Clifton (pcjc2)]

Fixed with commit http://git.geda-project.org/pcb/commit/?id=85abc6ef9792d8da4879cbe975537373b3c2ac30