On 5 Jul 2019, at 12:19, Jeff Young <jeff@xxxxxxxxx> wrote:
(setup
(last_trace_width 0.25)
(trace_clearance 0.2)
(zone_clearance 0.508)
(zone_45_only no)
(trace_min 0.2)
(via_size 0.8)
(via_drill 0.4)
(via_min_size 0.4)
(via_min_drill 0.3)
(user_diff_pair 1 2 3)
(uvia_size 0.3)
(uvia_drill 0.1)
(uvias_allowed no)
(uvia_min_size 0.2)
(uvia_min_drill 0.1)
(max_error 0.005)
(defaults
(edge_clearance 0.01)
(edge_cuts_line_width 0.05)
(courtyard_line_width 0.05)
(copper_line_width 0.2)
(copper_text_dims (size 1.5 1.5) (thickness 0.3) keep_upright)
(silk_line_width 0.12)
(silk_text_dims (size 1 1) (thickness 0.15) keep_upright)
(other_layers_line_width 0.1)
(other_layers_text_dims (size 1 1) (thickness 0.15)
keep_upright)
)
(pad_size 1.524 1.524)
(pad_drill 0.762)
(pad_to_mask_clearance 0.051)
(solder_mask_min_width 0.25)
(aux_axis_origin 0 0)
(visible_elements FEFFFF7F)
(pcbplotparams
(layerselection 0x01000_7fffffff)
(usegerberextensions false)
(usegerberattributes false)
(usegerberadvancedattributes false)
(creategerberjobfile false)
(excludeedgelayer true)
(linewidth 0.101600)
(plotframeref false)
(viasonmask false)
(mode 1)
(useauxorigin false)
(hpglpennumber 1)
(hpglpenspeed 20)
(hpglpendiameter 15.000000)
(psnegative false)
(psa4output false)
(plotreference true)
(plotvalue true)
(plotinvisibletext false)
(padsonsilk false)
(subtractmaskfromsilk false)
(outputformat 5)
(mirror false)
(drillshape 0)
(scaleselection 1)
(outputdirectory ""))
)
Good to go?
Cheers,
Jeff.
(I can post the code later, but our git instance seems to be down.)
On 5 Jul 2019, at 02:32, hauptmech <hauptmech@xxxxxxxxx> wrote:
Not requiring DR/DRC is appreciated.
Netclasses don't work with my designs on a fundamental level and if
there were not a way I could ignore them, I would not be able to use
KiCAD. Likewise the new interactive router which spends most of its
time in Highlight Collisions mode with Allow DRC Violations. I use
it normally when I can, but that's not very often.
The knowledge of the kicad developers of leading edge and specialist
board design has consistently been limited and if you bake in that
limited knowledge into DR/DRC with no fallback, you will shoot some
users in the foot.
It doesn't need to be the old system but it does need to be free of
assumptions about what is acceptable data for the manufacturer and
what is acceptable practice for the designer.
On 5/07/2019 11:45 AM, Jeff Young wrote:
Hi Seth,
I was thinking about a similar issue which is that we probably
can’t require users to move to the new DR system (as it will be
considerably more technical). So perhaps using the old system as
defaults which can be overridden by the new makes sense.
Cheers,
Jeff.
On 4 Jul 2019, at 22:40, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
Hi Jeff-
Ideally, I'd like to find an option that doesn't need to move twice
during v6. Toward that goal, what if we moved edge_clearance to the
defaults section? Until we implement the design rules and/or
polygon-specific clearance, it simply controls everything. Once we
integrate the new features, they are allowed to override the
default.
Thoughts?
-Seth
On 2019-07-04 12:07, Jeff Young wrote:
Looking through our current set of board setup properties, only
solder_mask_min_width would join edge_clearance in a design_rules
section.
Most of the other properties are either most-recently-used values
(zone_clearance, via_size, etc.) or true DRC values (uvias_allowed,
trace_min, etc.).
The outlier is max_error, which is mostly a performance vs beauty
trade-off, but _does_ affect the generated board.
So,
1) leave solder_mask_min_width and edge_clearance in setup for now
2) create a design_rules section for solder_mask_min_width and
edge_clearance
3) leave edge_clearance in the project file for now
I think I’d vote for (1) simply because I don’t know how (2)
will
play with Jon’s stuff. But the only one I don’t like is (3).
Cheers,
Jeff.
On 4 Jul 2019, at 15:42, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
On 2019-07-04 09:24, Jeff Young wrote:
Since this is DRC, can we keep it in its current place until the DRC
manager goes in
Well, there’s DRC and there’s DR. The other options really
control
only what is *checked*, whereas this one controls stuff *on* the
board. Granted a lot of Jon’s rules will also fit into the DR
camp,
but I feel a little more reticent to move this one out.
Thoughts?
Jeff.
That's a valid point. Ideally, I'd like to see this in a
"DesignRules" section. Different manufacturers will have different
requirements here, so the DRC/DFM import would need to modify this
value. The check also needs to allow separate values for internal
vs.
external layers.
If we want to separate the generation from the checking, we might
want
to put this setting in the zone parameters. In which case, we might
use a global default setting that is used for new zones.
-Seth
