Re: gEDA-user: PCB format wishlist
I don't think the copper shape / masking / clearance of the via is necessarily primitive. Granted, in 99.9% of cases it can be described by circular copper geometry on each connected layer, but support for arbitrary pad-stacks for components might as well extend to arbitrary via geometry. I'm pretty sure most holes in PCBs are round, but then some connectors have rectangular cut-outs (probably routed), but possibly stamped / reamed out. A few years ago, I worked at a company that made flexible PCBs on Polyamide (two external copper layers on a thin plastic). This process was performed by taking 1000+ ft rolls and advancing it through a mechanical press/die that would create all of the vias at once (for a single artwork image). While round pins were preferred, you could switch to any geometry you wanted. When you consider the possibilities of laser drilled vias, any geometry IS possible (although not necessarily practical). Andy Miner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, 6 Sep 2010 16:32:10 -0400 DJ Delorie d...@delorie.com wrote: Arcs can be simulated with many short lines, so the only primitive we need are lines. Of course, if line is a two-point polygon, then the only primitive we need is polygons. So, your pcb file would contain nothing but polygons. This would make it unparsable with external scripts and humans. A point is just a line that starts and ends at the same coordinates. I don't like this. -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 8:31 PM, Rick Collins wrote: I have often thought that I would prefer to write an HDL that works like Forth. I believe Chuck Moore (the inventor of Forth) beat you to it. http://www.colorforth.com/vlsi.html John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
I think (hope) DJ was being sarcastic I was. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/05/2010 10:21 AM, Bert Timmerman wrote:
On 09/04/2010 10:19 PM, Andrew Poelstra wrote:
I have one more suggestion: the facility to create recursive PCBs.
Recursive PCBs could work the same way as the footprint
re-use: a node could contain a reference to a parent node;
the parent node could be a single element or itself a
reference to a collection of elements.
+1
I can think of a group of {traces, vias, elements, silk text or lines} to
be linked in from an external file or to be embedded.
The analogy of embedded/unembedded symbols in gschem comes to mind.
Me too.
And what if the gschem, pcb file formats were somehow unified. Might allow
easier searching through project data. Might enable cell-based design like
larger circuits, (chips), are done...
John G
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
First grow up, you are the one crying And here is the solution for making the version control with git understand a zipped pcb file. http://the-gay-bar.com/2010/06/23/managing-zip-based-file-formats-in-git/ In summary you tell git that to diff the file it needs to me unzipped first. Steve Woah... I intended this thread for *what* we want to put in the file format to allow one to easily assign relationships between and characteristics of elements. I was trying to shift the focus away from awk, ruby, other program's file formats. I re-submit my original list: 1) Better angle support: include rotation (in degrees, rotation/translation matrix, whatever) as a location argument instead of altering the pad/pin/silk/refdes/whatever location data separately 2) Footprint re-use: reduce file size by having components refer to a 'base' component with XYRS information, make component tweaking easier. Say you wanted to change all your 0603 resistors - it's easier to change the fundamental component, rather than the present case of to modifying individual components in all of their rotations. 3) Connectivity information: include the connection information between line segments, similar to (but not necessarily exactly!) SVG format, where multiple points and arcs can be included in one line. 4) DRC re-use: refer to a 'base' DRC rule, rather than re-describing the DRC at every instance. DRC rules could be arbitrarily complex or simple, e.g. elements in DRC class '250V' must have a 0.050 clearance from class '5V', but can have 0.010 clearance within '250V', or something along the lines of the 'skinny, normal, fat, power' we have in place now. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 5, 2010, at 12:55 PM, Andrew Poelstra wrote: It's because it's inflexible and unintuitive. The gEDA schematic format is flexible, intuitive, easy to parse, easy to generate, and well described by concise documentation. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 5, 2010, at 1:56 PM, kai-martin knaak wrote: Stefan Salewski wrote: One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. More precisely: Positional parameters are bad. Mapping position to meaning makes it hard to add additional parameters anywhere but at the end. Structured data does not easily fit easily. It is next to impossible to throw meaningful errors if values are in the wrong order. Instead, the error likely goes unnoticed on read and can produce havoc at unsuspected places further down the flow. So gschem and gnetlist must obviously be constantly failing, suffer from horrible inflexibility, and users must live in a fog of file format driven error. Except they don't. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 5, 2010, at 7:10 PM, DJ Delorie wrote:
We are NOT going with another position-determines-meaning file format.
Why?
Consider the parser for the PIN object:
Pin [rX rY Thickness Clearance Mask Drill Name Number SFlags]
Pin (rX rY Thickness Clearance Mask Drill Name Number NFlags)
Pin (aX aY Thickness Drill Name Number NFlags)
Pin (aX aY Thickness Drill Name NFlags)
Pin (aX aY Thickness Name NFlags)
The parser only sees the syntax, not the semantics:
pin_hi_format
: T_PIN '[' NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER STRING
STRING flags ']'
pin_1.7_format
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER STRING STRING NUMBER ')'
pin_1.6.3_format
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER STRING NUMBER ')'
pin_newformat
: T_PIN '(' NUMBER NUMBER NUMBER STRING NUMBER ')'
pin_oldformat
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER STRING
STRING NUMBER ')'
What happens if I want to add another parameter?
Design the primitives right from the beginning and you won't have to. The real
problem is that pin is obviously not a primitive concept here.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
So gschem and gnetlist must obviously be constantly failing, suffer from horrible inflexibility, and users must live in a fog of file format driven error. Except they don't. The REAL problem with opensource and contributors like you, is that they're completely incapable of accepting any [even constructive] criticism and will threaten with killfiling your email address just for pointing this out. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 8:56 AM, timecop wrote: So gschem and gnetlist must obviously be constantly failing, suffer from horrible inflexibility, and users must live in a fog of file format driven error. Except they don't. The REAL problem with opensource and contributors like you, is that they're completely incapable of accepting any [even constructive] criticism and will threaten with killfiling your email address just for pointing this out. Nah, DJ and I get along better than you think. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 5, 2010, at 10:43 AM, Stephan Boettcher wrote:
Yes, the gschem file format is much less accessible for
hand/awk/sed-editing than the pcb file format.
Huh? gschem format is *trivial* to parse in awk. Use rules like:
$1==L {
x1 = $2
y1 = $3
...
Or for simple things just skip the symbolic names. XML is much harder.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 8:22 AM, Ethan Swint wrote: Woah... I intended this thread for *what* we want to put in the file format to allow one to easily assign relationships between and characteristics of elements. The reason you can't is that pcb and its file format aren't well factored. You cannot compose complex data and behaviors from simpler data and behaviors. So any new thing will necessarily be a kludge that solves a single complaint rather than a tool to extend pcb's capabilities. But maybe, in the discussion of file formats, we can come up with a way to describe a printed circuit board in a clean, well-factored way. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 09:32:44AM -0600, John Doty wrote: But maybe, in the discussion of file formats, we can come up with a way to describe a printed circuit board in a clean, well-factored way. Well, what primitives would we need? The ones I can think of are trace, polygon, net and drc class. I'm not even sure that 'trace' and 'polygon' need be distinct. (Though, by adding a bend parameter to a trace, we can obtain arcs - something that would look pretty kludgy on a polygon.) Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
John Doty j...@noqsi.com writes:
On Sep 5, 2010, at 10:43 AM, Stephan Boettcher wrote:
Yes, the gschem file format is much less accessible for
hand/awk/sed-editing than the pcb file format.
Huh? gschem format is *trivial* to parse in awk. Use rules like:
$1==L {
x1 = $2
y1 = $3
...
But the meat is in the following lines, those things I'd want to mangle.
Or for simple things just skip the symbolic names. XML is much harder.
Oh yes, XML is horrible.
--
Stephan Böttcher FAX: +49-431-880-3968
Extraterrestrische PhysikTel: +49-431-880-2508
I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de
Leibnizstr. 11, 24118 Kiel, Germany
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 08:46:03AM -0700, Andrew Poelstra wrote: Well, what primitives would we need? The ones I can think of are trace, polygon, net and drc class. Oh, and via. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 9:46 AM, Andrew Poelstra wrote: On Mon, Sep 06, 2010 at 09:32:44AM -0600, John Doty wrote: But maybe, in the discussion of file formats, we can come up with a way to describe a printed circuit board in a clean, well-factored way. Well, what primitives would we need? The ones I can think of are trace, polygon, net and drc class. Need some geometric shapes. Need to be able to attach material properties to them (including vacuum for holes). Net and properties for DRC are definitely not primitive. I'm not even sure that 'trace' and 'polygon' need be distinct. (Though, by adding a bend parameter to a trace, we can obtain arcs - something that would look pretty kludgy on a polygon.) Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
I'd add a capability of storing net information along with lines, polygons, vias, and other copper objects. It would then make it unnecessary to have the new lines arcs clear polygons stuff. A line in a polygon with the same net wouldn't clear. Levente -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sat, 4 Sep 2010 22:10:17 -0700 Steven Michalske smichal...@gmail.com wrote: Any other thoughts? Pick and place points? -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 9:59 AM, Kovacs Levente wrote: I'd add a capability of storing net information along with lines, polygons, vias, and other copper objects. It would then make it unnecessary to have the new lines arcs clear polygons stuff. A line in a polygon with the same net wouldn't clear. It makes sense either to compose a net from conductive geometric shapes, or tag conductive geometric shapes that belong to a net (some may not!) with a name identifying the net. But net is not a primitive concept in either case. Levente -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 10:00 AM, Kovacs Levente wrote: Pick and place points? Not primitive. Composed of a geometric object tagged to identify it as a pick and place point. We should, of course, allow arbitrary attributes to be attached to any object to allow for things like this (and much more). But we should not put things like this in the basic file format. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 9:48 AM, Stephan Boettcher wrote:
John Doty j...@noqsi.com writes:
On Sep 5, 2010, at 10:43 AM, Stephan Boettcher wrote:
Yes, the gschem file format is much less accessible for
hand/awk/sed-editing than the pcb file format.
Huh? gschem format is *trivial* to parse in awk. Use rules like:
$1==L {
x1 = $2
y1 = $3
...
But the meat is in the following lines, those things I'd want to mangle.
Well, either grab the interesting lines directly, make your rules stateful (set
a flag when you are processing an interesting component, for example), or put
the parsed data into an associative array that you then process with your END
rule. It doesn't seem hard to me, anyway.
Or for simple things just skip the symbolic names. XML is much harder.
Oh yes, XML is horrible.
--
Stephan Böttcher FAX: +49-431-880-3968
Extraterrestrische PhysikTel: +49-431-880-2508
I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de
Leibnizstr. 11, 24118 Kiel, Germany
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 9/6/10 10:56 AM, timecop wrote: So gschem and gnetlist must obviously be constantly failing, suffer from horrible inflexibility, and users must live in a fog of file format driven error. Except they don't. The REAL problem with opensource and contributors like you, is that they're completely incapable of accepting any [even constructive] criticism and will threaten with killfiling your email address just for pointing this out. If you find yourself getting kill-filed a lot, which I suspect you do, I respectfully submit that the problem lies elsewhere. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 11:24:58AM -0600, John Doty wrote: Choosing the right level for the primitives is important. I wouldn't drop below a planar stack of geometric shapes here. But I wouldn't go higher for primitives either. One might very well wish to draw arbitrary shapes in silk, or one might require holes of arbitrary shape. I once worked with a board that had different numbers of layers in different places, and with different conductive materials for different traces (not designed with pcb!). A well-factored design should be able to express this kind of thing. A format that would be equally at home specifying the layout of a printed circuit board, a VLSI chip, or a Mondrian painting would be a good target. I don't think we need to go as far as spherical circuits or Picasso ;-). Sounds good. But I'm worried that by dropping down to basically a vector drawing, we're going too far. However, given that any decent file format will let us create PCB objects from geometric shapes, perhaps this is an unjustified fear. ... It's often necessary to align shapes on different layers: that's not a special property of vias. So, the machinery of composition of objects from more primitive objects needs to be able to control that. Then it would make sense to use that machinery to compose vias. The reason we can't have blind and buried vias is a consequence of the lack of such factored, orthogonal design in pcb at present. This is a very good point. I agree with it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 10:54 AM, Andrew Poelstra wrote: Sounds good. But I'm worried that by dropping down to basically a vector drawing, we're going too far. However, given that any decent file format will let us create PCB objects from geometric shapes, perhaps this is an unjustified fear. Might look at Inkscape for some inspiration in that department if you're really not afraid. It's excellent open source software for vector drawing. Very good UI. XML-based open file format. Does arcs, layers, lines, groups, polygons, etc. No DRC, though. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/06/2010 11:59 AM, Kovacs Levente wrote: I'd add a capability of storing net information along with lines, polygons, vias, and other copper objects. It would then make it unnecessary to have the new lines arcs clear polygons stuff. A line in a polygon with the same net wouldn't clear. Levente Hmm... this could be incorporated into 4) DRC re-use: refer to a 'base' DRC rule, rather than re-describing the DRC at every instance. DRC rules could be arbitrarily complex or simple, e.g. elements in DRC class '250V' must have a 0.050 clearance from class '5V', but can have 0.010 clearance within '250V', or something along the lines of the 'skinny, normal, fat, power' we have in place now. A 'net' could be specified by a class/group of elements within which the DRC clearance would be 0 and probably the minimum intersection between two elements would be enforced as the minimum width for that group. If elements are tagged with a net ID, including polygons, then that would still take care of the 'new lines arcs clear'. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 11:54 AM, Andrew Poelstra wrote: But I'm worried that by dropping down to basically a vector drawing, we're going too far. The difference isn't so much in the primitives, but the machinery of composition of those into higher level things. Consider gschem. At the GUI level it's basically a vector drawing program. But with some simple mechanisms to compose drawings of drawings (symbols, sources, etc) and establish relations between objects both locally (attachment) and globally (netname), it becomes a schematic capture program. An ordinary vector drawing program cannot do that job. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
John Doty wrote: The gEDA schematic format is flexible, intuitive, easy to parse, easy to generate, and well described by concise documentation. Not true, on all accounts. It relies on positional parameters. Nuff said. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 12:16:21PM -0600, John Doty wrote: On Sep 6, 2010, at 11:54 AM, Andrew Poelstra wrote: But I'm worried that by dropping down to basically a vector drawing, we're going too far. The difference isn't so much in the primitives, but the machinery of composition of those into higher level things. Consider gschem. At the GUI level it's basically a vector drawing program. But with some simple mechanisms to compose drawings of drawings (symbols, sources, etc) and establish relations between objects both locally (attachment) and globally (netname), it becomes a schematic capture program. An ordinary vector drawing program cannot do that job. Okay, I see what you're saying. So here's a new primitive list: 1. Line 2. Polygon 3. Arc Perhaps 1. and 2. should be merged (after all, a line is basically a polygon with only 2 points), but there are might be logistical problems with that. Or, could we base everything off of lines, attach a 'curvature' property to create arcs, and build polygons from that. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, 6 Sep 2010 12:57:59 -0700 Andrew Poelstra as...@sfu.ca wrote: Or, could we base everything off of lines, attach a 'curvature' property to create arcs, and build polygons from that. I woldn't do that. The file would end up consisting of the same stuff. It's like you could only have points. I think we should define primitives as the most commonly used shapes in pcb layouts. I prefer line, polygon, circle, arc. Why arc and circle are not merged? Because the diameter of the arc is the center of the bent line; however, the diameter of a circle is the edge. And of course we have to implement padstacks at the footprint level. Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Or, could we base everything off of lines, attach a 'curvature' property to create arcs, and build polygons from that. Arcs can be simulated with many short lines, so the only primitive we need are lines. Of course, if line is a two-point polygon, then the only primitive we need is polygons. A point is just a line that starts and ends at the same coordinates. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Why arc and circle are not merged? Because the diameter of the arc is the center of the bent line; however, the diameter of a circle is the edge. I.e. you're listing a *stroked* arc vs a *filled* circle? I like the idea of using geometric shapes at the lowest level, but for most PCBs this is *way* too low-level to be efficient. We need some way of arbitrarily grouping shapes, grouping groups, etc, and creating some sort of macro/library/callout for those groups, so that we don't end up (for example) redefining a pad stack for every one of hundreds of pins. If our PCB file format had the concept of a grouping function that could define named macros that took named parameters, with some simple math and control logic, we could then use those macros to define new primitives. So a function that defined a standard pad stack for a pin could be later called with a few simple parameters for each needed pin. This same grouping function becomes our element library :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 2:27 PM, Levente Kovacs wrote: And of course we have to implement padstacks at the footprint level. Why have any distinction between footprint and other fragments of layout (like hierarchical blocks)? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 2:40 PM, DJ Delorie wrote: Why arc and circle are not merged? Because the diameter of the arc is the center of the bent line; however, the diameter of a circle is the edge. I.e. you're listing a *stroked* arc vs a *filled* circle? I like the idea of using geometric shapes at the lowest level, but for most PCBs this is *way* too low-level to be efficient. We need some way of arbitrarily grouping shapes, grouping groups, etc, and creating some sort of macro/library/callout for those groups, so that we don't end up (for example) redefining a pad stack for every one of hundreds of pins. If our PCB file format had the concept of a grouping function that could define named macros that took named parameters, with some simple math and control logic, we could then use those macros to define new primitives. So a function that defined a standard pad stack for a pin could be later called with a few simple parameters for each needed pin. This same grouping function becomes our element library :-) Yes. Build higher-level objects by composition, not merely by listing. Higher-level objects are certainly important and meaningful to the designer. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Why have any distinction between footprint and other fragments of layout (like hierarchical blocks)? Because PCB needs to deal with boards at the semantic level, not just the physical level. Padstacks have to exist at the element level so they can be tied to the netlist, for example. A padstack elsewhere has to be managed differently. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 04:40:47PM -0400, DJ Delorie wrote: I like the idea of using geometric shapes at the lowest level, but for most PCBs this is *way* too low-level to be efficient. We need some way of arbitrarily grouping shapes, grouping groups, etc, and creating some sort of macro/library/callout for those groups, so that we don't end up (for example) redefining a pad stack for every one of hundreds of pins. If our PCB file format had the concept of a grouping function that could define named macros that took named parameters, with some simple math and control logic, we could then use those macros to define new primitives. So a function that defined a standard pad stack for a pin could be later called with a few simple parameters for each needed pin. This same grouping function becomes our element library :-) YAML has facilities for this: both creating user-defined types, and concatenating multiple documents so that we can preface every .pcb file with a global types file. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Yes. Build higher-level objects by composition, not merely by listing. I was arguing for the opposite - separate the compositing from the grouping, so that when you *do* group, you mostly just list. Even internally to PCB, I'd want to keep exemplar composites as a library called by reference, so if you edit one pin of an IC, by default you end up editing all the same-shape pins (usually what you want when you're changing drill or annulus, for example) with the option to make the pin unique so you can change it separately. This is the way sketchup works, and it's very usable that way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 2:49 PM, DJ Delorie wrote: Why have any distinction between footprint and other fragments of layout (like hierarchical blocks)? Because PCB needs to deal with boards at the semantic level, not just the physical level. Yes. As gschem has to deal with schematics at the semantic level. Yet it manages with little semantic information in its primitives (and could manage with even less). Padstacks have to exist at the element level so they can be tied to the netlist, for example. A padstack elsewhere has to be managed differently. But conductors in hierarchical blocks need to be tied to the netlist also. Connections and other relationships between primitives are the responsibility of the composition machinery. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 6, 2010, at 2:54 PM, DJ Delorie wrote: Yes. Build higher-level objects by composition, not merely by listing. I was arguing for the opposite - separate the compositing from the grouping, so that when you *do* group, you mostly just list. Even internally to PCB, I'd want to keep exemplar composites as a library called by reference, so if you edit one pin of an IC, by default you end up editing all the same-shape pins (usually what you want when you're changing drill or annulus, for example) with the option to make the pin unique so you can change it separately. This is the way sketchup works, and it's very usable that way. I believe we mean the same thing, but are failing to understand each other's language. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 04:49:32PM -0400, DJ Delorie wrote: Why have any distinction between footprint and other fragments of layout (like hierarchical blocks)? Because PCB needs to deal with boards at the semantic level, not just the physical level. Padstacks have to exist at the element level so they can be tied to the netlist, for example. A padstack elsewhere has to be managed differently. We can store mappings in the file, though. Suppose I've got a footprint containing one element, U?, with 4 pads, P1 P2 P3 and P4. If I then bring the footprint into a pcb layout, the file would look like: element: U5 mapping: # Refdes map U?: U5 # Pad map P1: U5-P1 P2: U5-P2 P3: U5-P3 P4: U5-P4 # Layer map silk: silk component: layer1 data: # Actual data, or import directive, or whatever In actuality, if we had element groups, and allowed pins to be addressed through their group (U5-P1, U5-P2, etc), there would be no need to map the pads explicitly. I think that pad should be a primitive type, which is just a textual identifier. It could then be attached to geometric shapes, be a member of a group, and be referenced in netlists. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/06/2010 04:27 PM, Levente Kovacs wrote: On Mon, 6 Sep 2010 12:57:59 -0700 Andrew Poelstraas...@sfu.ca wrote: Or, could we base everything off of lines, attach a 'curvature' property to create arcs, and build polygons from that. I woldn't do that. The file would end up consisting of the same stuff. It's like you could only have points. I think we should define primitives as the most commonly used shapes in pcb layouts. I prefer line, polygon, circle, arc. Why arc and circle are not merged? Because the diameter of the arc is the center of the bent line; however, the diameter of a circle is the edge. And of course we have to implement padstacks at the footprint level. What do you consider the 'footprint' level? If the 'footprint' is defined the base object of a group of arbitrary elements, then the ability to define footprints with arcs, pad stacks, etc. comes quite naturally, as a combination of #2 and #5 of the original list of qualities I proposed: 2) Footprint re-use: reduce file size by having components refer to a 'base' component with XYRS information, make component tweaking easier. Say you wanted to change all your 0603 resistors - it's easier to change the fundamental component, rather than the present case of to modifying individual components in all of their rotations. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/06/2010 04:54 PM, DJ Delorie wrote: Yes. Build higher-level objects by composition, not merely by listing. I was arguing for the opposite - separate the compositing from the grouping, so that when you *do* group, you mostly just list. Even internally to PCB, I'd want to keep exemplar composites as a library called by reference, so if you edit one pin of an IC, by default you end up editing all the same-shape pins (usually what you want when you're changing drill or annulus, for example) with the option to make the pin unique so you can change it separately. Yes - but I'd also like to be prompted to answer the question 'Do you want this change to 1) apply to all instances of object X; 2) do you want to modify this one instance of object X to derive object Y with some inherited characteristics; or 3) do you want to make an independent object Z which starts out with parameters identical to X?' ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/06/2010 04:32 PM, DJ Delorie wrote: Or, could we base everything off of lines, attach a 'curvature' property to create arcs, and build polygons from that. Arcs can be simulated with many short lines, so the only primitive we need are lines. Of course, if line is a two-point polygon, then the only primitive we need is polygons. I don't really like the idea of 'simulating' arcs - it uses a *lot* of information to approximate what you are trying to do. My preference would be to keep an arc as a primitive type. A point is just a line that starts and ends at the same coordinates. Not really - a line that starts and ends at the same coordinate looks like a point, but it isn't. That presently causes us problems with square pads. I think I remember some issues with approximations of a point using traces, too? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 6, 2010 at 10:47 AM, John Doty [1]...@noqsi.com wrote: On Sep 5, 2010, at 12:55 PM, Andrew Poelstra wrote: It's because it's inflexible and unintuitive. The gEDA schematic format is flexible, intuitive, easy to parse, easy to generate, and well described by concise documentation. It is also frequently completely irrelevant to PCB. I use DOS OrCAD 7 more often for my schematics that I feed PCB, that I use gEDA. Others use XCircuit etc. References 1. mailto:j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
I like the idea of using geometric shapes at the lowest level, but for most PCBs this is *way* too low-level to be efficient. We need some way of arbitrarily grouping shapes, grouping groups, etc, and creating some sort of macro/library/callout for those groups, so that we don't end up (for example) redefining a pad stack for every one of hundreds of pins. Several times now in this thread I keep thinking that the language Forth is being described. 'Words' built up on previously defined 'words'... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, 2010-09-06 at 10:05 -0700, Andrew Poelstra wrote: via Definitely not primitive. A hole in one or more layers with conductive material in it. Again, while geometrically a via is not primitive, I think that in PCB terms, a via is primitive. It can exist on several layers, which the other shapes do not, so it doesn't make sense to build it out of other shapes. I think the concept of a via (in spanning layers of a 2.5d geometry) is fairly primitive in the PCB world, but I partly agree with John regarding the definition of the geometry. I don't think the copper shape / masking / clearance of the via is necessarily primitive. Granted, in 99.9% of cases it can be described by circular copper geometry on each connected layer, but support for arbitrary pad-stacks for components might as well extend to arbitrary via geometry. I'm pretty sure most holes in PCBs are round, but then some connectors have rectangular cut-outs (probably routed), but possibly stamped / reamed out. /me wonders how long it is before some crafty PCB manufacturers start producing off-axis, slant-drilled vias ;) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 06, 2010 at 10:27:25PM +0200, Levente Kovacs wrote: I prefer line, polygon, circle, arc. Why arc and circle are not merged? Because the diameter of the arc is the center of the bent line; however, the diameter of a circle is the edge. I don't understand this. If we generalize circles to ellipses, they can be described by a center point, and major/minor axis lengths. For an arc, add a sweep attribute and set it to 90 degrees. And of course we have to implement padstacks at the footprint level. I also don't see why footprints and PCBs need to be distinct. Anything should be able to be designated as a pad, regardless of whether it is part of a footprint, or group, or sub-PCB. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
At 07:49 PM 9/6/2010, you wrote: I like the idea of using geometric shapes at the lowest level, but for most PCBs this is *way* too low-level to be efficient. We need some way of arbitrarily grouping shapes, grouping groups, etc, and creating some sort of macro/library/callout for those groups, so that we don't end up (for example) redefining a pad stack for every one of hundreds of pins. Several times now in this thread I keep thinking that the language Forth is being described. 'Words' built up on previously defined 'words'... I have often thought that I would prefer to write an HDL that works like Forth. If used in this way, it becomes a bit Lisp like in that the data and program would need to become one and the same. The Forth that describes the design would be executed to create the design in memory or to be output as a set of Gerber files. But to do things like DRC, you would need to analyze either the image in memory or the design source itself as data. If I find some time, a lot of time, I may work on that at some point. But there are many other projects on the list ahead of that one. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Rick - On Mon, Sep 06, 2010 at 10:31:15PM -0400, Rick Collins wrote: Several times now in this thread I keep thinking that the language Forth is being described. 'Words' built up on previously defined 'words'... I have often thought that I would prefer to write an HDL that works like Forth. If used in this way, it becomes a bit Lisp like in that the data and program would need to become one and the same. The Forth that describes the design would be executed to create the design in memory or to be output as a set of Gerber files. But to do things like DRC, you would need to analyze either the image in memory or the design source itself as data. Ideas like this are cool, but take extra attention to their security implications. Is the file format capable of infinite loops? Are there primitives to read or write files? Hmm. It's not impossible to get right. There's an old security saying; my Google-fu failed me, but it goes something like: Users are receptive to all sorts of ideas of what computers should do, and vendors are all too ready to make them happen. By the time a security expert exclaims are you nuts?, it's too late. - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/04/2010 10:04 PM, Andrew Poelstra wrote: 3) Connectivity information: include the connection information between line segments, similar to (but not necessarily exactly!) SVG format, where multiple points and arcs can be included in one line. I'm not sure what you're getting at here. I think the rule of least surprise dictates that line segments be line segments, since that is how they are manipulated. If you are familiar with mechanical CAD packages, they would be called 'polylines': connected line segments/arcs which otherwise have the same characteristics. I often find myself editing the PCB file in a text editor and it's a real pain to find connected traces, as they are scattered over the entire file. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. More generally, we should support creating groups of components that can be transformed and manipulated as a collection. However, I'm not sure how much functionality this would give on top of the functional-block proposal. This idea encompasses a component group: the XYRS data of each of these components would be locked to a 'base' component. When the base component is moved, all of the components are moved. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/04/2010 10:19 PM, Andrew Poelstra wrote: I have one more suggestion: the facility to create recursive PCBs. What this will look like in the file format, I dunno. But we should keep it in mind. Recursive PCBs could work the same way as the footprint re-use: a node could contain a reference to a parent node; the parent node could be a single element or itself a reference to a collection of elements. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Hi,
-Original Message-
From: geda-user-boun...@moria.seul.org
[mailto:geda-user-boun...@moria.seul.org] On Behalf Of Ethan Swint
Sent: Sunday, September 05, 2010 4:06 PM
To: gEDA user mailing list
Subject: Re: gEDA-user: PCB format wishlist
On 09/04/2010 10:19 PM, Andrew Poelstra wrote:
I have one more suggestion: the facility to create recursive PCBs.
What this will look like in the file format, I dunno. But we should
keep it in mind.
Recursive PCBs could work the same way as the footprint
re-use: a node could contain a reference to a parent node;
the parent node could be a single element or itself a
reference to a collection of elements.
+1
I can think of a group of {traces, vias, elements, silk text or lines} to
be linked in from an external file or to be embedded.
The analogy of embedded/unembedded symbols in gschem comes to mind.
I never have applied symbols recursively though (symbols within symbols
within symbols), other than in the form of hierarchical multisheet
schematics (symbols pointing to schematics containing symbols, pointing to
schematics containing symbols, etc.
Kind regards,
Bert Timmerman.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
All of this discussion of formats misses the shining example that's already in gEDA: the schematic format. Now *there's* a work of genius. 1. The format is based on a small, well-chosen set of elementary objects. 2. Elementary objects are represented by one-line tagged records of fixed format (identified by the tag). Almost any tool you might want to use can easily process a file of this sort without the need of any special library. 3. A set of objects can be attached to any abject. This can be in principle extended to unlimited depth. 4. Multi-line text objects are supported. There are few restrictions on the content of a text object. (1) and (2) make the format easy to process with simple tools. (3) and (4) constitute an infinitely flexible escape hatch, although we're not using it to its full capability (but a single level of attached attributes is pretty good). A good file format for this sort of thing avoids definitions for high level concepts. It provides mechanisms to compose high level objects from low level primitives. So, the question here starts with what are the primitives that one constructs printed circuit board descriptions from? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote: All of this discussion of formats misses the shining example that's already in gEDA: the schematic format. Yes. Recently I begun studying that format and started writing a parser in Ruby -- really easy. One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, Sep 05, 2010 at 05:47:12PM +0200, Stefan Salewski wrote: One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. Sounds like a job for awk. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Stefan Salewski m...@ssalewski.de writes: On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote: All of this discussion of formats misses the shining example that's already in gEDA: the schematic format. Yes. Recently I begun studying that format and started writing a parser in Ruby -- really easy. One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. Yes, the gschem file format is much less accessible for hand/awk/sed-editing than the pcb file format. I would not like that to change - on the pcb side. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
We have lines starting with a letter followed by up to 16 decimal numbers We are NOT going with another position-determines-meaning file format. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote: We have lines starting with a letter followed by up to 16 decimal numbers We are NOT going with another position-determines-meaning file format. May I suggest that while deciding on a file format and choosing how it will work it would be good to consider the diffs that will be generated when managing a projecting using an SCM. I have thought about this a little bit and it does seem like it'll never be possible to make it amazing but I'm sure improvements over the current format can be made. It would be great to be able to look at a diff and instantly see that a component was moved or that a few traces were moved from one layer to another. At the moment even the smallest of changes creates large and complicated diffs, sometimes with lots of unrelated changes. An example of this can be seen at [1] where a single footprint was moved from one side of the board to the other. The commit message is fine for saying what has changed but it's important to be able to review changes made before committing. Thanks, Richard [1] https://www.studentrobotics.org/cgit/boards/power-hw.git/commit/?id=70118c54cf0ffe6ec6a1e98ff2d8207675d95645 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote: We have lines starting with a letter followed by up to 16 decimal numbers We are NOT going with another position-determines-meaning file format. Why? Is manually editing the only reason? I guess data in most files on our computer hard disc is position dependent. Will PCB program still work fine if we insert or delete a few bytes in the executable? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, Sep 05, 2010 at 07:22:14PM +0200, Stefan Salewski wrote: On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote: We have lines starting with a letter followed by up to 16 decimal numbers We are NOT going with another position-determines-meaning file format. Why? Is manually editing the only reason? I guess data in most files on our computer hard disc is position dependent. Will PCB program still work fine if we insert or delete a few bytes in the executable? It's because it's inflexible and unintuitive. True, most data on the hard disk is position dependent, but between the hard disk, the kernel and the filesystem driver, we never need to think about it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Stefan Salewski wrote: One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. More precisely: Positional parameters are bad. Mapping position to meaning makes it hard to add additional parameters anywhere but at the end. Structured data does not easily fit easily. It is next to impossible to throw meaningful errors if values are in the wrong order. Instead, the error likely goes unnoticed on read and can produce havoc at unsuspected places further down the flow. This is not a matter of style, but a major flaw. It is the very reason why a completely new format for pcb might be worth the effort. ---)kaiamrtin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 21:56 +0200, kai-martin knaak wrote: Stefan Salewski wrote: One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. More precisely: Positional parameters are bad. Mapping position to meaning makes it hard to add additional parameters anywhere but at the end. Structured data does not easily fit easily. It is next to impossible to throw meaningful errors if values are in the wrong order. Instead, the error likely goes unnoticed on read and can produce havoc at unsuspected places further down the flow. This is not a matter of style, but a major flaw. It is the very reason why a completely new format for pcb might be worth the effort. Yes, I agree. But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
We are NOT going with another position-determines-meaning file format.
Why?
Consider the parser for the PIN object:
Pin [rX rY Thickness Clearance Mask Drill Name Number SFlags]
Pin (rX rY Thickness Clearance Mask Drill Name Number NFlags)
Pin (aX aY Thickness Drill Name Number NFlags)
Pin (aX aY Thickness Drill Name NFlags)
Pin (aX aY Thickness Name NFlags)
The parser only sees the syntax, not the semantics:
pin_hi_format
: T_PIN '[' NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER STRING
STRING flags ']'
pin_1.7_format
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER STRING STRING NUMBER ')'
pin_1.6.3_format
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER STRING NUMBER ')'
pin_newformat
: T_PIN '(' NUMBER NUMBER NUMBER STRING NUMBER ')'
pin_oldformat
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER STRING
STRING NUMBER ')'
What happens if I want to add another parameter?
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. Compression. Either gzip the text file, or use an alternate binary file (smaller *and* faster). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote: But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. Compression. Either gzip the text file, or use an alternate binary file (smaller *and* faster). Between the two of those, I think compression is the better option. That way there's nothing to keep in sync, external tools and scripts simply need to stick a gzip filter on each end, and it's fast. But I think it should be optional, since if we zip the .pcb files, we no longer have simple diffs, which to a lot of people would be more important than small files. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra as...@sfu.ca wrote: On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote: But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. Compression. Either gzip the text file, or use an alternate binary file (smaller *and* faster). Between the two of those, I think compression is the better option. That way there's nothing to keep in sync, external tools and scripts simply need to stick a gzip filter on each end, and it's fast. But I think it should be optional, since if we zip the .pcb files, we no longer have simple diffs, which to a lot of people would be more important than small files. Did you know? I can name a few modern formats that are .zip and have no problems. examples: Office 2010 .docx/xlsx/etc OpenOffice files Android apk Java .jar A number of closed-source windows games etc. wahh wahh, i cant zip shit wa wahh,, make it a clickable options in preferences and those who diff their PCB designs are welcome to keep them uncompressed Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 5, 2010, at 6:29 PM, timecop wrote: On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra as...@sfu.ca wrote: On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote: But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. Compression. Either gzip the text file, or use an alternate binary file (smaller *and* faster). Between the two of those, I think compression is the better option. That way there's nothing to keep in sync, external tools and scripts simply need to stick a gzip filter on each end, and it's fast. But I think it should be optional, since if we zip the .pcb files, we no longer have simple diffs, which to a lot of people would be more important than small files. Did you know? I can name a few modern formats that are .zip and have no problems. examples: Office 2010 .docx/xlsx/etc OpenOffice files Android apk Java .jar A number of closed-source windows games etc. wahh wahh, i cant zip shit wa wahh,, make it a clickable options in preferences and those who diff their PCB designs are welcome to keep them uncompressed First grow up, you are the one crying And here is the solution for making the version control with git understand a zipped pcb file. http://the-gay-bar.com/2010/06/23/managing-zip-based-file-formats-in-git/ In summary you tell git that to diff the file it needs to me unzipped first. Steve Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sat, Sep 04, 2010 at 07:50:51PM -0400, Ethan Swint wrote: In parallel to how we want to implement the PCB file format, why don't we have a separate thread on *what* we want to implement? I'll propose the following as a starting point: I have one more suggestion: the facility to create recursive PCBs. What this will look like in the file format, I dunno. But we should keep it in mind. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 4, 2010, at 4:50 PM, Ethan Swint wrote: In parallel to how we want to implement the PCB file format, why don't we have a separate thread on *what* we want to implement? I'll propose the following as a starting point: 1) Better angle support: include rotation (in degrees, rotation/translation matrix, whatever) as a location argument instead of altering the pad/pin/silk/refdes/whatever location data separately 2) Footprint re-use: reduce file size by having components refer to a 'base' component with XYRS information, make component tweaking easier. Say you wanted to change all your 0603 resistors - it's easier to change the fundamental component, rather than the present case of to modifying individual components in all of their rotations. 3) Connectivity information: include the connection information between line segments, similar to (but not necessarily exactly!) SVG format, where multiple points and arcs can be included in one line. 4) DRC re-use: refer to a 'base' DRC rule, rather than re-describing the DRC at every instance. DRC rules could be arbitrarily complex or simple, e.g. elements in DRC class '250V' must have a 0.050 clearance from class '5V', but can have 0.010 clearance within '250V', or something along the lines of the 'skinny, normal, fat, power' we have in place now. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. We might not be able to use this flexibility until PCB's internals are modified, but the ability will be there, waiting to be tapped. I think that we should start from a bit lower level an include discussions of wishes for footprint file format as well, because currently footprints are a pcb file snippet. Desires for PCB footprints: True solder and paste mask layers. (could be converted to pads with no copper and the proper mask clearances set in the current PCB data structures) keepouts: - Mechanical: no components in these places. - Electrical: - No surface copper. (housings, connectors) - No internal copper. (antennas) Alignment points: - board edges - board slots - mating connector alignments glue/potting/underfill points. Any other thoughts? Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
