kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #41393
Re: Pcbnew file format
(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
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
Follow ups
References
-
Pcbnew file format
From: Jeff Young, 2019-07-02
-
Re: Pcbnew file format
From: jp charras, 2019-07-02
-
Re: Pcbnew file format
From: Wayne Stambaugh, 2019-07-02
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-03
-
Re: Pcbnew file format
From: Seth Hillbrand, 2019-07-03
-
Re: Pcbnew file format
From: Wayne Stambaugh, 2019-07-03
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-03
-
Re: Pcbnew file format
From: Seth Hillbrand, 2019-07-03
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-03
-
Re: Pcbnew file format
From: Seth Hillbrand, 2019-07-03
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-03
-
Re: Pcbnew file format
From: Seth Hillbrand, 2019-07-03
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-04
-
Re: Pcbnew file format
From: Seth Hillbrand, 2019-07-04
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-04
-
Re: Pcbnew file format
From: Seth Hillbrand, 2019-07-04
-
Re: Pcbnew file format
From: Jeff Young, 2019-07-04
-
Re: Pcbnew file format
From: hauptmech, 2019-07-05