On 9/12/10, Peter Clifton pc...@cam.ac.uk wrote:
On Sun, 2010-09-12 at 06:57 +, ineiev wrote:
Peter Clifton wrote:
I think the rule it is triggering on in this case is probably bogus, and
the Shrink parameter should not apply to a pad solid inside a polygon.
IMHO DRC should report an
So I want to auto route a design for my ASIC, and magic is being a
little flakey (It seems it connects some nets together that don't
belong and fail to connect nets that do belong). I was wondering if
anyone has any references on how auto routers get written.
I know some stuff
DJ Delorie d...@delorie.com writes:
But I figure the top/inner/bottom class is what we need for
importing footprints. They'd be layered by class, not number, so they
can adapt to whatever number of layers the board has.
Rigid-Flex boards have pads on more than two layers. There are pads on
DJ Delorie d...@delorie.com writes:
And I think the only way to do ... in a non-kludgy way
Yet another example of you automatically putting down any idea that
isn't yours. Please stop that. Please consider the possibility that
someone might come up with a better (or even equally good) idea
Writing an autorouter is a very demanding task. I'd estimate it in the
range of 10.000's of lines of code since a good working router will contain
many heuristics to try and achieve optimal results in many situations.
Lots of cases that are mathematically difficult to understand have to be
On Fri, 10 Sep 2010 18:11:05 -0400
DJ Delorie d...@delorie.com wrote:
And I think we need anti-layers to handle some soldermask and paste
issues anyway.
I think the soldermask layer can be an anti-layer.
--
Kovacs Levente leventel...@gmail.com
Voice: +36705071002
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 13.09.2010 09:02, schrieb Oliver King-Smith:
So I want to auto route a design for my ASIC, and magic is being a
little flakey (It seems it connects some nets together that don't
belong and fail to connect nets that do belong). I was
here's a video I found that answers a lot of questions -
http://store.curiousinventor.com/guides/Surface_Mount_Soldering/QFN/
(scroll down just a little for the video)
___
geda-user mailing list
geda-user@moria.seul.org
On Mon, 2010-09-13 at 06:00 +, Ineiev wrote:
Or ensure that the results of RectPoly are checked. I find single
place to modify:
Shouldn't be a problem in the dicer. From recollection, poly_* boollean
routines check for NULL one one of the two input polygons, and will
return the appropriate
On Sep 12, 2010, at 9:09 PM, DJ Delorie wrote:
If a cutout is a property of an insulating layer, the a drill through
the whole PCB is really a composite of 2N+1 drills through N insulating
layers and N+1 conductor layers.
I'll call that the geometric viewpoint.
That seems kludgy to me.
On 09/12/2010 08:39 PM, John Doty wrote:
On Sep 12, 2010, at 1:49 PM, Rick Collins wrote:
Sounds suspicious. Are you sure you aren't talking about an assembly with
boards and a case? Bolts aren't normally
considered vias. ;^)
No, I'm talking about a narrow board with two rigid parts at
On 09/12/2010 10:09 PM, DJ Delorie wrote:
I'm thinking we structure the layers into composites. Each
composite contains some conductor/insulator layers, including other
composites, and an overall shape (outline, drills, slots).
Thus, a drilling operation is stored as a single drill object in
On 09/12/2010 10:36 PM, Andrew Poelstra wrote:
In theory, PCB never needs to know how an entire pcb assembly is
composed. That's the fab's job. IME most multi-PCB projects involve
socket/plug combinations so that the different components can plug
into each other and you don't have to worry about
On Mon, Sep 13, 2010 at 12:28:53AM -0400, DJ Delorie wrote:
but we've still got a user-interface problem.
We're used to that.
So what happens for those users?
They get exactly one composite, which ends up acting just like what we
have today - one outline, one set of drills, all
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
I think that using a Lisp (or Lispy-looking) format would be extensible,
easy to parse, and make the most people happy.
Allow me to toss out JSON. It is
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote:
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
I think that using a Lisp (or Lispy-looking) format would be extensible,
easy to parse, and
XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
I think that using a Lisp (or Lispy-looking) format would be extensible,
easy to parse, and make the most people happy.
Allow me to toss out JSON. It is about as light weight as using S-EXP,
...else along those
On Mon, 2010-09-13 at 08:37 -0700, Andrew Poelstra wrote:
It would be nice to support multiple .pcbs open at once, and to allow
copy/pasting between them.
That wouldn't be so hard to support between PCB instances. Do it like in
gschem, and have the X11 / toolkit clipboard mechanism transfer a
On Mon, Sep 13, 2010 at 08:40:47AM -0700, Andrew Poelstra wrote:
The problem I have with JSON (and to some extent, Lisp) is that it is
not self-documenting. You can't open a JSON document and immediately
see what everything is and what it does; it just looks like gibberish
and brackets.
I
Andrew Poelstra wrote:
The problem I have with JSON (and to some extent, Lisp) is that it is
not self-documenting. You can't open a JSON document and immediately
see what everything is and what it does; it just looks like gibberish
and brackets.
+1
Whatever format is going to be chosen, it
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio is
abysmal.
True on both counts and you would never want to handcraft a xml
document.
But thats not how your supposed to use it. You want to
Dear all
I wanna work with if,then and some programming properties of gEDA and
I checked them on two different version of Linux but unfortunately they
don't work.Please let me know if sb know the solution.Also I should say
if you wanna try it ,you should use gEDA guide but the
On Mon, Sep 13, 2010 at 11:57:11AM -0400, Ethan Swint wrote:
Every time I run against it, I'm still in disbelief that, in this
era, some of our most powerful and useful tools are restricted to
one character for parsing, and that one character is furthermore
restricted to newline!
Two
At 11:40 AM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote:
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
I think that using a Lisp (or Lispy-looking) format would
Peter Clifton wrote:
On Mon, 2010-09-13 at 06:00 +, Ineiev wrote:
Or ensure that the results of RectPoly are checked. I find single
place to modify:
Shouldn't be a problem in the dicer. From recollection, poly_* boollean
routines check for NULL one one of the two input polygons, and will
On Sep 13, 2010, at 10:14 AM, Rick Collins wrote:
Yes, if you have the file format provide adequate context information for
humans to read, then you are adding weight and the file becomes heavy. I
find that I can actually lift many gigabytes very easily, but some others
seem to have more
On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio is
abysmal.
True on both counts and you would never want to handcraft a xml
document.
Why?
On Sep 13, 2010, at 11:23 AM, Windell H. Oskay wrote:
I'm not sure that I see a good reason for the hatred of XML.
As one sysadmin I know put it, it allows the data representation to be as ugly
as you can imagine.
I've never found the size of Inkscape documents to be absurd, for example,
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio is
abysmal.
Why? I'd much
On Sep 13, 2010, at 10:46 AM, John Doty wrote:
The gschem format is as expressive as HTML, but having the braces stand alone
on separate lines makes the structure easier to parse with simple tools.
Simple is good.
Your definition of simple is (as usual) very different from mine.
At 01:43 PM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
XML is far too heavy, agreed, and it's signal-to-noise ratio
At 01:44 PM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
Why? I'd much rather handwrite XML than YAML.
Really? It's not the filesize of XML documents that is the concern; it is the
/redundant/ filesize. Even for a single-character tag, you need to
Andrew Poelstra as...@sfu.ca writes:
On Sun, Sep 12, 2010 at 03:40:24PM -0400, DJ Delorie wrote:
With flex cable, top and bottom aren't limited to one layer each.
Aren't they?
No. Different areas of the cable may have extra layers or pcbs
attached, changing the number of layers in
Now, the question becomes which is more fundamental?. I think
it's geometry.
A hole is the same geometry regardless of what level of the heirarchy
it's placed at. So let me rephrase: Why have seven geometric holes,
one for each layer, when we can have one geometric hole applied to the
whole
In our previous example, you'd get (1 2 3 4 5 6 7 8 ...)
Okay, but where does that leave us in terms of having multiple drawing
layers on the same physical surface?
(1 2 3 4 5 6 7 8 ...)
grouping in a composite and assignment to physical layers are two
different things. An element, for
Perhaps we store the internal data in a structure that can be
exported/imported in *any* structured format, and let those who really
want format XYZ to add the import/export logic for it?
___
geda-user mailing list
geda-user@moria.seul.org
But that is exactly what others have been saying, they are concerned
about the file size they think they would get from XML... I want to
run PCB on my iPad, etc.
File size just means a bigger file to generate/parse. Doesn't affect RAM
use significantly, which is the major limit for small
Will that mean every time something new is added to the core, each
set of import/export logic will break? Or is that part of making
changes to the core, to update all affected functions?
Rick
At 04:29 PM 9/13/2010, you wrote:
Perhaps we store the internal data in a structure that can be
On Mon, 2010-09-13 at 16:34 -0400, Windell H. Oskay wrote:
But that is exactly what others have been saying, they are concerned
about the file size they think they would get from XML... I want to
run PCB on my iPad, etc.
File size just means a bigger file to generate/parse.
And why
Will that mean every time something new is added to the core, each
set of import/export logic will break? Or is that part of making
changes to the core, to update all affected functions?
Either the core's data structure will be flexible enough, or there
could be an intermediate layer that
My concerns with XML have always been on the talking to it from
inside pcb side. File size is nothing compared to the complexity of
supporting it in the first place.
___
geda-user mailing list
geda-user@moria.seul.org
Sorry, I was not able to follow the whole discussion, but I do not like
your arguments too much. XML may be fine -- if it has big benefits, that
may be much more important than size.
I don't care about XML one way or the other, I was pointing out that the
argument presented against it was
On Sep 13, 2010, at 2:22 PM, Stefan Salewski wrote:
On Mon, 2010-09-13 at 16:34 -0400, Windell H. Oskay wrote:
But that is exactly what others have been saying, they are concerned
about the file size they think they would get from XML... I want to
run PCB on my iPad, etc.
File size just
On Mon, Sep 13, 2010 at 02:31:34PM -0400, Rick Collins wrote:
At 01:44 PM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
Why? I'd much rather handwrite XML than YAML.
Really? It's not the filesize of XML documents that is the concern; it is the
On Mon, Sep 13, 2010 at 04:29:07PM -0400, DJ Delorie wrote:
In our previous example, you'd get (1 2 3 4 5 6 7 8 ...)
Okay, but where does that leave us in terms of having multiple drawing
layers on the same physical surface?
(1 2 3 4 5 6 7 8 ...)
grouping in a composite and
On Sep 13, 2010, at 2:27 PM, DJ Delorie wrote:
Now, the question becomes which is more fundamental?. I think
it's geometry.
A hole is the same geometry regardless of what level of the heirarchy
it's placed at. So let me rephrase: Why have seven geometric holes,
one for each layer,
DJ Delorie d...@delorie.com writes:
Now, the question becomes which is more fundamental?. I think
it's geometry.
A hole is the same geometry regardless of what level of the heirarchy
it's placed at. So let me rephrase: Why have seven geometric holes,
one for each layer, when we can have
So drills, stacking order and physical layer geometry will be defined
in terms of composites, and drawing layers will be tagged to physical
layers?
Do we need a concept of layer groups in this setup?
In that example, the layer groups would be implied - drawing layers[*]
mapped to the same
I think that an object that spans more than one layer cannot
sensibly be considered primitive in a layer-centric description of
geometry.
Then stop thinking in terms of being layer-centric.
___
geda-user mailing list
geda-user@moria.seul.org
At 04:34 PM 9/13/2010, you wrote:
But that is exactly what others have been saying, they are concerned
about the file size they think they would get from XML... I want to
run PCB on my iPad, etc.
File size just means a bigger file to generate/parse. Doesn't affect RAM
use significantly,
On Sep 13, 2010, at 4:32 PM, Rick Collins wrote:
As Windell says, the arguments against XML seem to be based on some sort of
bias rather than any real facts against it.
You can't easily parse it with simple tools like awk or sed. That's a fact.
John Doty Noqsi Aerospace, Ltd.
On Sep 13, 2010, at 3:32 PM, Rick Collins wrote:
At 04:34 PM 9/13/2010, you wrote:
But that is exactly what others have been saying, they are concerned
about the file size they think they would get from XML... I want to
run PCB on my iPad, etc.
File size just means a bigger file to
You can't easily parse it with simple tools like awk or sed. That's a
fact.
No, it's not a fact.
It's actually just you expressing your opinion that awk and sed are simple
tools.
___
geda-user mailing list
geda-user@moria.seul.org
On Sep 13, 2010, at 5:26 PM, Windell H. Oskay wrote:
You can't easily parse it with simple tools like awk or sed. That's a
fact.
No, it's not a fact.
It's actually just you expressing your opinion that awk and sed are simple
tools.
Widely used, classic, useful tools then.
John Doty
I call the second large, bloat, and ugly.
98 chars vs 134 or 36% bigger for a pin with these mythical formats.
You're making my point. 36% is way under the 900% that I budgeted to show
that it still isn't a big deal in terms of file size-- absolutely
negligible in determining how portable
On Sep 13, 2010, at 5:25 PM, Steven Michalske wrote:
Arguably grep and sed will have issues with both XML or YAML
AWK is perhaps more important, as one can often do serious processing of data
in line-oriented formats using very short programs.
John Doty Noqsi Aerospace, Ltd.
Widely used, classic, useful tools then.
XML is easily parsed with Perl. It's more widely used than awk or
sed, and far more useful.
Classic is not a point in your favor here.
___
geda-user mailing list
geda-user@moria.seul.org
On Sep 13, 2010, at 5:39 PM, DJ Delorie wrote:
Widely used, classic, useful tools then.
XML is easily parsed with Perl. It's more widely used than awk or
sed, and far more useful.
And far more of a conceptual mess. But regardless of personal preference, why
not embrace the whole
On Mon, Sep 13, 2010 at 06:16:47PM -0400, DJ Delorie wrote:
So drills, stacking order and physical layer geometry will be defined
in terms of composites, and drawing layers will be tagged to physical
layers?
Do we need a concept of layer groups in this setup?
In that example, the
On Mon, Sep 13, 2010 at 04:29:07PM -0400, DJ Delorie wrote:
In our previous example, you'd get (1 2 3 4 5 6 7 8 ...)
Okay, but where does that leave us in terms of having multiple drawing
layers on the same physical surface?
(1 2 3 4 5 6 7 8 ...)
What's the physical meaning of an
On Mon, Sep 13, 2010 at 07:35:29PM -0400, Windell H. Oskay wrote:
I say no to raw XML as making out own format, but would use SVG with
extra info embedded.
This way our drawings would work in all modern web browsers, we get all of
the primitives we would ever want, including fancy
What's the physical meaning of an eight-layered composite?
A board with eight copper layers, assuming the eight drawing layers
each map to a different physical layer. Making the structure flat
just means that all your drills and outlines apply to all layers
equally.
So wouldn't a better
On Mon, Sep 13, 2010 at 08:58:54PM -0400, DJ Delorie wrote:
What's the physical meaning of an eight-layered composite?
A board with eight copper layers, assuming the eight drawing layers
each map to a different physical layer. Making the structure flat
just means that all your drills and
pin:
pinNumber: 2
pinName: rst
x1: 1234
y1: 4321
x2: 2345
y2: 4321
layer: component
or
pinpinNumber2/pinNumberpinNamerst\pinNamex11234\x1y
14321\y1x22345\x2y25432\y2layercomponent\layer\pin
I call the second large, bloat, and ugly.
I don't think we're ready for code yet :-)
Besides, I was hoping to switch to C++ before doing any major internal
changes. Then, a composite is just a container of objects, one of
which may be itself a composite, but might include drills, drawing
layers, etc.
[*] We need a better term for drawing layers, since layer means
something specific in PCB design. Or another name for physical
layers. Or something ;-)
How about overlay?
Canvas comes to mind. It hints that you draw on it. Or this could
just be the fact that I have
On Sep 13, 2010, at 6:45 PM, Andrew Poelstra wrote:
On Mon, Sep 13, 2010 at 08:58:54PM -0400, DJ Delorie wrote:
What's the physical meaning of an eight-layered composite?
A board with eight copper layers, assuming the eight drawing layers
each map to a different physical layer. Making
Nice,
but I prefer
#! /usr/bin/python
import yaml
from pprint import pprint
pcb = yaml.load('''
---
pin:
pinNumber: 2
pinName: rst
x1: 1234
y1: 4321
x2: 2345
y2: 4321
layer: component
...
''')
# or from file
#pcb = yaml.load(open(sys.argv[1], 'rb'))
On Mon, Sep 13, 2010 at 07:24:57PM -0700, Steven Michalske wrote:
On Sep 13, 2010, at 6:45 PM, Andrew Poelstra wrote:
/*** BEGIN ***/
/*
* The layer structuring works as follows:
* 1. At the physical level, PCBs are composed of composites. These
* composites have an
C2 and C3 is set to thickness 1mm.
C1 is set to thickness 5mm.
There is a discrepancy! How should we resolve this?
By telling the user they're wrong, or by just ignoring the problem
until the data's needed.
___
geda-user mailing list
70 matches
Mail list logo
