| ID: | 4369 |
| From: | ge...@igor2.repo.hu |
| Date: | Fri, 18 Sep 2020 05:31:10 +0200 (CEST) |
| Subject: | [pcb-rnd] plan for optional "auto quick background checks" |
| replies: | 4370 from Majenko Technologies <ma...@majenko.co.uk> , 4387 from Bdale Garbee <bd...@gag.com> |
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
Reply subtree:
4369 [pcb-rnd] plan for optional "auto quick background checks" from ge...@igor2.repo.hu
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>
4387 Re: [pcb-rnd] plan for optional "auto quick background checks" from Bdale Garbee <bd...@gag.com>