| ID: | 4370 |
| From: | Majenko Technologies <ma...@majenko.co.uk> |
| Date: | Fri, 18 Sep 2020 09:53:17 +0100 |
| Subject: | Re: [pcb-rnd] plan for optional "auto quick background checks" |
| in-reply-to: | 4369 from ge...@igor2.repo.hu |
| replies: | 4371 from ge...@igor2.repo.hu |
--00000000000072938505af92a26b
Content-Type: text/plain; charset="UTF-8"
Personally I have never used, and never intend to use, the enforced
clearance. Like you I think it's not what a good PCB designer should be
being forced to use. I have had to use it in KiCAD before
(it's on by default) and it was an absolute nightmare - especially when it
went wrong and wouldn't let me get anywhere within the radius of a curved
corner.
So it's certainly not something that I would lament being removed and even
put into an optional user script.
Background DRC checks make more sense to me though, as you can look and see
at a glance if there's anything that would need your attention. I like that
idea.
The displaying of the clearance from the style, though, is something that I
absolutely use 100% of the time. That is something that is essential to how
I work - and probably many others too. Where that clearance ultimately
comes from (DRC, the style, netlist attributes, whatever) is not really a
concern for me, I will use whatever, but it is logical that it should be
named the same as what it is - style clearance if it's from the style,
netlist clearance if it's from a netlist attribute, DRC clearance if it's
from the DRC.
Personally I usually have the same clearance for all styles unless I have a
really specific reason not to, so wherever the value comes from it'll be
the same for me... 0.15mm...
What would be nice, and this can probably already be done with the new DRC
system, though I wouldn't know how, is to differentiate between trace and
padstack clearances. For example, 0.15mm clearance for all traces minimum,
and 0.3mm clearance for all padstacks minimum. Some fab houses like to have
more clearance around pads than they allow for traces. Of course, that
makes deciding on the right clearance tricky when you have a trace
alongside a pad... the trace would need to be 0.3mm away from the pad,
even though it's specified as having 0.15mm clearance. Something that, if I
read your reasoning right, is not possible to display with the new DRC "on
the fly", so could never be represented in the clearance cursor display.
TBH that's no big deal really, as long as it would flag up in the
background checks that something isn't quite right.
On Fri, Sep 18, 2020 at 5:18 AM <gedau@igor2.repo.hu> wrote:
> Hi all,
>
> as you see from the previous mail on "show/enforce drc clearance",
> flexibility comes with a price: writing drc rules is easy, as you don't
> need to script the solution, only the check.
>
> In other words, you don't need to write a complicated program that tells
> the computer how to draw a board with all features accepteble in regard of
> a specific aspect, but the simple program that can decide if a specific
> drawing is already there, there's no object (or pair of objects...) that
> is borken in that specific aspect. Or in a more theoretical way: you don't
> need to write a program the produces the good solution for a problem,
> you only need to write a program that decides if a solution (that is
> presented as input) is good or not.
>
> The price of this flexibility and simplicity is that we can't get
> the drc scripts tell _in advance_ if a construct is going to be good or
> bad, we can tell it only when it's drawn; and especially it can't tell
> what ways a construct is going to be good or bad, e.g. what clearance
> value you need to use in a given situation so that it won't violate any
> rule at the end.
>
> But is that really bad?
>
> At this point, it becomes a more phylosophical question: how much pcb-rnd
> should be a 'nanny' trying to validate each editing step you do and say
> "no no, you can't do that, bad boy!", trying to keep you from "doing the
> wrong thing" or even trying to tell the user what exactly to draw.
>
> My standpoint is, and always was, that that's not the way pcb-rnd should
> work. We should let the user do whatever he wants and offer tools to
> _assist_ the user to figure if what is done fails to comply with
> predefined rules/parameters. This is the "free edit" approach. This allows
> the user to implement a big edit operation that consists of multiple steps
> in the easy way:
>
> - we assume the board was good before the edit
>
> - the actual big edit consists of a series of atomic small edit operations
> (draw a line, delete an object, move an object, change a property); the
> board may get broken between any of these atomic steps
>
> - we sort of require that the board is good again after all atomic steps
> are finished.
>
> In other words, between the first and last point where the board is valid,
> there are dozens of different paths the user can take: which atomic edit
> operations are used in what order exactly. In a nanny-mode software, the
> user is forced to choose one of the very few paths where the board remains
> valid between any two atomic steps. In the free edit variant that pcb-rnd
> prefers, the user is free to choose any path and have temporarily invalid
> board (with short circuits, or at least DRC violations), because what
> matters is only that at the end the board is valid again.
>
> In this sense any "enforce" thing in the cursor is just a bad idea.
> However, when done with the style clearance, and kept optional, it is
> acceptable, as a drawing aid. A bit like the grid, which somewhat limits,
> enforces where you can go. But the point is: I don't want to get this part
> too complicated, as pcb-rnd is generally not following the 'nanny'
> approach.
>
> On the other hand: it's also a valid requirement from the user that
> pcb-rnd should figure and tell the user if the board _unintentionally_
> changed from valid to invalid. That is: if it became invalid because the
> user is in the midlde of a multi-step-edit, that's fine, expected; but if
> the user thinks he has finished the multi-step edit and he thinks the
> board is valid now but it is really not, that's an error, and some user
> may reason that pcb-rnd needs to detect that and warn the user.
>
> However pcb-rnd has no idea if the user is in the middle of a
> multi-step-edit or if the user has just finished one. But what we still
> can do, as a long term plan:
>
> - we could have an _option_ for a background task; when enabled
> pcb-rnd could run a few checks in the background "after each edit step"
>
> - with majority of the computers being multi-core (even the single-board
> PI computers!) these days, and pcb-rnd being single-threaded, this simply
> wouldn't slow down anything in practice
>
> - this would probably run rat optimization ({c r}) and DRC checks, both in
> a non-intrusive way (e.g. it wouldn't change rats on screen and wouldn't
> highlight or mark objects and wouldn't pop up windows)
>
> - the result of the background check would be a few numbers: how many
> problems each check found; we could simply print these numbers in
> the status bar somehwere
>
>
> In practice, on the GUI: if the board is all valid, the numbers are 0. Or
> if there are known errors the user decided to live with, the numbers are
> at a specific value (that the user sort of remembers). Then the user
> starts editing. Upon board changes, the numbers may change. If the numbers
> increase, they would probably get marked with red. The user could look at
> the numbers any time and could decide if it's expected that they have
> rised (middle of a multi-step-edit) or unexpected (wow, I thought I've
> finished and it's all good now!). When the user thinks he has
> finished, the user can check if the numbers went back to 0 (or the
> normal, accepted level of errors).
>
> When in doubt why the numbers are that high, the user can run {c r} and
> the DRC to get to the details.
>
> This all could fit in a nice little plugin. It's not even too hard to
> code. Question is if it sounds useful enough to get it done.
>
> Best regards,
>
> Igor2
>
>
>
>
>
>
--
*Matt Jenkins*
Majenko Technologies
https://majenko.co.uk
--00000000000072938505af92a26b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Personally I have never used, and never intend to use=
, the enforced clearance. Like you I think it's not what a good PCB des=
igner should be being forced to use.=C2=A0 I have had to use it in KiCAD be=
fore<br></div><div>=C2=A0(it's on by default) and it was an absolute ni=
ghtmare - especially when it went wrong and wouldn't let me get anywher=
e within the radius of a curved corner. <br></div><div><br></div><div>So it=
's certainly not something that I would lament being removed and even p=
ut into an optional user script.</div><div><br></div><div>Background DRC ch=
ecks make more sense to me though, as you can look and see at a glance if t=
here's anything that would need your attention. I like that idea. <br><=
/div><div><br></div><div>The displaying of the clearance from the style, th=
ough, is something that I absolutely use 100% of the time. That is somethin=
g that is essential to how I work - and probably many others too. Where tha=
t clearance ultimately comes from (DRC, the style, netlist attributes, what=
ever) is not really a concern for me, I will use whatever, but it is logica=
l that it should be named the same as what it is - style clearance if it=
9;s from the style, netlist clearance if it's from a netlist attribute,=
DRC clearance if it's from the DRC.</div><div><br></div><div>Personall=
y I usually have the same clearance for all styles unless I have a really s=
pecific reason not to, so wherever the value comes from it'll be the sa=
me for me...=C2=A0 0.15mm...</div><div><br></div><div>What would be nice, a=
nd this can probably already be done with the new DRC system, though I woul=
dn't know how, is to differentiate between trace and padstack clearance=
s. For example, 0.15mm clearance for all traces minimum, and 0.3mm clearanc=
e for all padstacks minimum. Some fab houses like to have more clearance ar=
ound pads than they allow for traces. Of course, that makes deciding on the=
right clearance tricky when you have a trace alongside a pad...=C2=A0 the =
trace would need to be 0.3mm away from the pad, even though it's specif=
ied as having 0.15mm clearance. Something that, if I read your reasoning ri=
ght, is not possible to display with the new DRC "on the fly", so=
could never be represented in the clearance cursor display. TBH that's=
no big deal really, as long as it would flag up in the background checks t=
hat something isn't quite right.<br></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 18, 2020 at 5:18 =
AM <<a href=3D"mailto:gedau@igor2.repo.hu">gedau@igor2.repo.hu</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br=
>
<br>
as you see from the previous mail on "show/enforce drc clearance"=
, <br>
flexibility comes with a price: writing drc rules is easy, as you don't=
<br>
need to script the solution, only the check.<br>
<br>
In other words, you don't need to write a complicated program that tell=
s <br>
the computer how to draw a board with all features accepteble in regard of =
<br>
a specific aspect, but the simple program that can decide if a specific <br=
>
drawing is already there, there's no object (or pair of objects...) tha=
t <br>
is borken in that specific aspect. Or in a more theoretical way: you don=
9;t <br>
need to write a program the produces the good solution for a problem, <br>
you only need to write a program that decides if a solution (that is <br>
presented as input) is good or not.<br>
<br>
The price of this flexibility and simplicity is that we can't get <br>
the drc scripts tell _in advance_ if a construct is going to be good or <br=
>
bad, we can tell it only when it's drawn; and especially it can't t=
ell <br>
what ways a construct is going to be good or bad, e.g. what clearance <br>
value you need to use in a given situation so that it won't violate any=
<br>
rule at the end.<br>
<br>
But is that really bad?<br>
<br>
At this point, it becomes a more phylosophical question: how much pcb-rnd <=
br>
should be a 'nanny' trying to validate each editing step you do and=
say <br>
"no no, you can't do that, bad boy!", trying to keep you from=
"doing the <br>
wrong thing" or even trying to tell the user what exactly to draw.<br>
<br>
My standpoint is, and always was, that that's not the way pcb-rnd shoul=
d <br>
work. We should let the user do whatever he wants and offer tools to <br>
_assist_ the user to figure if what is done fails to comply with <br>
predefined rules/parameters. This is the "free edit" approach. Th=
is allows <br>
the user to implement a big edit operation that consists of multiple steps =
<br>
in the easy way: <br>
<br>
- we assume the board was good before the edit<br>
<br>
- the actual big edit consists of a series of atomic small edit operations =
<br>
(draw a line, delete an object, move an object, change a property); the <br=
>
board may get broken between any of these atomic steps<br>
<br>
- we sort of require that the board is good again after all atomic steps <b=
r>
are finished.<br>
<br>
In other words, between the first and last point where the board is valid, =
<br>
there are dozens of different paths the user can take: which atomic edit <b=
r>
operations are used in what order exactly. In a nanny-mode software, the <b=
r>
user is forced to choose one of the very few paths where the board remains =
<br>
valid between any two atomic steps. In the free edit variant that pcb-rnd <=
br>
prefers, the user is free to choose any path and have temporarily invalid <=
br>
board (with short circuits, or at least DRC violations), because what <br>
matters is only that at the end the board is valid again.<br>
<br>
In this sense any "enforce" thing in the cursor is just a bad ide=
a. <br>
However, when done with the style clearance, and kept optional, it is <br>
acceptable, as a drawing aid. A bit like the grid, which somewhat limits, <=
br>
enforces where you can go. But the point is: I don't want to get this p=
art <br>
too complicated, as pcb-rnd is generally not following the 'nanny' =
<br>
approach.<br>
<br>
On the other hand: it's also a valid requirement from the user that <br=
>
pcb-rnd should figure and tell the user if the board _unintentionally_ <br>
changed from valid to invalid. That is: if it became invalid because the <b=
r>
user is in the midlde of a multi-step-edit, that's fine, expected; but =
if <br>
the user thinks he has finished the multi-step edit and he thinks the <br>
board is valid now but it is really not, that's an error, and some user=
<br>
may reason that pcb-rnd needs to detect that and warn the user. <br>
<br>
However pcb-rnd has no idea if the user is in the middle of a <br>
multi-step-edit or if the user has just finished one. But what we still <br=
>
can do, as a long term plan:<br>
<br>
- we could have an _option_ for a background task; when enabled<br>
pcb-rnd could run a few checks in the background "after each edit step=
"<br>
<br>
- with majority of the computers being multi-core (even the single-board <b=
r>
PI computers!) these days, and pcb-rnd being single-threaded, this simply <=
br>
wouldn't slow down anything in practice<br>
<br>
- this would probably run rat optimization ({c r}) and DRC checks, both in =
<br>
a non-intrusive way (e.g. it wouldn't change rats on screen and wouldn&=
#39;t <br>
highlight or mark objects and wouldn't pop up windows)<br>
<br>
- the result of the background check would be a few numbers: how many <br>
problems each check found; we could simply print these numbers in <br>
the status bar somehwere<br>
<br>
<br>
In practice, on the GUI: if the board is all valid, the numbers are 0. Or <=
br>
if there are known errors the user decided to live with, the numbers are <b=
r>
at a specific value (that the user sort of remembers). Then the user <br>
starts editing. Upon board changes, the numbers may change. If the numbers =
<br>
increase, they would probably get marked with red. The user could look at <=
br>
the numbers any time and could decide if it's expected that they have <=
br>
rised (middle of a multi-step-edit) or unexpected (wow, I thought I've =
<br>
finished and it's all good now!). When the user thinks he has <br>
finished, the user can check if the numbers went back to 0 (or the <br>
normal, accepted level of errors). <br>
<br>
When in doubt why the numbers are that high, the user can run {c r} and <br=
>
the DRC to get to the details.<br>
<br>
This all could fit in a nice little plugin. It's not even too hard to <=
br>
code. Question is if it sounds useful enough to get it done.<br>
<br>
Best regards,<br>
<br>
Igor2<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><b>Matt Jenkins</b><=
div>Majenko Technologies</div><div><a href=3D"https://majenko.co.uk" target=
=3D"_blank">https://majenko.co.uk</a></div></div></div></div></div>
--00000000000072938505af92a26b--
Reply subtree:
4370 Re: [pcb-rnd] plan for optional "auto quick background checks" from Majenko Technologies <ma...@majenko.co.uk>
4371 [pcb-rnd] DRC: different clearance for padstack (Was: Re: plan for optional from ge...@igor2.repo.hu
4373 Re: [pcb-rnd] DRC: different clearance for padstack (Was: Re: plan from N <ni...@gmail.com>
4374 Re: [pcb-rnd] DRC: different clearance for padstack (Was: Re: plan from Majenko Technologies <ma...@majenko.co.uk>
4376 Re: [pcb-rnd] DRC: different clearance for padstack (Was: Re: plan from N <ni...@gmail.com>