X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <53BD6981.3050302@sonic.net> Date: Wed, 09 Jul 2014 09:10:41 -0700 From: Dave Curtis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] pour clearing around pads References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010005000807070104020403" X-Sonic-ID: C;enrQkoMH5BG2L02zUc16mQ== M;PtoGk4MH5BG2L02zUc16mQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Reply-To: geda-user AT delorie DOT com 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 > > (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 >> >> (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
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 =C2=A0going 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.=C2=A0 Geometry= * layer-flags.

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).


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...)

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.=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.
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.=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.

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+Fo= rmats
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

-dave
---

(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.=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.

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

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:

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.=C2=A0= I simply don't know the code well enough.

-dave


Peter


---

(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.=C2=A0 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.=C2=A0 djopt, I think, does this - intersecti= on of segments
is a different test than the "happen to touch due to width" test.


--------------010005000807070104020403--