On 03/19/2011 12:01 PM, Martin Kupec wrote:
> > > On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
No problem here. Just define that conductive ink as copper or conductive
> > type layer. I don't care how that layer happens to be manufactured.
>
> No. For describing geometry, I agr
On Mar 21, 2011, at 6:59 PM, Kai-Martin Knaak wrote:
>
> IMHO, the emphasis here was on "your kind of", with "you" pointing to
> John Doty.
But Steven's understanding is clearly similar to mine. DJ simply doesn't
understand what we're talking about, and I have found no way to explain it to
h
Steven Michalske wrote:
>> And your kind of bottom-up design never gets done at all, because of
>> impossible-to-meet requirements for unlimited flexibility.
>>
> Wow all my bottom up designs in shipping products must not exist
IMHO, the emphasis here was on "your kind of", with "you" point
Martin Kupec wrote:
> I am the one who is willing to code it. And my majority I simply mean
> number of people involved. I am democratic, just counting heads :-).
In that case, just count me in on DJs side by default ;-)
---<)kaimartin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffen
On Mar 18, 2011, at 2:25 PM, DJ Delorie wrote:
> Inkscape gives you complete flexibility, and it's absolutely useless
> as a pcb layout tool.
Indeed. So please remember that the job of a layout tool is to describe the
*geometry* of *physical* objects. It's *not* just a graphical tool, nor shoul
On Mar 19, 2011, at 2:03 PM, Steven Michalske wrote:
> Oh my! You can draw The plating on the insulator layer. Thus making the
> plating a real object of conductor This is more 3d cad leaking through.
DJ once made the observation that pcb's basic problem is the lack of a proper
layer stac
On Mar 19, 2011, at 12:33 PM, John Doty wrote:
>
> On Mar 19, 2011, at 1:20 PM, Steven Michalske wrote:
>
>> This is what bothers me about a hole layer, un plated vs plated, the holes
>> do not define electrical contact, the plating does.
>>
>> Or, rivits, or the soldered wires on hand
On Mar 19, 2011, at 9:50 AM, Martin Kupec wrote:
> On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
>>
>> On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
>>
>>> If layers types would be defined by attributes, someone would be able to
>>> declare one layer both as conductive and
On Mar 19, 2011, at 1:20 PM, Steven Michalske wrote:
> This is what bothers me about a hole layer, un plated vs plated, the holes
> do not define electrical contact, the plating does.
>
> Or, rivits, or the soldered wires on hand assembled multilayer boards.
>
> Well with silver ink circuit
On Mar 19, 2011, at 8:13 AM, John Doty wrote:
>
> On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote:
>
>> BTW., there were electronic circuitries before PCBs were invented and the
>> future of electronics manufacturing is most likely something
>> three-dimensional, arbitrarily shaped.
>
This message makes me think that COW should remember what master it was copied
from and an edited flag.
On Mar 18, 2011, at 5:16 PM, Stephan Boettcher
wrote:
> DJ Delorie writes:
>
Except gerbers have special cases for thermals and pads, for example.
>>>
>>> So there need to be att
On Mar 18, 2011, at 4:39 PM, DJ Delorie wrote:
>
>> It is the exporter's job to understand drilling. For geometry
>> capture, all you need to know is the shape. Modules with no "need to
>> know" should not know.
>
> The autorouter needs to know not to run traces across unplated
> holes...
On Mar 18, 2011, at 4:37 PM, DJ Delorie wrote:
>
>> Still, I do not see a need for outline layers anywhere, except as an
>> attribute on a graphical layer that tells an exporter where to stop
>> drawing.
>
> Hmmm... so you think PCB should let the user place an element in a
> physically im
On Mar 18, 2011, at 4:17 PM, Stephan Boettcher
wrote:
> DJ Delorie writes:
>
I expect the plugin mechanism to be the way to write *all* the core
bits, though.
>>>
>>> The more important it is, that what is below the plugin mechanism is as
>>> general as necessary, and since th
On Mar 18, 2011, at 4:02 PM, DJ Delorie wrote:
>
>>> Except gerbers have special cases for thermals and pads, for example.
>>
>> So there need to be attributes on shapes.
>
> No, the exporters really need to have access to the whole collection
> of shapes that means "pin" so they can do p
On Mar 18, 2011, at 3:43 PM, DJ Delorie wrote:
>
>>> I expect the plugin mechanism to be the way to write *all* the core
>>> bits, though.
>>
>> The more important it is, that what is below the plugin mechanism is as
>> general as necessary, and since that is difficult to judge up front:
On Mar 18, 2011, at 3:22 PM, Stephan Boettcher
wrote:
> DJ Delorie writes:
>
>>> ... I think the tool we have is pretty good already. Very good. Thanks!
>>
>> The tool we have already is nearly impossible to maintain, though.
>>
>>> Please do not expect that users write plugins. The t
On Mar 18, 2011, at 3:07 PM, DJ Delorie wrote:
>
>> That's the kind of "top down" design that produces a tool that meets
>> today's requirements in the minimum amount of time, but produces an
>> inflexible tool limited to those requirements.
>
> And your kind of bottom-up design never gets
On Mar 18, 2011, at 2:19 PM, DJ Delorie wrote:
>
>> I don't want to end up with the current state that some 'specialy
>> named' layers receive special treatment.
>
> From a practical standpoint, I think it makes sense to have a fast way
> to scan for layers of some high-level type, as well
On Mar 19, 2011, at 11:01 AM, Martin Kupec wrote:
> On Sat, Mar 19, 2011 at 10:56:27AM -0600, John Doty wrote:
>>
>> On Mar 19, 2011, at 10:50 AM, Martin Kupec wrote:
>>
>>> On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
>>
On Sat, Mar 19, 2011 at 10:56:27AM -0600, John Doty wrote:
>
> On Mar 19, 2011, at 10:50 AM, Martin Kupec wrote:
>
> > On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
> >>
> >> On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
> >>
> >>> If layers types would be defined by attributes,
On Mar 19, 2011, at 10:50 AM, Martin Kupec wrote:
> On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
>>
>> On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
>>
>>> If layers types would be defined by attributes, someone would be able to
>>> declare one layer both as conductive and as s
On Sat, Mar 19, 2011 at 04:43:29PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
>
> > On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
> >> Martin Kupec writes:
> >> > That is a bit complicated. I need a clean definition of layer types, so
> >> > one can pick the righ
On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote:
>
> On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
>
> > If layers types would be defined by attributes, someone would be able to
> > declare one layer both as conductive and as silk for example. That could
> > cause me a nighmares. Tha
On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote:
> If layers types would be defined by attributes, someone would be able to
> declare one layer both as conductive and as silk for example. That could
> cause me a nighmares. That is why I insist on 'typed' layers, not
> 'tagged' layer.
No. The nig
John Doty writes:
> On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote:
>
>> BTW., there were electronic circuitries before PCBs were invented and
>> the future of electronics manufacturing is most likely something
>> three-dimensional, arbitrarily shaped.
>
> Yes. I'm now working with two groups t
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
>> Martin Kupec writes:
>> > That is a bit complicated. I need a clean definition of layer types, so
>> > one can pick the right layer when needed. But some attributes in
>> > addition to layer type are pos
On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote:
> BTW., there were electronic circuitries before PCBs were invented and the
> future of electronics manufacturing is most likely something
> three-dimensional, arbitrarily shaped.
Yes. I'm now working with two groups that are fabricating parts
Stephan Boettcher writes:
>> Now consider a differential pair. It's a line but you *don't* move
>> the *line* endpoints, you move the *pair* control points.
>
> That is a hard one. You could define a composit of type "morphable" The
> endpoints of shapes inside such a composite become pointable
Am 19.03.2011 um 02:29 schrieb John Doty:
... comparison to the C language snipped ...
Proper bottom-up design *never* results in "impossible-to-meet
requirements" because it starts from capabilities.
Nice description, John.
What can a layered description of tame plane geometries (no
f
On Sat, Mar 19, 2011 at 11:02:55AM +0100, Stephan Boettcher wrote:
> I will now have a look at that. But what do you call majority? The
> most vocal people here, like John and myself did not offer to do any
> coding, yet. In the end, those that code (DJ, you ?) decide.
I am the one who is willin
Martin Kupec writes:
> Hi all,
>
> I appreciate the discussion.
So do I. It started out a bit of a mess, because we were talking about
different things, but in the end I think there was not left much
disagreement about fundamental issues.
> There we nearly no objections to my layer concept, ju
On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote:
> And your kind of bottom-up design never gets done at all, because of
> impossible-to-meet requirements for unlimited flexibility.
"My kind" of bottom-up design is precisely what Ritchie did when he invented C.
Contrast C with PL/I, the language i
DJ Delorie writes:
>> Still, I do not see a need for outline layers anywhere, except as an
>> attribute on a graphical layer that tells an exporter where to stop
>> drawing.
>
> Hmmm... so you think PCB should let the user place an element in a
> physically impossible location, because it doesn't
DJ Delorie writes:
>> > Except gerbers have special cases for thermals and pads, for example.
>>
>> So there need to be attributes on shapes.
>
> No, the exporters really need to have access to the whole collection
> of shapes that means "pin" so they can do pin-specific things. If the
> export
Hi all,
I appreciate the discussion.
There we nearly no objections to my layer concept, just to the
via/footprint/composite.
I have updated the page (http://geda.seul.org/wiki/geda:pcb_layers)
and I hope it not reflects the 'opinion of majority'.
So again. Coments are welcome, the discussion was
On Mar 18, 2011, at 5:39 PM, DJ Delorie wrote:
>
>> It is the exporter's job to understand drilling. For geometry
>> capture, all you need to know is the shape. Modules with no "need to
>> know" should not know.
>
> The autorouter needs to know not to run traces across unplated
> holes...
Whet
> It is the exporter's job to understand drilling. For geometry
> capture, all you need to know is the shape. Modules with no "need to
> know" should not know.
The autorouter needs to know not to run traces across unplated
holes...
___
geda-user maili
On Mar 18, 2011, at 5:25 PM, DJ Delorie wrote:
> You don't drill through ink. You drill through what the ink is *on*.
> It's a semantic issue. If you want a spot where ink is missing, you
> add an anti-circle there. It's different than a physical hole. It's
> still a circle that removes thing
> Still, I do not see a need for outline layers anywhere, except as an
> attribute on a graphical layer that tells an exporter where to stop
> drawing.
Hmmm... so you think PCB should let the user place an element in a
physically impossible location, because it doesn't care about the
outlines?
DJ Delorie writes:
>> I do not like the concept of composit outlines. Does each layer
>> have its outline? How does it do partial vias?
>
> In the case of flex cables, each layer *does* have its own outline.
> The tool needs to know that vias go only across layers that actually
> exist at that
> Would and an 'outline' layer do for you? We can rename it so 'assembly'
> layer or so.
"assembly" has a specific meaning in CAM - it's a reference drawing,
either to help the CAM engineer understand how your board is
assembled, or to help with assembling the components to it.
On Sat, Mar 19, 2011 at 12:17:36AM +0100, Stephan Boettcher wrote:
> But that's why I argue for hole layers. A hole is a shape on a hole
> layer. The layers attributes define what needs to be drilled.
> Actually, they only define to which layers they electrically conduct.
> That is all the tools n
> > As general as neccessary, but not as general as *possible*.
>
> But we cannot know what is necessary.
Well, we start by asking people who do pcb layouts what they need :-)
"My point exactly. Do customers *want* portable fire?"
> >> On top of that is a memory representation, that introduce
On Mar 18, 2011, at 5:05 PM, DJ Delorie wrote:
>
>> Yes, sadly gEDA is a high productivity toolkit for spaceflight
>> hardware, ASIC design, merging tabular design data with graphical
>> design data, symbolic circuit analysis, and even hydraulics.
>
> No matter what I say, you'll find a way to
DJ Delorie writes:
>> > I expect the plugin mechanism to be the way to write *all* the core
>> > bits, though.
>>
>> The more important it is, that what is below the plugin mechanism is as
>> general as necessary, and since that is difficult to judge up front: as
>> general as possible, without
> Except that we'll argue forever if we can't agree on the words.
I don't care about the words. I care about the ideas, the concepts,
the use-cases. You throw "factored design" around like it's the
solution to everything, but it's a meaningless term without a specific
solution behind it.
Unfor
On Mar 18, 2011, at 5:02 PM, DJ Delorie wrote:
> These are all examples of a need for both a semantic and data
> heirarchy, where parts of your design are grouped together and treated
> as a single object, sometimes replicated, sometimes customized.
Yes. Factored design.
> What
> we call them
> I do not like the concept of composit outlines. Does each layer
> have its outline? How does it do partial vias?
In the case of flex cables, each layer *does* have its own outline.
The tool needs to know that vias go only across layers that actually
exist at that spot.
_
> Yes, sadly gEDA is a high productivity toolkit for spaceflight
> hardware, ASIC design, merging tabular design data with graphical
> design data, symbolic circuit analysis, and even hydraulics.
No matter what I say, you'll find a way to disagree with me.
I *meant* sadly, the results are THE ON
> > Except gerbers have special cases for thermals and pads, for example.
>
> So there need to be attributes on shapes.
No, the exporters really need to have access to the whole collection
of shapes that means "pin" so they can do pin-specific things. If the
exporter doesn't need that high-leve
On Friday 18 March 2011, John Doty wrote:
> Yes, sadly gEDA is a high productivity toolkit for
> spaceflight hardware, ASIC design, merging tabular design
> data with graphical design data, symbolic circuit analysis,
> and even hydraulics.
ROFLMAO
___
John Doty writes:
> On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote:
>
>> Except, I see no need to specify any insulating layers here.
>
> "I see no need" is exactly the kind of thinking that produces an
> inflexible, limited tool. I see *every* need to base the description
> on geometry, so
DJ Delorie writes:
>> As someone proposed, it is possible to have different hole size on
>> different layers. So I think the best would be to have special 'hole'
>> object on each layer. And that object will always be in composite
>> container, and all of them will be forcebly aligned to the same
On Mar 18, 2011, at 4:34 PM, DJ Delorie wrote:
>>
>> In your sense, you have no idea what the "space of the possible" is
>> for the integers.
>
> Of course I do. It's aleph null, the set of counting numbers.
That's not the space of the possible, that's only the range of the abstraction.
To k
On Fri, Mar 18, 2011 at 01:18:16PM -0700, Steven Michalske wrote:
> Embedded resistor and capacitors are in holes in the separating layers.
>
> Some separating layers are more like a solder mask and sprayed down
> rather than FR4 and prepreg.
>
> Just because standard FR4 Fabs don't usually use a
> > I expect the plugin mechanism to be the way to write *all* the core
> > bits, though.
>
> The more important it is, that what is below the plugin mechanism is as
> general as necessary, and since that is difficult to judge up front: as
> general as possible, without compromising the final go
On Mar 18, 2011, at 4:34 PM, DJ Delorie wrote:
> The problem with geda is that the lower leves are *so* flexible, that
> there was no semantic consistency, no intrinsic model for the upper
> levels to follow. The results were sadly predictable.
Yes, sadly gEDA is a high productivity toolkit for
DJ Delorie writes:
>> Hide all composites with attribute "type=via". The GUI probably
>> maintains an extra list of those, as well as a list of elements, for
>> performance.
>
> Why the GUI? Why can't the core maintain that list, since a lot of
> things will need it? I care a lot about perform
> The right kind of flexibility is even more important
> to the developers than to the users.
Since you're not a pcb developer, how can you know what the right kind
of flexibility is?
> In your sense, you have no idea what the "space of the possible" is
> for the integers.
Of course I do. It's
> If you mean 'physical layer' by 'composite', than yes. Each of those
> will have it's 'outline' layer.
I meant sub-assemblies.
This is hard to describe because of the near-impossible list of things
we want to support, but...
There are two types of sub-assemblies. First, composite objects whi
DJ Delorie writes:
>> ... I think the tool we have is pretty good already. Very good. Thanks!
>
> The tool we have already is nearly impossible to maintain, though.
>
>> Please do not expect that users write plugins. The tool is already too
>> good as it is to make is worth the effort to learn
On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote:
>
>> That's the kind of "top down" design that produces a tool that meets
>> today's requirements in the minimum amount of time, but produces an
>> inflexible tool limited to those requirements.
>
> And your kind of bottom-up design never gets done
On Fri, Mar 18, 2011 at 05:58:29PM -0400, DJ Delorie wrote:
>
> > As someone proposed, it is possible to have different hole size on
> > different layers. So I think the best would be to have special 'hole'
> > object on each layer. And that object will always be in composite
> > container, and al
On Fri, Mar 18, 2011 at 10:40:02PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
>
> > On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
> >>
> >> > But if I am doing that (just to extend this silly example too far), I
> >> > would want the DRC checker to ensure that it obeys
> That's the kind of "top down" design that produces a tool that meets
> today's requirements in the minimum amount of time, but produces an
> inflexible tool limited to those requirements.
And your kind of bottom-up design never gets done at all, because of
impossible-to-meet requirements for un
On Mar 18, 2011, at 3:11 PM, DJ Delorie wrote:
>
>> But if I am doing that (just to extend this silly example too far), I
>> would want the DRC checker to ensure that it obeys both the rules for
>> copper _and_ for silk.
>
> Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on
>
On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote:
> Except, I see no need to specify any insulating layers here.
"I see no need" is exactly the kind of thinking that produces an inflexible,
limited tool. I see *every* need to base the description on geometry, so that
the tool's limits ar
On Mar 18, 2011, at 3:09 PM, DJ Delorie wrote:
> I feel that the data layer is easiest to implement, but it seems to be
> what we're arguing about the most. I say we should ignore that
> problem for now, until we have a better understanding of what we want
> at the other two layers.
That's the
> As someone proposed, it is possible to have different hole size on
> different layers. So I think the best would be to have special 'hole'
> object on each layer. And that object will always be in composite
> container, and all of them will be forcebly aligned to the same center.
What I suggest
> I do not agree with the term high level here. I agree that there
> may be layers of different types, that require special treatment.
> These are low-level types, like "conductive" for layers that
> electrically connect things, or "holes" for connections between
> layers, and "other" for anythin
On Fri, Mar 18, 2011 at 09:23:20PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
> > Actually what I am trying to do, is to have concept so layers don't
> > interract with layers of different type. The composits are a bit
> > problem, because I would need to consider more layers when perf
DJ Delorie writes:
>> I don't want to end up with the current state that some 'specialy
>> named' layers receive special treatment.
>
>>From a practical standpoint, I think it makes sense to have a fast way
> to scan for layers of some high-level type, as well as further typing
> them by name.
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
>>
>> > But if I am doing that (just to extend this silly example too far), I
>> > would want the DRC checker to ensure that it obeys both the rules for
>> > copper _and_ for silk.
>>
>> Hmmm... DRC is already fa
> ... I think the tool we have is pretty good already. Very good. Thanks!
The tool we have already is nearly impossible to maintain, though.
> Please do not expect that users write plugins. The tool is already too
> good as it is to make is worth the effort to learn how to do that.
I expect t
DJ Delorie writes:
>> We are talking about different thinks, I guess.
>
> Probably.
>
>> The tool shall be very focussed on traces, elements, vias.
>
> To be this kind of focused, it needs to have some understanding of
> what a via is. You wouldn't want to invoke the via editor on a trace,
> but
> Hide all composites with attribute "type=via". The GUI probably
> maintains an extra list of those, as well as a list of elements, for
> performance.
Why the GUI? Why can't the core maintain that list, since a lot of
things will need it? I care a lot about performance.
> Exporters can only
On Fri, Mar 18, 2011 at 05:09:09PM -0400, DJ Delorie wrote:
> User level - a via is a connection between layers that I can add,
> remove, edit, and move around.
>
> Tool level - a via is an anonymous (i.e. not part of an element) hole
> between layers electrically connecting copper pads on each la
On Fri, Mar 18, 2011 at 05:19:10PM -0400, DJ Delorie wrote:
>
> > I don't want to end up with the current state that some 'specialy
> > named' layers receive special treatment.
>
> From a practical standpoint, I think it makes sense to have a fast way
> to scan for layers of some high-level type,
On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
>
> > But if I am doing that (just to extend this silly example too far), I
> > would want the DRC checker to ensure that it obeys both the rules for
> > copper _and_ for silk.
>
> Hmmm... DRC is already fab-specific anyway. Maybe DRC s
> I don't want to end up with the current state that some 'specialy
> named' layers receive special treatment.
>From a practical standpoint, I think it makes sense to have a fast way
to scan for layers of some high-level type, as well as further typing
them by name.
My original design had an enu
DJ Delorie writes:
>> That is up to the HID to find the composits with attribute
>> "type=via", and present them in a via toll selector.
>
> I disagree with this.
>
> The HID is the Human Interaction Device - how the information is
> presented to the user. GUI, printer, etc.
>
> The HID is the w
On Fri, Mar 18, 2011 at 01:52:38PM -0700, Jared Casper wrote:
> On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie wrote:
> > At the design/edit level, that layer is a copper layer. Note to John:
>
> > And DRC freaks out because it has two separate incompatible sets of
> > rules to apply to it.
Tha
> But if I am doing that (just to extend this silly example too far), I
> would want the DRC checker to ensure that it obeys both the rules for
> copper _and_ for silk.
Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on
the other side of the CAM job? I.e. make DRC an exporter, s
DJ Delorie writes:
>> But at the core, they work all just the same.
>
> The "core" includes the autorouters, optimizers, DRC, exporters,
> reports, and even simple editing - we have a "hide vias" button. How
> does that work if you no longer have "vias" as an inherent type?
Hide all composites
On Mar 18, 2011, at 1:32 PM, DJ Delorie wrote:
>
>> But at the core, they work all just the same.
>
> The "core" includes the autorouters, optimizers, DRC, exporters,
> reports, and even simple editing - we have a "hide vias" button. How
> does that work if you no longer have "vias" as an
> We are talking about different thinks, I guess.
Probably.
> The tool shall be very focussed on traces, elements, vias.
To be this kind of focused, it needs to have some understanding of
what a via is. You wouldn't want to invoke the via editor on a trace,
but you wouldn't want the "move" opt
On Mar 18, 2011, at 2:55 PM, Stephan Boettcher wrote:
> DJ Delorie writes:
>
>>> Inflexible wired-in behavior
>>
>> ... is MANDATORY if you're going to produce a tool that's usable.
>>
>> That's the difference between a pcb editor and, say, inkscape.
>>
>> Inkscape gives you complete flexibi
On Fri, Mar 18, 2011 at 09:49:08PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
> > Ok. We probably don't understand each other, so I will just state my fears.
> >
> > I would like to know about each drawing layer where it belongs to.
> >
> > So when I am performing DRC check, I will kno
DJ Delorie writes:
>> Inflexible wired-in behavior
>
> ... is MANDATORY if you're going to produce a tool that's usable.
>
> That's the difference between a pcb editor and, say, inkscape.
>
> Inkscape gives you complete flexibility, and it's absolutely useless
> as a pcb layout tool.
>
> You seem
On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie wrote:
>
>> But what if I want a silk layer to just be a copy of a copper layer?
>
> This is a different category of problem - the CAM job. Typically,
> you'd have a file that describes how to map design layers to output
> layers. In that file, you'd s
> You can always tell the board house to use copper minus soldermask as
> silk.
That sounds like fun...
Now I want to make a pcb plugin that copies all copper to the silk
layer, but only where there's soldermask. You get a picture of your
circuit in white-on-green, that actually works :-)
___
Jared Casper writes:
> On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec wrote:
>> If layers types would be defined by attributes, someone would be able to
>> declare one layer both as conductive and as silk for example. That could
>> cause me a nighmares. That is why I insist on 'typed' layers, not
Martin Kupec writes:
> On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote:
>> Martin Kupec writes:
>>
>> > On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote:
>> >> The file format need not know about these distictions. Both are
>> >> graphical layers, with differ
> But what if I want a silk layer to just be a copy of a copper layer?
This is a different category of problem - the CAM job. Typically,
you'd have a file that describes how to map design layers to output
layers. In that file, you'd say "this copper layer should be output
as a silk layer also".
On Fri, Mar 18, 2011 at 09:29:04PM +0100, Stephan Boettcher wrote:
> Martin Kupec writes:
>
> > On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote:
> >>
> >> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote:
> >>
> >> > Generaly you are proposing that there should be a special type of
> >
On Fri, Mar 18, 2011 at 1:32 PM, DJ Delorie wrote:
> The "core" includes the autorouters, optimizers, DRC, exporters,
> reports, and even simple editing - we have a "hide vias" button. How
> does that work if you no longer have "vias" as an inherent type?
>
You go through and hide all the compos
Steven Michalske writes:
> On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec wrote:
>> On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote:
>>>
>>> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:
>>>
>>> >> Ok. So "via" should be a circle element on "hole" typed layer.
>>> >
>>> > No.
On Fri, Mar 18, 2011 at 01:20:43PM -0700, Steven Michalske wrote:
> On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher
> > The GUI must present footprints, vias, and hierachical sublayouts, both
> > in copy on write and in truly hierachical fashion. But at the core,
> > they work all just the same
> That is up to the HID to find the composits with attribute
> "type=via", and present them in a via toll selector.
I disagree with this.
The HID is the Human Interaction Device - how the information is
presented to the user. GUI, printer, etc.
The HID is the wrong place to be assigning *meani
1 - 100 of 224 matches
Mail list logo
