Mail Archives: geda-user/2014/07/09/12:11:57
This is a multi-part message in MIME format.
--------------010005000807070104020403
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 07/09/2014 05:50 AM, Peter Clifton wrote:
> Apologies for my phone related top posting.
>
> I've been poking at pcb's internals for a long time now, and suspect I
> could (given time) fill in the geometry / rendering / connectivity
> parts of any file format extension.
Ohh... a vict^h^h^h^h volunteer...
> I just don't have a lot of time to drive the whole thing from design,
> documentation, discussion, testing etc..
>
> Implementing editing support is often the hardest part of enabling a
> new feature. (Think gschem's paths - I never did finish support for
> creating those within gschem, only moving existing control points.)
>
> I think any layer objects embeded in footprints (might as well include
> silk and copper in the same way going forward), ought to reference
> predefined symbolic layer name or ID.
>
> "TOP-SILK" "TOP-MASK" "TOP-COPPER" "INNER-COPPER" "INNER-ANTI-COPPER"*
> "BOTTOM-COPPER" etc...
>
> *(inner anticopper might need some thought, possibly not one for today!).
Seems like you are thinking along the same lines I am. Geometry *
layer-flags.
>
> These would no doubt be interpreted relative to the placement side.
> Names, and rules for these would need defining. Ideally, think how
> this applies to complex constructions like flex rigid and buried
> components. (If it is easy to design so we support / avoid breaking
> such flows, we should).
>
>
> I'd be tempted to make pads layer objects going forward, (and let them
> reside on any copper layer), but perhaps for now, keeping them
> "special" and outside the normal layer data structure may be cleaner
> due to the fact they place objects on multiple "layers". (Copper,
> mask, paste etc...)
>
> If there is need to define geometric areas (keepouts etc.), this
> should ideally be done with a primitive polycurve definition, not a
> collection of other objects. IDF supports line and circular arc
> segments for this, and I've been working on support for similar within
> PCBs polygons. You might need to consider how multiple outlines are
> handled.
>
Some kind of polycurve geometry would be very flexible. I have no idea
how difficult that would be to handle in the internal data structures,
what impact that has on performance, how much that complicates
rotations, etc. etc.
> I've been tempted to suggest a polycurve representation for pads too.
> Might want to indirect through a pad and/or padstack definition to
> avoid huge amounts of data repetition, and to allow the exporters to
> more easily group features into unique apertures etc.
I'll work up a few ideas and write them up to kick things off. First
off, I want to collect a laundry list of "cranky footprint problems" so
that I have something to validate the spec against. I have a couple of
my own poster-child footprints for that, but my PCB designs never get
extremely complicated and I don't target automated assembly, so there
are a lot of issues I'm not aware of.
>
> If you have a link to hand, send me a pointer to the KiCAD footprint
> format reference please.
>
This page:
http://www.kicad-pcb.org/display/KICAD/File+Formats
has a link to a pdf document. Note that KiCad is moving to a new
format. The old format has a single monolithic text file that contains
all footprints -- I haven't looked at that format at all, but I assume
it has been found to be insufficiently flexible. The new format is
based on S-expressions. Seems flexible, but I think they leave things
out (like keep-outs) or perhaps I'm not seeing how to use what is
there. Could be a case of creeping elegance, or maybe they have the
right idea. I haven't studied it enough to say.
-dave
> ---
> Peter Clifton <Peter DOT Clifton AT clifton-electronics DOT co DOT uk >
>
> (Sent from my phone)
>
> -------- Original message --------
> From: Dave Curtis
> Date:09/07/2014 07:09 (GMT+00:00)
> To: geda-user AT delorie DOT com
> Subject: Re: [geda-user] pour clearing around pads
>
> On 07/08/2014 11:17 AM, Peter Clifton wrote:
>> Please don't use zero width pads...
> OK :)
>>
>> The file format makes no guarantee how they behave, and it seems like
>> the special case free situation should view them as an under width
>> DRC error.
> Yes, its a total belly-flop onto "maybe it happens to work."
>>
>> Adding support for defining additional mask within a footprint should
>> not be insurmountable, just needs in the first instance, someone to
>> define the extension to the file format.
> Extending the file format is the easy part. I can come up with lots
> of ideas for syntax. And I could have a patch for the flex .l-file in
> minutes and recognize the the constructs in the bison code quite
> quickly as well. It's getting past that point is where we smack into
> a wall -- it's not clear to me that the internal data structures are
> ready to accept copper-clearance and mask-clearance features that are
> not associated with a pad or a pin.
>
> A friend across town has been using KiCad for a while, and since we
> are interested in building the same sorts of things we try to share
> what we can in terms of tools and designs. Right now, we are hot on
> the "grand, unified, footprint generator script" problem. We would
> like to come up with a single front-end that can create footprints for
> both pcb and KiCad so that we could share footprints more easily.
> So... I've been looking at the KiCad footprint file format and their
> new one can handle a lot of things that are somewhat vexing in pcb --
> although I'm not too hot on the S-expression idea overall. Anyway,
> KiCad seems to leave some things out that my friend and I have been
> talking about -- like keep-outs.
>
> So the point of the above paragraph is, yes, I can suggest some
> extensions, and now would be a good time to capture that since I am
> trying to wrap my head around the issues right now. What I can do:
>
> 1. write up some straw-man spec extensions
> 2. update the "footprint creation for.." document with what ever
> settles out of that.
>
> What I can not do:
>
> Investigate the feasibility of implementing the extensions. I simply
> don't know the code well enough.
>
> -dave
>
>>
>> Peter
>>
>>
>> ---
>> Peter Clifton <Peter DOT Clifton AT clifton-electronics DOT co DOT uk >
>>
>> (Sent from my phone)
>>
>> -------- Original message --------
>> From: DJ Delorie
>> Date:07/07/2014 19:00 (GMT+00:00)
>> To: geda-user AT delorie DOT com
>> Subject: Re: [geda-user] pour clearing around pads
>>
>>
>> > I'm not sure where to look for how a zero-thickness pad might cause
>> > phantom shorts or how it interacts with route blocking. Clues welcome.
>>
>> The code considers a pad to be a line segment between two points, and
>> may do a "do these segments intersect" test independent of the "check
>> the width" test. djopt, I think, does this - intersection of segments
>> is a different test than the "happen to touch due to width" test.
>
--------------010005000807070104020403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by c.mail.sonic.net id s69GAfIO020126
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 07/09/2014 05:50 AM, Peter Clifton
wrote:<br>
</div>
<blockquote
cite=3D"mid:jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT co=
m"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DU=
TF-8">
<div>Apologies for my phone related top posting.</div>
<div><br>
</div>
<div>I've been poking at pcb's internals for a long time now, and
suspect I could (given time) fill in the geometry / rendering /
connectivity parts of any file format extension.</div>
</blockquote>
Ohh... a vict^h^h^h^h volunteer...<br>
<blockquote
cite=3D"mid:jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT co=
m"
type=3D"cite">
<div> I just don't have a lot of time to drive the whole thing
from design, documentation, discussion, testing etc..</div>
<div><br>
</div>
<div>Implementing editing support is often the hardest part of
enabling a new feature. (Think gschem's paths - I never did
finish support for creating those within gschem, only moving
existing control points.)</div>
<div><br>
</div>
<div>I think any layer objects embeded in footprints (might as
well include silk and copper in the same way =C2=A0going forward)=
,
ought to reference predefined symbolic layer name or ID.</div>
<div><br>
</div>
<div>"TOP-SILK" "TOP-MASK" "TOP-COPPER" "INNER-COPPER"
"INNER-ANTI-COPPER"* "BOTTOM-COPPER" etc...</div>
<div><br>
</div>
<div>*(inner anticopper might need some thought, possibly not one
for today!).</div>
</blockquote>
Seems like you are thinking along the same lines I am.=C2=A0 Geometry=
*
layer-flags.<br>
<blockquote
cite=3D"mid:jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT co=
m"
type=3D"cite">
<div><br>
</div>
<div>These would no doubt be interpreted relative to the placement
side. Names, and rules for these would need defining. =C2=A0Ideal=
ly,
think how this applies to complex constructions like flex rigid
and buried components. (If it is easy to design so we support /
avoid breaking such flows, we should).</div>
<div><br>
</div>
<div><br>
</div>
<div>I'd be tempted to make pads layer objects going forward, (and
let them reside on any copper layer), but perhaps for now,
keeping them "special" and outside the normal layer data
structure =C2=A0may be cleaner due to the =C2=A0fact they place o=
bjects on
multiple "layers". (Copper, mask, paste etc...)</div>
<div><br>
</div>
<div>If there is need to define geometric areas (keepouts etc.),
this should ideally be done with a primitive polycurve
definition, not a collection of other objects. IDF supports line
and circular arc segments for this, and I've been working on
support for similar within PCBs polygons. You might need to
consider how multiple outlines are handled.</div>
<div><br>
</div>
</blockquote>
Some kind of polycurve geometry would be very flexible.=C2=A0 I have =
no
idea how difficult that would be to handle in the internal data
structures, what impact that has on performance,=C2=A0 how much that
complicates rotations, etc. etc.<br>
<blockquote
cite=3D"mid:jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT co=
m"
type=3D"cite">
<div>I've been tempted to suggest a polycurve representation for
pads too. Might want to indirect through a pad and/or padstack
definition to avoid huge amounts of data repetition, and to
allow the exporters to more easily group features into unique
apertures etc.</div>
</blockquote>
I'll work up a few ideas and write them up to kick things off.=C2=A0
First off, I want to collect a laundry list of "cranky footprint
problems" so that I have something to validate the spec against.=C2=A0=
I
have a couple of my own poster-child footprints for that, but my PCB
designs never get extremely complicated and I don't target automated
assembly, so there are a lot of issues I'm not aware of.<br>
<blockquote
cite=3D"mid:jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT co=
m"
type=3D"cite">
<div><br>
</div>
<div>If you have a link to hand, send me a pointer to the KiCAD
footprint format reference please.</div>
<div><br>
</div>
</blockquote>
This page: <br>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.kicad-pcb.org/d=
isplay/KICAD/File+Formats">http://www.kicad-pcb.org/display/KICAD/File+Fo=
rmats</a><br>
has a link to a pdf document.=C2=A0 Note that KiCad is moving to a ne=
w
format.=C2=A0 The old format has a single monolithic text file that
contains all footprints -- I haven't looked at that format at all,
but I assume it has been found to be insufficiently flexible.=C2=A0 T=
he
new format is based on S-expressions.=C2=A0 Seems flexible, but I thi=
nk
they leave things out (like keep-outs) or perhaps I'm not seeing how
to use what is there.=C2=A0 Could be a case of creeping elegance, or
maybe they have the right idea.=C2=A0 I haven't studied it enough to =
say.=C2=A0
<br>
<br>
-dave<br>
<blockquote
cite=3D"mid:jql5oeoex9l7r932tnwtp2i5 DOT 1404908642063 AT email DOT android DOT co=
m"
type=3D"cite">
<div>---</div>
<div>Peter Clifton <a class=3D"moz-txt-link-rfc2396E" href=3D"mailt=
o:Peter DOT Clifton AT clifton-electronics DOT co DOT uk"><Peter DOT Clifton AT clifton-elec=
tronics.co.uk
></a></div>
<div><br>
</div>
(Sent from my phone)<br>
<br>
-------- Original message --------<br>
From: Dave Curtis <davecurtis AT sonic DOT net> <br>
Date:09/07/2014 07:09 (GMT+00:00) <br>
To: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:geda-use=
r AT delorie DOT com">geda-user AT delorie DOT com</a> <br>
Subject: Re: [geda-user] pour clearing around pads <br>
<br>
<div class=3D"moz-cite-prefix">On 07/08/2014 11:17 AM, Peter
Clifton wrote:<br>
</div>
<blockquote
cite=3D"mid:tdei7xok2jel0ik0d6j1r048 DOT 1404843436262 AT email DOT androi=
d.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3DUTF-8">
<div>Please don't use zero width pads...</div>
</blockquote>
OK :)<br>
<blockquote
cite=3D"mid:tdei7xok2jel0ik0d6j1r048 DOT 1404843436262 AT email DOT androi=
d.com"
type=3D"cite">
<div><br>
</div>
<div>The file format makes no guarantee how they behave, and
it seems like the special case free situation should view
them as an under width DRC error.</div>
</blockquote>
Yes, its a total belly-flop onto "maybe it happens to work."<br>
<blockquote
cite=3D"mid:tdei7xok2jel0ik0d6j1r048 DOT 1404843436262 AT email DOT androi=
d.com"
type=3D"cite">
<div><br>
</div>
<div>Adding support for defining additional mask within a
footprint should not be insurmountable, just needs in the
first instance, someone to define the extension to the file
format.</div>
</blockquote>
Extending the file format is the easy part.=C2=A0 I can come up w=
ith
lots of ideas for syntax. And I could have a patch for the flex
.l-file in minutes and recognize the the constructs in the bison
code quite quickly as well.=C2=A0 It's getting past that point is
where we smack into a wall -- it's not clear to me that the
internal data structures are ready to accept copper-clearance
and mask-clearance features that are not associated with a pad
or a pin. <br>
<br>
A friend across town has been using KiCad for a while, and since
we are interested in building the same sorts of things we try to
share what we can in terms of tools and designs.=C2=A0 Right now,=
we
are hot on the "grand, unified, footprint generator script"
problem.=C2=A0=C2=A0 We would like to come up with a single front=
-end that
can create footprints for both pcb and KiCad so that we could
share footprints more easily.=C2=A0 So... I've been looking at th=
e
KiCad footprint file format and their new one can handle a lot
of things that are somewhat vexing in pcb -- although I'm not
too hot on the S-expression idea overall.=C2=A0 Anyway, KiCad see=
ms
to leave some things out that my friend and I have been talking
about -- like keep-outs.=C2=A0 <br>
<br>
So the point of the above paragraph is, yes, I can suggest some
extensions, and now would be a good time to capture that since I
am trying to wrap my head around the issues right now.=C2=A0 What=
I
can do:<br>
<br>
1. write up some straw-man spec extensions<br>
2. update the "footprint creation for.." document with what ever
settles out of that.<br>
<br>
What I can not do:<br>
<br>
Investigate the feasibility of implementing the extensions.=C2=A0=
I
simply don't know the code well enough.<br>
<br>
-dave<br>
<br>
<blockquote
cite=3D"mid:tdei7xok2jel0ik0d6j1r048 DOT 1404843436262 AT email DOT androi=
d.com"
type=3D"cite">
<div><br>
</div>
<div>Peter</div>
<div><br>
</div>
<div><br>
</div>
<div>---</div>
<div>Peter Clifton <a moz-do-not-send=3D"true"
class=3D"moz-txt-link-rfc2396E"
href=3D"mailto:Peter DOT Clifton AT clifton-electronics DOT co DOT uk"><=
;Peter DOT Clifton AT clifton-electronics DOT co DOT uk
></a></div>
<div><br>
</div>
(Sent from my phone)<br>
<br>
-------- Original message --------<br>
From: DJ Delorie <dj AT delorie DOT com> <br>
Date:07/07/2014 19:00 (GMT+00:00) <br>
To: <a moz-do-not-send=3D"true"
class=3D"moz-txt-link-abbreviated"
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com=
</a>
<br>
Subject: Re: [geda-user] pour clearing around pads <br>
<br>
<br>
> I'm not sure where to look for how a zero-thickness pad
might cause <br>
> phantom shorts or how it interacts with route
blocking.=C2=A0 Clues welcome.<br>
<br>
The code considers a pad to be a line segment between two
points, and<br>
may do a "do these segments intersect" test independent of
the "check<br>
the width" test.=C2=A0 djopt, I think, does this - intersecti=
on
of segments<br>
is a different test than the "happen to touch due to width"
test.<br>
</dj AT delorie DOT com></blockquote>
<br>
</davecurtis AT sonic DOT net></blockquote>
<br>
</body>
</html>
--------------010005000807070104020403--
- Raw text -