Re: gEDA-user: Broken TO92 footprint

2011-05-20 Thread Stephan Boettcher
DJ Delorie  writes:

>> The TO92 package has well define pin numbers.  The mapping from
>> transistor pins to footprint pins should happen in the schematic.
>
> Worse, the mapping from EBC to 123 is *different* for different
> transistors using the TO-92 case.
>
> Compare 2N3904  - E-B-C
> 2SC2631 - E-C-B

The package pin numbers are well defined: 1-2-3.  The Symbol on the
schematic should tell which (numeric) package pin conects to which
transitor contact.  There are also FETs in that package.

I'd still use slotting for this in generic symbols.  I've made a quick
generic NPN symbol that demonstrates how I think generic symbols may
work.

gschem GUI may need an additional feature in the attibute editor: When
editing an attribute "NAME", it shall offer a dropdown menu of choices
given in the attibute "NAMEs" (or some other less ambiguous mangling of
NAME).

v 20110115 2
P 600 1000 600 800 1 0 0
{
T 500 850 5 6 1 1 0 0 1
pinnumber=1
T 700 850 5 6 0 0 0 0 1
pinseq=1
T 400 850 5 6 0 1 0 0 1
pinlabel=C
T 700 950 5 6 0 1 0 0 1
pintype=pas
}
P 600 200 600 0 1 0 1
{
T 500 50 5 6 1 1 0 0 1
pinnumber=3
T 700 50 5 6 0 0 0 0 1
pinseq=3
T 400 50 5 6 0 1 0 0 1
pinlabel=E
T 700 150 5 6 0 1 0 0 1
pintype=pas
}
V 500 501 316 3 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
T 900 700 5 10 0 0 0 0 1
device=NPN
L 600 200 400 400 3 0 0 0 -1 -1
L 600 800 400 600 3 0 0 0 -1 -1
L 400 700 400 300 3 0 0 0 -1 -1
P 0 500 184 500 1 0 0
{
T 100 550 5 6 1 1 0 0 1
pinnumber=2
T 200 550 5 6 0 0 0 0 1
pinseq=2
T 0 550 5 6 0 1 0 0 1
pinlabel=B
T 200 650 5 6 0 1 0 0 1
pintype=pas
}
L 400 500 184 500 3 0 0 0 -1 -1
L 600 200 564 272 3 0 0 0 -1 -1
L 600 200 528 236 3 0 0 0 -1 -1
L 528 236 564 272 3 0 0 0 -1 -1
T 900 500 8 10 1 1 0 0 1
refdes=Q?
T 1300 500 5 10 0 0 0 0 1
footprint=?
T 0 1500 8 10 0 0 0 0 1
numslots=6
T 0 1300 8 10 0 1 0 0 1
slotdef=1:1,2,3
T 0 1100 8 10 0 1 0 0 1
slotdef=2\:1,3,2
T 700 1100 8 10 0 1 0 0 1
slotdef=3:2,1,3
T 700 1300 8 10 0 1 0 0 1
slotdef=4:2,3,1
T 1400 1300 8 10 0 1 0 0 1
slotdef=5:3,1,2
T 1400 1100 8 10 0 1 0 0 1
slotdef=6:3,2,1
T 1400 1500 8 10 0 0 0 0 1
slot=1
T 900 300 8 10 0 1 0 0 1
footprints=SOT23,TO92,TO220
T 0 1700 8 10 0 0 0 0 1
slotmode=alternatives
T 0 1900 8 10 0 0 0 0 1
promote=slot,device,refdes,footprint

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Broken TO92 footprint

2011-05-19 Thread Stephan Boettcher

Vanessa Ezekowitz  writes:

> The TO92 footprint included with PCB does not work with the schematic
> importer therein.  Try to reference it and the importer complains
> about missing pins, because it uses numbered pins instead of the B-C-E
> lettering used in gschem's transistor symbols.  

The TO92 package has well define pin numbers.  The mapping from
transistor pins to footprint pins should happen in the schematic.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Stephan Boettcher wrote:

>> My colleagues use eagle.  I review their gerbers with gerbv. They
>> envy my hierachical schematics and scripting fu,
>  
> Funny. I got the impression, the scripting abilities of eagle are one 
> of the few things eagle really excels at. 

I've heard so, yes, one of our engineers does eagle scripting once in a
while.  But he had to learn how to script eagle.  I did not learn any
new language, I script in sed, awk, python, gnumeric.  Both are good
things.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
k...@aspodata.se (Karl Hammar) writes:

> Stephan:
> ...
>> I still do not know where the pcb users manual is to be found.
> ...
>
> You can find it in the git repo. as pcb/doc/pcb.pdf,
> but you have to build it first.

:-)

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Stephan Boettcher wrote:
>
>> The way to promote gedasymbols and to fix the default library is to
>> remove the default library, except for a small set of very generic
>> symbols.
>
> ack. 
> This set of symbols should provide the ability to start working as is
> and generally be examples for complete working symbols. That is, they
> should contain footprint attributes. And when applicable simulation
> attributes, too. HOWTOs and manuals may refer to these items.

nack.  There is no way for a footprint attribute to be generic.  

These symbols shall exactly not be examples, and exactly not just work.

They shall be symbols that can be use as they are for any workflow, by
adding the required attributes after instantiation, or by editing a copy
in a project lib, i.e., the first easy steps in learning symbol editing.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
John Doty  writes:

> So, is it really that bad?

In the end, when you really need to look something up, giyf, it is all
there.  But terribly disorganised.  For most things that may need
looking up I am completely unaware that they even exist.

As I said eleswhere, the first thing I tend to read is some kind of
reference manual.  Those things are typically not very verbose and give
me a complete overview what the program, API, language, library can do
for me.  I could not point to such documents for gaf or PCB.

I still do not know where the pcb users manual is to be found. I found
it several times in the past after some googling, and after I read it, I
still have no idea what the possibilities are on the pcb actions command
line, because it appears to be incomplete both in coverage of the
actions as well as the parameters for the actions.

This is not a complaint, since I get along with what I know.  I may just
miss out on a lot of nice features that I do not know about.

What I did find early (and enjoyed a lot) was the file formats
documentation.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
Geoff Swan  writes:

>>
>> > > Examples
>> > > are the next to unusable default library of geda
>> >
>> > As has been discussed many times, this cannot be fixed, since there is no
>> > narrow, common use case for gEDA. 

It can be fixed, ...

> Actually I think gEDA is not too bad for components/symbols really. What the
> default library lacks, gedsymbols often has. With a little bit more
> promotion of gedasymbols I think people wouldn't have such an issue.

The way to promote gedasymbols and to fix the default library is to
remove the default library, except for a small set of very generic
symbols.

I do use some symbols from the defaul library, generic resistors,
capacitors, transistors, switches, but nothing else. Basically only the
very generic drawings.

The first thing a new user shall (have to) learn is making symbols, and
(for a pcb workflow) footprints, or (for a simulation workflow) models,
because, as John said, it cannot be done right for everybody, so we
shall not try, and if it were possible, nobody wants to to the work
anyway.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Stephan Boettcher wrote:
>
>> Why is there so much discussion here about the needs of potential new
>> users, instead of the needs of current, loving, existing users?  Let's
>> make the tools perfect for us (that includes discoverability and
>> documentation improvements), and not cater for not-yet-users.
>
> In my case, this is essentially the same. If students find geda more
> difficult and less attractive than eagle, I have a hard time to convince 
> them to use the right tool.

Why do you have this notion of _right tool_?  Let them use what they
want.  My colleagues use eagle.  I review their gerbers with gerbv. They
envy my hierachical schematics and scripting fu, but still, they are
happy.  All I say is: look if you want help from me with these things,
use gEAD, else, do it yourself.

>> In the end, the development caters the needs of whoever is doing the
>> development,
>
> and whose contributions get accepted. There is a heap of 45 patches for 
> pcb and 20 patches for geda rotting on launchpad. 

just what I said see below ...

>> That brings me to another point: I somehow feel a barrier of entry for
>> contributing code to gEDA/PCB, more than with other projects.  This is a
>> combination of a lot of little details which have been discussed before.
>
> ack. 
> It starts with a developer mailing list that is closed to mortal users but 
> discusses issues which affect said users. The wiki only features edit buttons
> on application. 

That are two of those little details, major ones.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-19 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Stephan Boettcher wrote:
>
>> Judging the
>> code by lack of comments without knowledge of the language is too.
>
> I referred to the lack of documentation, rather than lack of comments.
> The particular case I had in mind, is the interaction of gnetlist's 
> C front-end with the scheme back-ends. There seems to be no documentation 
> whatsoever, what data structure the front-end should use to communicate 
> with the back-end.

Ok, yes, that is a valid point...  the lack of documented APIs.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


gEDA-user: BUG: gaf hierarchy problems with old backup files

2011-05-18 Thread Stephan Boettcher

I have a collection of similar projects, each of which refer to a common
set of hierarchical sub-schematics, which were located in the directory
of the first project.  I needed to prepare a tarball for one of the
other projects, so I cleaned up the mess, and moved the symbols and
schematics of the common sub-circuits into the ../lib directory.  I
added lines to gafrc like this:

(component-library "../lib")
(component-library ".")
(source-library "../lib")
(source-library "."))

Everthing worked fine for the project that I had to tar up.  Then I
tried to open the project where the common subcircuits were previously
stored, and there I could not descend into the sub-schematic with H-d.
Worse, gsch2pcb did not find the source= schematics either and deleted
all the included components from the layout.

It took a while to figure out what was different between the project
where everything worked, and there it did not work: 

There where backup~ and #autosave# files left in the direcory for the
.sch file that were moved.  After removing the backup~ and #autosave#
files of the moved files everything works as expected.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-18 Thread Stephan Boettcher
Colin D Bennett  writes:

> First, let's be clear that popularity is no indication of usefulness or
> goodness of something.
>
> But, if a product is less widely-chosen, perhaps there is something
> that can be done to improve the learning curve for new users... 

Why is there so much discussion here about the needs of potential new
users, instead of the needs of current, loving, existing users?  Let's
make the tools perfect for us (that includes discoverability and
documentation improvements), and not cater for not-yet-users.  When we
love the tools, they will eventually also leran how to love them.  See: 

> e.g., I was frustrated with gEDA when I first started using it, and
> thought KiCAD looked easy to use and cool.  But I found that I didn't
> like the feel of KiCAD (Wxwidgets was probably part of the
> problem...), and eventually figured out the tricks needed to make the
> gEDA system "work".  Now I love gEDA and am really comfortable with
> it, 

Q.e.d.

> but I must say that it's difficult to learn.  Perhaps a comprehensive
> tutorial/manual that explains the usual PCB workflow would help.  I
> know there are lots of ways to use gEDA, but for new users, a basic
> and sensible standard workflow could be identified.

Yes.  Well, the results may be essentially the same, but still, the
emphasis must be the needs of those how already use the tools, else the
delepoment may run into dead ends.

In the end, the development caters the needs of whoever is doing the
development, and that is how it must be.  Those of us (like me) who just
argue their needs on this list, but do not write code, can just hope to
steer the development a little bit towards their needs.

That brings me to another point: I somehow feel a barrier of entry for
contributing code to gEDA/PCB, more than with other projects.  This is a
combination of a lot of little details which have been discussed before.
Maybe there is change in the right direction now, but I do not see any.

If it were easier, some new users may already have written a tutorial
based on their learning experience, or make the existing tutorials
easier to find.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Reinventing the wheel

2011-05-18 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Russell Shaw wrote:
>
>> I think Scheme could be made much more attractive in geda if
>> it was adequately explained in documentation or a tutorial.
>  
> +1
> I wouldn't mind to learn (a new language). But to learn a new language by 
> almost non-commented code is just too much of a barrier. 

Learning a programming language by examples is hazardous.  Judging the
code by lack of comments without knowledge of the language is too.

Comments that help those who do not know the language to understand the
code belong in tutorials, but not production code.  Well written code
should be understandable, with full knowlegde of the semantics of the
language, but not necessarily without that knowledge.  

I do think that most code needs comments, but mostly exactly not the
comments that are present in the code.

I once learned TeX by reading the source of LaTeX2.09 (before reading
the TeXbook).  Nowadays I start with the language reference manual, skip
the tutorial, and _then_ jump into example code.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


gEDA-user: physics Re: Reinventing the wheel

2011-05-16 Thread Stephan Boettcher
John Doty  writes:

> Because when the theory is all epicycles and no physics, there's no
> foundation upon which to stand.

Epicycles are no less physics than Keplers Laws.  They described the
observed ephemerides of planets just fine (for the time).  Kepler
replaced them by ellipses because he found the math turns out easier
that way, but there is no more physics in there than in Ptolemaeus math.
It is often the case that the wrong choice of reference frame makes the
math more complicated, but not necessarily wrong.  Currently we believe
that Einstein got the math right, at least as precise as we can measure.
Does that make the GRT more physics than Kelpers laws or epicycles?

You are right, though, epicycles are no good foundation to go any
further, neither is general relativity.  Kepler may fit just fine,
simple Euklidian geometry in a plane.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: An idea: rework design support...

2011-05-14 Thread Stephan Boettcher
Peter Clifton  writes:

> FWIW, I'd love to see PCB's enforce one "layer" per "layer" of the
> board, tagging objects if necessary to implement similar functionality
> to what we currently use "layers" and "layer groups" for.

One layer per physical layer would imply that element pins (pads) are
tagged shapes in this single layer too?

And negative shapes as well?  So each object (shape) on the layer needs
a stacking order tag (implying sublayers), or shall each negative shape
take precedence over positive shapes?

> Mechanical drawing overlays could still sensibly be called "layers",
> even if they are quite distinct from the physical representation of the
> PCB board.

I do not have a problem with the idea of single layer per physical
layer, as long as the end result is no more than a separation of the
plane in two subsets, all layers can be manipulated othogonally in the
same way (at least with a text editor), and there are not too many
assumtions about the semantics of the resulting layers.  The tags on the
objects that define the layers have several distinct purposes:

 - how does this object affect the plane (positive, negative, positive
   with clearance, stacking order, ...)

 - where did this object come from (routing, element pin, ...)

 - how may this object be modified (locked, grouped, ...)

 - verification (design rules, ...)

 - connectivity (vias, antenna, ...)

 - ...

 - user attributes

Some of these tags exist today, some are requested features, some depend
on what gets picked up from the long discussion we had a few months
back.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: pcb: Track routing strategies and tips

2011-05-11 Thread Stephan Boettcher

Colin D Bennett  writes:

> As a rather inexperienced PCB designer, I find that I have to throw
> away two or three layouts until I get one that is usable--and still
> not entirely satisfactory.  I always end up with such a mess of traces
> that I know I need better organization and a method to the madness.
> But I am a newb with little knowledge so I fall back on trial-and-error.
>
> Does anyone have any tips on how to plan a layout for easy and clean
> track routing?  In particular for 2-layer boards.

My schematics usually look almost like the layout.  The pins of the
symbols are placed like on the package.  People on this list argue that
the schematic should document the function, not the physical
implementation, but in my circuit the function is all inside the FPGA
and the processor, while the details of the layout in low noise mixed
signal or high-speed applications are very important, so I use the
schematic entry as a first opportunity to preview the place and route.

> One strategy that I have seen and recently tried is to use the top
> layer for all horizontal trace runs and the bottom layer for all
> vertical trace runs, or vice-versa.

This is a good for (slow) digital designs.  These typically benefit from
good functional schematics for review and documentation, so my physical
style of schematics is not appropriate.  OTOH, when it needs to fit on
two layers, and the logic is not too complicated, a little physical
planing on the schematic level may help later with the placement and
save a few backannotation cycles for swapped pins and slots.

> Do you ever use the pcb autorouter or do you always route by hand?

I never tried an autorouter.  But for that kind of Manhattan routing I
probably would try.

> Do you ever study other people's PCB designs to learn from them?  I
> think you could find both good and bad examples: things to emulate and
> things to avoid yourself.

Yes.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Where is pcb-20100929 for Win32 ?

2011-05-10 Thread Stephan Boettcher
Bob Paddock  writes:

> On Tue, May 10, 2011 at 2:18 AM, DJ Delorie  wrote:
>>
>>> If somebody requires GTK sources - let download them directly from
>>> http://gtk.org/ I used GTK etc. libs unmodified.
>>
>> Unfortunately, the GPL does not allow this.  If we're shipping GTK
>> dlls, we must offer the GTK sources ourselves.
>
> Why are individuals who are trying to help the project being held to a
> higher standard that the projects own download page?
> http://pcb.gpleda.org/ 's download link does not contain GTK sources,
> sources of compilers or sources for the Windows operating system.

Neither did I find any libgtk executables, that would require to provide
corresponding sources.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Out and In symbols in gschem & getting net names to come out in PCB

2011-05-03 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Colin D Bennett wrote:
>
>> +1000 for a patch to make I/O pin symbols visually clean without
>> requiring maintaining duplicate attributes as at present.
>
> While I am all in favor to get rid of the ":1", this is how I currently 
> deal with net names:
>
> * For nets that jump inside a sheet I attach an attribute to a short
> net line stub. I copy/paste this stub to where ever the net should go.
>
> * For nets that enter the sheet from a higher level of hierarchy, I use 
> in.sym and out.sym and set the refdes to the desired net name (without a 
> ":1" appendix).

dito, plus:

* For power/ground nets I create a symbol with a label and hidden net=
  attribute.

* For small projects I use the generic power symbol and live with the
  ugly :1 at the end of the netname, when the standard Vcc, Vdd, Vee, Vss,
  and GND symbols are not sufficient.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Can i use geda for electric indoor installation?

2011-04-30 Thread Stephan Boettcher
Jonas Stein  writes:

> i want to make a scheme like this:
>
> http://images.autodesk.com/emea_dach_main_germany/images/2g_acadelec_2012_auto_wire_number_1_large_1264x711.jpg
>
> Is geda the right tool for it?

Yes, I'd think so.  You will need to make a library of symbols.  Or is
there such a library for gschem already?

> Has anyone experience with that? Do you have some screenshots of
> nice schemes of house electric indoor installation?
> Additional information like wiretype or wire ID would be nice to have
> next to the line of the wire.

Sure, you can attach attributes to wires.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: How to identify a refdes' owner in gSchem

2011-04-29 Thread Stephan Boettcher
Mark Rages  writes:

> On Fri, Apr 29, 2011 at 3:03 PM, Rob Butts  wrote:
>>   Having never looked at a schematic this way I wouldn't know what to
>>   look for but from this excerpt can you tell if this is just a stray
>>   refdes that doesn't belong?  It is the only U9 found.
>
>
> Right, looks like stray text.   You can delete the line.
>
> How it got there is more interesting.  If you can reproduce it, please
> file a bug on the gschem bug tracker.

Typically, by selecting a refdes and hitting 'c'.  No bug required.

> Regards,Mark
> markrages@gmail

-- 
Stephan 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols

2011-04-15 Thread Stephan Boettcher
Gabriel Paubert  writes:

> A french or german keyboard will be different (I'm french,
> but I can't stand the layout of french keyboards).

I'm using us keyboards exclusively, in Germany.  I type a lot more
[]{}\| than äöüß.

I do not think that easy of typing should drive this decision too much.
When we need to type hierachy seprators a lot, then there is a problem
with the UI that needs fixing.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols

2011-04-12 Thread Stephan Boettcher
Peter Clifton  writes:

> On Tue, 2011-04-12 at 22:35 +0200, Krzysztof Kościuszkiewicz wrote:
>> On Mon, Apr 11, 2011 at 11:25:19PM +0100, Peter Clifton wrote:
>> 
>> > What about the cases where this is a mistake? The net= attribute was
>> > supposed to refer to some implicit power pin - not the device's one
>> > symbolic pin, but the user forgot the suffix.
>> 
>> The special case applies only to symbols with a single pin, so no such
>> error is possible here.
>
> What about symbols with one pin, and multiple net= attributes providing
> hidden "pins".

A non-graphical netlist format could be a gschem schematic file with a
generic symbol without any pins, with just a list of attributes.

Instead of special case, we could call it a default.  If a net=
attribute does not provide a pinnumber, it defaults to 1.  
Doesn't make is any better, but maybe feel better :-)

This default is actually a natural and useful default.  I'd welcome it.
Whenever I forgot to put a pinnumber on a net= attribute, this default
would have fixed the schematic, not hide an error.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: RFC using SVG with semantic markup as an EDA format

2011-04-11 Thread Stephan Boettcher
Peter Clifton  writes:

> On Mon, 2011-04-11 at 13:05 +0100, Andrew Seddon wrote:
>
>> 1. Be translated to common EDA formats with relatively simple algorithms
>> 2. Display nicely on standard SVG viewers
>> 3. Be easily to manipulate by tools working natively in the format
>> (this is probably implicit in 1 though)
>> 
>> Keen to hear why this idea sucks!
>
> It doesn't.
>
> Some challenges to be met though.
>
> If you make schematics == SVG files, you need to ensure that opening and
> saving from an SVG editor (e.g. Inkscape) won't break the data within.
>
> Gschem currently uses special primitives to mark connectivity - nets,
> pins, buses etc.. I'm not quite clear how that can be mapped to SVG in a
> way which doesn't loose that information when edited outside of the EDA
> tool.

Does SVG/Inkscape support layers? It sure does. I recently looked at an
svg export from gerbv, and I found it pretty useless.  I found one
object inside, and when I ungrouped that object I found all the little
pieces, but not grouped into layers.  And no transparency.

A schematic could require nets and pins to be in special layers.  When
Inkscape messes with the file, as long as the layers are preseved the
connectivity should survive.  All non-schematic layers are graphics.

So it should be easy to map the semantics of gschem to an svg subset,
allow gschem to export to such a format.  On open/import, the schematic
is extracted from those layers/groups that have a meaning, all the rest
is preserved as graphics, maybe with limited edit sorrut, like move and
delete.

If this shall become the primary format, I'd first insist on really good
native scripting support, since external schematics scripting on svg is
no fun.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: default pcb stackup change?

2011-04-10 Thread Stephan Boettcher
Peter Clifton  writes:

> On Sun, 2011-04-10 at 19:42 -0400, DJ Delorie wrote:
>> I'm pondering a minor change in pcb's defaults to give us a more
>> useful default stackup.  How's this?
>> 
>>   LAYERNAME (1, "top"),
>>   LAYERNAME (2, "ground"),
>>   LAYERNAME (3, "signal2"),
>>   LAYERNAME (4, "signal3"),
>>   LAYERNAME (5, "power"),
>>   LAYERNAME (6, "bottom"),
>>   LAYERNAME (7, "outline"),
>>   LAYERNAME (8, "spare"),
>
> I'm very keen to see this change.
>
> The PCB+GL renderer (for example), needs layers (actually layer group
> numbers) in the correct physical order to be able to figure out how to
> render 3D views. Our current default stack is totally useless for that.

I'd very much like to not have any exporters/renderers requiring the
layers to be in physical order, since I tend to move the final order
around a lot.  My layer order is defined in the README that goes to the
board house, and little text numbers in the layers.

A layer attribute that tells Ben-mode and PCB+GL how to render the stack
may be the way to go.  

Is it really the layer order, or the group order that PCB+GL or Ben-mode
uses?

-- 
Stephan 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Split ground planes and zero ohm jumpers

2011-04-09 Thread Stephan Boettcher
DJ Delorie  writes:

>> Why not a description for what it is, instead of fending off some 
>> program. Like "square,use=xx", where xx could be "fuse", "antenna",
>> etc.
>
> For starters, flags are one-bit values.
>
> Also, if you allow the user to put in a wide range of values, then the
> routines in pcb need to understand what those wide range of values
> *means* so they can do the right thing.

Exactly.  The attributes and flags shall have meaning to the program,
without overloading them with higher-level semantics.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Split ground planes and zero ohm jumpers

2011-04-08 Thread Stephan Boettcher
rickman  writes:

> On 4/7/2011 1:13 PM, Stephan Boettcher wrote:
>> rickman  writes:
>>
>>> I have to say I am philosophically opposed to any feature that allows
>>> a design to pass DRC when the layout differs from the schematic.
>> Just to get the terminology right:
>>
>> DRC has no business to care about the schematics at all.  There shall be
>> a tool to check if the layout implements the schematics netlist, but
>> that is a different issue.
>>
>> PCB implements this distiction properly.  DRC checks consider coper
>> structures as layed out when evaluating the rules, without regard to the
>> netlist.
>>
>> The Rat's-nest (O-key) ignores DRC rules when checking connectivity.
>
>  Ok, if you want to be pedantic the net list is not the schematic, but
> if the netlist differs from the schematic, then you have another
> problem.

My point is, what I (we?) call DRC in the PCB program context is the
Menu item Connects -> Design_Rule_Checker. This action does not check if
two nets are connected or not.  It just checks if the connection has the
proper copper width.  It does not care which copper belongs to which
net, or if all pins on a net are really connected.

And, yes, that may be pedantic, but I believe in this context we should
get the teminology right in our discussions.  This is independent of the
issues you are arguing, though.

> DRC is a part of my design process which includes a verification that
> the layout matches the net list.  In fact, my number 1 "design rule"
> to be checked is that  they match.  What button I push to get the tool
> to do my required design rule checking is irrelevant.  It is just a
> tool and does not define my process.
>
> So my point is that adding an attribute to any copper to tell the tool
> to ignore the connectivity violates my idea of design rule checking.
>
> Rick

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Power users us normal users, a conflict?

2011-04-08 Thread Stephan Boettcher
Rubén Gómez Antolí  writes:

> Hi again:
>
> El 08/04/11 01:30, Peter Clifton escribió:
>> On Thu, 2011-04-07 at 16:00 -0600, John Doty wrote:
>>> On Apr 7, 2011, at 3:06 PM, Rubén Gómez Antolí wrote:

 You are right but, what about the users?
>>>
>>> I *am* a user.
>
> I'm too.

Both of you now pushed some users aside somehow, one calling the GUI
users _consumers_, the other calling CLI users _power users_.

I do not see a conflict between GUI and make, the first ist a good way
to make features of the second discoverable.  John wants to make sure
that the make-power is not compromised for the sake of the integrated
GUI.  But that should not discourage development in that area.

>>> gEDA is software that caters to the needs of users. But
>>> it's not for passive *consumers* of software. There are plenty of
>>> other tools for them. I sincerely hope that gEDA's power and
>>> productivity are never abridged to make it more palatable to
>>> consumers.
>
> John, I'm not attack the powerful of gEDA, I'm really agree with the
> multiple pieces of powerful software that compounds it, and I love too
> the posibilty of use makefiles, but...
>
> I tell you a short history: I have a friend, he is really good in
> electronics and yes, he uses other comercial apps (and he's testing
> Qucs). I try to come him with us, but, stop, if I tell him to need to
> learn Bash, Makefiles, Gnuplot and other "esotheric" languages... ¡oh,
> wait! He only wants to do some electronics work.

He cannot be really good, when we stays in the GUI forever. At least not
efficiently.  An expert in any field needs to use learn the tools of his
trade, or hire personel that does.

None of the languages you quoted are esotheric.  Users of commercial
tools learn more esotheric scripting languages to achieve what open
tools can partly achieve with these non-esotheric tools.  These
non-esotheric tools are useful for all kinds of productivity boost
besides eda.

> Who is wrong? Possibly anyone, then, what about do a easy curve of
> learning? Why we have to lost a potentially users which should
> contribute in some way to gEDA? For a leak of a good interface* to do
> in a easy way the work? I say no. Try to tell him about doing some
> makefiles and, definitively all lost, we and they.

gEDA and especially PCB suffer a lot from lack of discoverability.
There a powerful features in PCB that are inaccessible from the GUI, and
those features that are accessible do not provide hints how to access
them from scripts.  And AFAIK there is still no complete list of all
actions available.

I do not believe that a GUI frontend to gaf, pcb, spice is the way to
go.  That prevents dicoverability.  My productivity with proprietary
tools always got a boost as soon as I learned how to call the components
individually.  This was not always easy to discover.

gschem modes, like emacs modes may be a good way forward.  If you target
simulation, provide a menu that highlights spice attributes, and spice
components, with descriptive names.  Just make sure you can switch to
different modes on the same schematic, to use what is left of
multi-target capabilities in gschem.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Split ground planes and zero ohm jumpers

2011-04-07 Thread Stephan Boettcher
John Griessen  writes:

> On 04/07/2011 04:52 AM, Stephan Boettcher wrote:
>> PCB layer groups may be used here.  Put the short on an extra layer, in
>> an extra group.  At checkout time, you can assign the extra layer to the
>> group representing the copper layer that needs shorting.  This is
>> probably a single char in the PCB file header, and can be done with a
>> simple sed script.
>
> I like that idea -- at least until someone figures how to have a starpoint
> symbol and footprint that keeps DRC checking of separate ground planes while
> still having a short there for fabbing purposes.
>
> I'm thinking of two scripts external to pcb, for use with make.  While editing
> a pcb board, I would run DRC and effectively have a non conductive piece
> of trace between separately named ground planes.  When I run make faboutput,
> one script is run to change the non conductive piece
> of trace to copper on a layer, then output RS274-X, the run the other script
> to change the piece of copper on a layer to a non conductive piece
> of trace.
>
> We don't have the concept of non-conductive built into pcb now though,
> so some kind of "ignore for DRC purposes" might do.
>
> There's still a problem with that method though... It won't check for
> proper clearances of the starpoint blob of copper to other copper if it
> is handled by an "ignore for DRC purposes" attribute.

As soon as we have the option to define arbitary layer types, we also
need to be able to define arbitrary DRC rules.  The star-point may be a
footprint with a structure on some non-conductive "shorts" layer, which
will need to be accompanied by a set of design rules in the technology
specs.  The fact that the non-conductive "shorts" layer is implemented
in conductive copper by merging the layer with the bottom copper is
irrelevant, since for netlist purposes it is non-conductive, just like a
"resistor" layer.  Part of the design-rule check is to be perfomed
manually, you'll always need to check your footprints in your library.


-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Split ground planes and zero ohm jumpers

2011-04-07 Thread Stephan Boettcher
rickman  writes:

> I have to say I am philosophically opposed to any feature that allows
> a design to pass DRC when the layout differs from the schematic.  

Just to get the terminology right:

DRC has no business to care about the schematics at all.  There shall be
a tool to check if the layout implements the schematics netlist, but
that is a different issue.

PCB implements this distiction properly.  DRC checks consider coper
structures as layed out when evaluating the rules, without regard to the
netlist.

The Rat's-nest (O-key) ignores DRC rules when checking connectivity.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Split ground planes and zero ohm jumpers

2011-04-07 Thread Stephan Boettcher
John Griessen  writes:

> On 04/06/2011 05:16 PM, Russell Dill wrote:
>> The use case I'm talking about, you have two nets, say GND and AGND1
>> which are two planes that are connected at a single point. Connecting
>> a component on the AGND1 side is different that connecting a component
>> on the GND side.
>
> Yes, Levente's way of handling that after the fact is practical and
> what I like to do, since then you keep all your DRC's working against
> error, and have one more step to do after DRC complete.  Perhaps that
> method could be scripted with a makefile?  Can commands from a script
> make a layer invisible and not part of DRCs?  If so, then the starpoint
> connecting copper could be on a special layer for that purpose alone,
> and merged in by using visibility or not.

PCB layer groups may be used here.  Put the short on an extra layer, in
an extra group.  At checkout time, you can assign the extra layer to the
group representing the copper layer that needs shorting.  This is
probably a single char in the PCB file header, and can be done with a
simple sed script.


-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Footprint/symbol generating scripts + question

2011-04-06 Thread Stephan Boettcher
Richard Rasker  writes:

> One last question: the project I'm working on has several schematic
> pages, with several nets spanning multiple pages. For me, this is the
> first project of this size, and I wondered about one thing: Are  there
> special symbols to indicate nets connected to other schematic pages?
> In the reference design on which this project is based (probably made in
> OrCAD), those nets have double arrows, but I can't find anything similar
> in gschem. So now I have quite a few nets ending in little red squares,
> giving the impression that they're open-ended.
> The actual connection is there, of course, so it's more of a cosmetic
> issue, but I have the feeling that this is not how it's supposed to
> look.

You could draw a bus, and connect the nets to a bus.  The bus could be
labeled with the sheet the nets connect to.  All this is just cosmetics,
though.

-- 
Stephan 



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: zview/ngscope

2011-04-06 Thread Stephan Boettcher

Kai-Martin Knaak  writes:

> Specifically, the suite misses a way for fast turnaround of schematic
> modification, simulation and display.

  make

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: US Distributor for Balloon Board

2011-04-02 Thread Stephan Boettcher
Dave McGuire  writes:

> On 3/27/11 6:05 AM, Stephan Boettcher wrote:
>> I am designing a lot of boards with an LPC2141 ARM7, Altera 3c25, USB
>> client, RS232, SPI, uSD.  No ram, no Linux, just the builtin flash and
>> RAM of the ARM and FPGA, and 1MByte SPI flash. The frontend is fitted
>> with a variable number of ADCs of various types.
>>
>> It is optimized for precision analog measurements.  The FPGA and the ARM
>> live on differnt ground planes, with LVDS-IO between, to isolate the
>> noisy digital world (computer) from the frontend.  This board is
>> sandwiched between a power regulator board and a preamplifier board.
>> The inputs to the preamps are usially quoted in pA or fC, that is just a
>> few electrons.
>>
>> I don't think this is what you asked for, but, if that comes close to
>> what you need, and are ready to do your board yourself, I will share my
>> design to work from.  Most work is in the software/firmware.
>
>   That sounds like a very powerful platform for general metrology
> applications.  I'd love to get my hands on one of those boards.  If
> you decide to publish the info or sell any boards, please let me know!

Well, I design a new board for every problem, because each problem
requires it's special frontend, like

 ==  18 * AD7276, 3 MSPS, 12bit, each with a shaper AD8005
 ==  2 * AD9251, 4 channels, 80MSPS, 14 bit, with AD8138 preamps.
 ==  9 * AD7690, 9 channels, 400 kSPS, 18 bit, with AD8131 preamps.
 ==  1 * AD9649, and LVDS IO, to test variuos ASICS.
 ==  0 * ADC, but an SRAM, to test/emulate interfaces with downstream systems.

The backend, ARM, FPGA is always the same, as is the ARM firmware, and a
good part of the FPGA code.

So, no boards, but I may put the design online when I find the time to
package it.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: US Distributor for Balloon Board

2011-03-27 Thread Stephan Boettcher

Patrick Doyle  writes:

> Hi Folks,
> I'm looking for a US distributor for a Balloon Board
> (http://www.balloonboard.org/) or it's equivalent -- perhaps one of
> you may have designed and sell your own equivalent.  Basically, I'm
> looking for a standalone board with a processor (with it's associated
> flash & SDRAM) and an FPGA.  I'm not terribly picky about the FPGA --
> any reasonable Xilinx or Altera device should suffice.
>
> Does anybody on this list have any recommendations?

What do you want to do?  

I am designing a lot of boards with an LPC2141 ARM7, Altera 3c25, USB
client, RS232, SPI, uSD.  No ram, no Linux, just the builtin flash and
RAM of the ARM and FPGA, and 1MByte SPI flash. The frontend is fitted
with a variable number of ADCs of various types.

It is optimized for precision analog measurements.  The FPGA and the ARM
live on differnt ground planes, with LVDS-IO between, to isolate the
noisy digital world (computer) from the frontend.  This board is
sandwiched between a power regulator board and a preamplifier board.
The inputs to the preamps are usially quoted in pA or fC, that is just a
few electrons.

I don't think this is what you asked for, but, if that comes close to
what you need, and are ready to do your board yourself, I will share my
design to work from.  Most work is in the software/firmware.

> I would prefer to buy from a gEDA supporter, and it will be
> logistically easier if I can purchase from someplace in the US.

I cannot help with that.

> Thanks for any pointers.
>
> --wpd
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

-- 
Stephan Böttcher FAX: +49-431-85660
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 question

2011-03-22 Thread Stephan Boettcher
Rob Butts  writes:

> Yes, that's what I meant.  I should have thought about it better before I
> asked.  So if I say in the project file 'output-name "new-name"'  It will
> know to check the new-name.pcb file to see what components are missing and
> will give me a knew file with the layout data to load into the layout
> buffer?
>
> Not trying to be wise but is classifying a question properly critical here?

It helps, to understand the answer :-)

I do recommend a vcs (subversion, git) for pcb projects.  No need to
rename layout files, then.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Problems with a TDSON8 footprint

2011-03-20 Thread Stephan Boettcher
Rob Butts  writes:

> I am using an Infineon power mosfet in a voltage converter.  I'm attaching
> the datasheet.  Pins 5 thru 8 get tied together and the actual footprint has
> a big pad that ties them together.  I'm attaching the footprint that I made
> also.  I'm having trouble with PCB making the big pad orange when I optimize
> rats.  The big pad lays across each pad for each pin.

Your symbol has 5 or 8 pins?  The one big pad has what pin number?

I'd do a footprint/symbol with 8 pins, connect them on the schematic,
and draw poly across the connected pins on the layout.  I don't know if
the poly clearance can be reduced to zero, of if you need to draw
thermals to the poly, or a fat line, depending what you need.

> How can I do this?  Suggestions?  Or, since only the big pad that lays
> across the pads for each pin turns orange, should I just ignore this?
>
> Thanks
>
>
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

-- 
Stephan Böttcher FAX: +49-431-85660
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: General Layers questions

2011-03-19 Thread Stephan Boettcher
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 that are fabricating parts with
> 3-D "printers". I've been wondering when the technology will reach the
> point where the printing could include conductors, with components
> placed during the build-up, and then buried.
>
> But I suppose describing this is beyond what we can conceptualize here
> at this time. Planes are difficult enough.

As long as this 3D structure is built mainy manhattan style, with
horizontal conductive layers and vias, all conductive layers become
component layers, an element must define keepout zones on those layers
that it's housing penetrates.  It's pads are on layers that correspond
to the z-positions of it's pins.  Before you start making your footprint
library you need to decide on the thickness and distance between the
conductive layers.  The kind of tool we were discussion here could do
that very nicely.  A GUI plugin needs to be written, that allows to move
the 3delements up and down in the layer stack. Maybe even rotate off
plane, but that is initially best done by hand as a separate
3dfootprint.

One more argument to implement holes as shapes on a hole layers.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-19 Thread Stephan Boettcher
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 possible.
>> 
>> I do not understand that argument.
>
> 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.
>
> 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.

Hmm.  I think that is the old trap of overloading.  When you say that a
layer type defines what you can do with it, then this one type attribute
becomes messily overloaded.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-19 Thread Stephan Boettcher
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/selectable,
> and a plugin can register callbacks to be called when such an endpoint
> is manipulated.  The plugin would check to see if a "diffpair" attribute
> is set, and decline the callback if not, so that the "magic_poly" plugin
> has a chance.

The "morphable" composits can also support lines with soldermask opening
and paste.  Maybe we call the "wires".  These composits allow to
manipulate endpoints of contained objects, where a plugin makes sure
that the stack of features representing the "wires" move together.

-- 
Stephan Böttcher FAX: +49-431-85660
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: General Layers questions

2011-03-19 Thread Stephan Boettcher
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, 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'.

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 appreciate that you asked for out opinion!

> So again. Coments are welcome, the discussion was a bit fast so I may
> have missed something important again.

I think it is worth to read the whole thing once again. I will send
myself a digest message of the whole thread so that it is easier to
read, and I may try to identify the core arguments.

> Thank you all for participating,

Thank you!

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 care about the
> outlines?

currently it does, and I need that functionality.  When I import a new
batch of components from gsch2pcb, they get disperses in a big area
outside the outline, because inside there is half the layout already
done.

In the end, it's a DRC problem, so yes, the DRC may look for a layer
with an outline attributes.  That layer shall have a separate attribute
for the placement wizard plugin, although the message is almost the
same.


-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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
> exporter doesn't need that high-level access, then the default action
> breaks it down into shapes and exports them individually.
>
> The gerber exporter needs to be given a whole "pin" because it has a
> command that means "put pin here, with this aperture and thermal
> settings".  If you wait until the core descends to "circle, arc,
> line", it's too late to look at the attributes and figure out what's
> happening.  CAM tools know about this, and can adjust thermals and
> pins as needed, but in PCB's case they can't do it because we break
> pins down into raw shapes.

I do not understand this.  The gerber exporter exports each layer
separately, no?  On some layer it finds a circle with a thermal
attribute surounded by a polygon.  What else does in need?

>> > and containing other layers as sub-layouts.  I have never disagreed
>> > with this!
>> 
>> Oh.  My understanding of composites is different.  I assume a composite
>> contains shapes that go on a global set of layers.
>
> This is part of the communication problem we're having, yes ;-)
>
> Consider these:
>
> * A footprint is a global resource, but an instance of a footprint (an
>   element) must be mapped to the physical layout.  When do you manage
>   the footprint as an element (indivisible) and when do you access its
>   parts (changing pad size)?

Is the footprint still part of the layout?  Wouldn't it's genereic
layers (top,inner,bottom) be mapped to the layout layers
(oben,innen1,innen2,unten) when imported?

> * A sub-circuit that's replicated N times on a board.

composites instances are objects inside other composites, next to
shapes.  You can do most operations to composites, that you do to shapes
(move, rotate, mirror, delete, ...).  Vias and elements are special in
the memory representation, as there are methods, or callback hooks that
allow access to some internals without explicitly decending into the
composit.  It should be possible to flag any composit as Element or vise
versa, to turn on and off this special access.  If you exlicitly decend
into an element, you can move its pins and pads.  But pads size, text
positions e.t.c. are still directly accessible for elements.  Maybe it
is not even necessary to have any special treatment and treat all
composites the same.

> * A flex cable that has 4 layers at each end, but only 2 layers in the
>   middle.  The extra layers on the end are on opposite sides of the
>   cable.

You want to describe the rigid ends as outlines of a composite?  That
attaches high-level semantics to a low level concept in an inapropriate
way.

Here you need outline layers with attributes that tell the autorouters
not to cross the lines on certain layers.

> * buried vias are limited to certain pairs of layers because of the
> way the fab is assembling the board.

A DRC problem.  With hole layers, the GUI tool to add/manipulate these
hole layers can provide a view on the layer stack that represents the
stacking and drilling order, just like you once proposed as an
underlying data structure.  The tool would refuse to configure holes
layers that cannot be drilled, unless you say "please".

> * 400 instances of a standard via, but the user needs to modify the
>   pad stack on just one of them, and only for one layer.

Vias may be COW by default, like they are now.  But you can decend in
non-copy mode into the composite, so they all change.  That composit is
also the master copy in the Via menu, so that future vias of that type
are affected by the edit.  When you edit the via definition in the Via
menu, you may need to answer a question if you want all existing
instances to change, of only new vias.

> 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.  What
> we call them is not important.
>
>> Well, yes, it can, except that a via is not sufficiently special to
>> justify the distiction.  What would we have in a composite, the layout
>> being the top-level composite?
>> 
>>   Vias
>>   Elements
>>   Composits that are not Vias or Elements
>>   Lines
>>   Shapes outside of composits that are not Lines
>
> Consider: you can move a via, but for lines, you can move either the
> line or its endpoints.  For a polygon you can move its corners.  Ah,
> but a via can include polygons and lines - but when it's a via, you
> *don't* move their endpoints and corners, unless you specifically edit
> the via.  A pin is just like a via, except you *don't* move it - you
> move the element it's in.

shapes (lines and polys) in the current composite can be editied as
before, moved, endpoints moved, size, 

Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 spot.

I am the one who did flex cables with pcb, with six copper layes, three
different outlines, four surface layers.  It is going to fly to Mars
later this year.

  http://www.ieap.uni-kiel.de/et/people/stephan/msl/eda/TFlex/TFlex.pdf
  http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/TFlex/index.html

To support such a beast in PCB you need multiple pairs of surface
layers.  Elements with pads on explicit layers is what fills this role,
so that the pads of the flex edge connectors get connected to their
(inner) copper layers.

The outlines are just any graphical layers that can be exported without
vias and pins.  But the boardhouse had no problems ignoring the holes in
the outline layers.


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.

-- 
Stephan 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 compromising the final goals.
>
> As general as neccessary, but not as general as *possible*.

But we cannot know what is necessary.

>> On top of that is a memory representation, that introduces the concepts
>> of elements, vias, surface-layers (layer sets: copper, mask, silk,
>> courtyard, keepout), connectivity,   
>
> This is the part I wish we were discussing.

As John said, bottom up works better in the long term :-)

>> It provides basic operations on these concepts.  The implementation of
>> these concepts builds on the objects of the storage data layers.  It
>> must not be an error if a via has two holes, a polygon shaped hole or
>> silk in it.  DRC may flag such things, but it must not be an error.
>
> There must be *some* limits, however, or the tools cannot be written.
> Defining a "hole" in a silk layer is nonsensical, if you wish to
> support it, we cannot define what the tools would do with it.

Why not?  The tool can move it arount and not much else, like with all
objects on a sliklayer.

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 needs to know until checkout.  DRC checks if all
shapes are circles, unless the shape has a DRC overide attribute.

There would be one hole layer for each drill pattern, i.e., one, unless
there are partial vias.  John's insulating layers will be mentioned in
the attributes, so they get drilled too.

A via with variable hole size for different layers must be built as a
composit with multiple holes on as many hole layers. Inefficient but
appropriate for such an obscure case.

>> The attributes that this memory representation and it methods
>> understand shall be in namespace "pcb:" and unknown attributes in
>> that namespace shall emit warnings.
>
> You assume that attributes are the way to organize groups of things.
> Why?

So that everything is just shapes on layers. Very simple, very powerful.

>> Higher level parts of the concepts "element", "via", "surface layer"
>> may be implemented in plugins.
>
> How does a move tool plugin interact with an element plugin, then?

The memory core representation provides methods to move, rotate, mirror
shapes and composits.  (Element composits may have an attribute that
forbids mirroring.)  To bring an element to the other side od the board
is method of the Element plugin, relying on attributes of the relevant
layers how they map to the other side.

I don't think that the concept of vias and elements shall be fully
implemented in plugins, for efficiency, and since most other plugings
may need refer to these concepts.  At least some callback hooks need to
be specific to elements or vias, that a plugin can register. So that a
plugin can intercept composite methods (e.g., move) for elements or
vias.


-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 that the tool's limits are defined by necessity and
> not by the limited imagination of any particular group of developers.

Nothing prevents that you define insulator layers, and include shapes on
these layers in your vias and elements.  But for simple layout work its
not needed.  I did not miss them, yet.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 center.
>
> What I suggested before is that each composite itself have "outline"
> type layers, which contains any holes, cutouts, or physical outline
> shapes that need to be applied to all of the layers therein.

composit instance overlap with other composits and shapes.

I do not like the concept of composit outlines.  Does each layer have
its outline?  How does it do partial vias?

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 performance.

Sorry, yes, that's what I meant.  But it's not in the disk file.

>> Exporters can only export what they know about.  All layers can be
>> turned into gerbers.
>
> Except gerbers have special cases for thermals and pads, for example.
> If you use the special cases, other CAM tools empower their users to
> do more things (like auto-generate paste stencils when you forget the
> paste mask, which does NOT work with pcb's gerbers).  But for the
> exporters to offer these special cases, they need to know more about
> the data they're given than just "draw circle here".

So there need to be attributes on shapes.

>> At the bottom, a layout is a set of layers with attributes,
>> containing shapes, maybe with attributes.
>
> and containing other layers as sub-layouts.  I have never disagreed
> with this!

Oh.  My understanding of composites is different.  I assume a composite
contains shapes that go on a global set of layers.

> What I disagree with is using this "at the bottom" information to
> re-produce the semantic information inherent in a "pcb layout".  I see
> no reason why there can't be a semantic heierarchy to the data, so at
> a high level we have a collection of "all vias" that's a child of
> "this layout", so that the tools can find them easier and deal with
> them as a group.

Well, yes, it can, except that a via is not sufficiently special to
justify the distiction.  What would we have in a composite, the layout
being the top-level composite?

  Vias
  Elements
  Composits that are not Vias or Elements
  Lines
  Shapes outside of composits that are not Lines

How the layers fit in here depends if they are global or local to a
composit.  I did not think about non-global layers yet.

The set of global layers is the union of layers referenced in the
hierachy of composits.  When an how to map generic element layers to
layout layers is another good question.  And how to treat conflicting
attributes of layers.  I'd flag those as errors.  Or define for each
attribute lookup if the precedence goes from outside to inside, or from
inside to outside starting at some shape.

Global layers can be mapped at load time.  Local layers inside composits
must be mapped a runtime, don't they?



>> The semantics of those attributes is what encapsulates the builtin
>> knowledge how to make PCBs, and the tool must fully exploit that
>> knowledge when presenting a layout to the user.
>
> Forcing tools to "fully exploit" data at too low a level makes it very
> difficult to create such tools in the first place.  The move tool
> needs to know the difference between an element, a via, and a trace,
> so it can function properly.  We need to consider these types of
> issues when designing the internal data structures, or it will be so
> difficult to write the software that it just won't get done.



-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 how to do that.
>
> 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 goals.

I'd propose a very basic, very general storage data representation.
Just layers, shapes, and arbitray levels of composites, the layout
implicitly being the top level composit. Everything with arbitrary
attributes.

On top of that is a memory representation, that introduces the concepts
of elements, vias, surface-layers (layer sets: copper, mask, silk,
courtyard, keepout), connectivity,   

It provides basic operations on these concepts.  The implementation of
these concepts builds on the objects of the storage data layers.  It
must not be an error if a via has two holes, a polygon shaped hole or
silk in it.  DRC may flag such things, but it must not be an error.
The attributes that this memory representation and it methods understand
shall be in namespace "pcb:" and unknown attributes in that namespace
shall emit warnings.

The plugins define their own attributes.  Attributes shall not be
overloaded.  If a plugin operates on attributes of the memory
representation, it shall do that via methods of that representation, if
possible.  

Higher level parts of the concepts "element", "via", "surface layer"
may be implemented in plugins.




I cannot keep up, there are 15 new messages in my inbox, lets see what
what new arguments come up :-)

I cannot make up my mind if I should continue to argue for hole layers,
or if holes shall be shapes with hole attribute on layers.

> The fact that the *user* can write them *also* is a side-effect :-)
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

-- 
Stephan Böttcher FAX: +49-431-85660
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: General Layers questions

2011-03-18 Thread Stephan Boettcher

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.

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
anything else.  What kind of high-performance processing is needed in
addition to that?  Well, when you figure out that there is something
else, it's a good justification to add anothe type.

At the storage data level they are still all layers with attributes.
When loading the layout, they are collected into separate lists, or get
a binary attribute attached, by enumerating known values of the
attribute "pcb:type="

> My original design had an enumerated type for each drawing layer, that
> was one of (for example) "copper, silk, soldermask, paste, outline,
> other" with flags for "normal, inverted" and an assignment to a
> physical layer (1..N).
>
> That way, when you're doing something compute-intensive like
> connectivity checks for "auto-enforce drc clearance" you aren't doing
> a bazillion string compares.
>
> Actions that are performed less often, like mapping a footprint to an
> element, can use a more open-ended string-attribute with more complex
> rules.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 fab-specific anyway.  Maybe DRC should be on
>> the other side of the CAM job?  I.e. make DRC an exporter, so it gets
>> the layer mappings you want, and can apply rules based on the *mapped*
>> layers, not the *design* layers?
>> 
>> That also lets us code the DRC rules in the CAM job file, so different
>> "jobs" check different rule sets.
>
> I am sorry, but I don't think this is a good idea.
> The DRC should work on the hierarchy. While the exporters will receive
> somewhat 'flattened' stackup.

Absolutely not. The DRC shall check the final flat result.  And yes, the
DRC should be a separate tool examining the CAM output.

OTOH, some DRC functionality inside the layout tool is at least nice to
have, if not required, for doing life checks when editing.  These will
probably never reach the coverage that a final checkout DRC should
provide.  But that is a problem to write such a tool in the first place.

> And I want represent the resulting layer mapping somewhat in the
> stackup, so the exporters will receive how are the layer ordered.
> This should brink some code from the exporters to the core => less code.

This kind of information shall be in the layer attributes.  Ben-mode
image export will need to know that.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 you wouldn't want the "move" option on a trace to not be able to
> move either the endpoints or the whole trace.  Regardless of how the
> underlying data is stored, the tools need to organize the data in a
> way that helps them serve the user, and be aware of various levels of
> semantics that need to be applied to what would otherwise be
> meaningless groups of composites.
>
> For example:
>
> 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 layer.
>
> Data layer - a via is a collection of N shapes on M conducting layers,
> with a collection of one or more shapes penetrating the insulators
> between those layers.

Except, I see no need to specify any insulating layers here.  The data
does not care.  It's the exporter that may care.  If, for some
technology, the data does care, there will be a very special layer of
type "other" to make it care.

> I feel that the data layer is easiest to implement, but it seems to be
> what we're arguing about the most.  

Yes.  because ...

> I say we should ignore that problem for now, until we have a better
> understanding of what we want at the other two layers.  The tool layer
> is going to be the hardest to design, 

... I think the tool we have is pretty good already. Very good.  Thanks!

> because that's where we blend flexibility with ease of use.  Picking
> the right tool-level design will give us both flexibility and ease of
> use ("use" includes both the user and the plugin writer).

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.

It's good to know that is is possible when a real need arises, but that
will not be often the case.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 wrong place to be assigning *meaning* to the data.
> That is still in the core.  The fact that some composites are "vias"
> is something intrinsic to the pcb design, independent of what color
> you make it on the screen, and independend of how vias are implemented
> at the lowest internal levels.

Physical meaning is "here is a hole in the board", "here is a copper
circle on layer 1". Those meanings appear in elements, vias, whatever.
That a hole with concentric pads is a via has no meaning except for how
those came to be.  DRC does not care about vias.  It cares about hole
diameters and copper annulus. Connectivity also does not care about
vias.  Only the human in front of the screen cares about vias.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 with attribute "type=via".  The GUI probably
maintains an extra list of those, as well as a list of elements, for
performance.

The autorouter is told to route on all enable conductive layers, and
choose from a set of selected vias to go between those layers.

Exporters can only export what they know about.  All layers can be
turned into gerbers.  More complicated exports may need a technology
description, like an advanced concept of the current layer groups. An
exporter shall define a set of attibutes it expects to find on layers
and objects to do its special deeds, and those attribute shall not be
overloaded attributes that the core tool needs.

> PCB has a lot of tools that know a lot about how PCBs are designed.
> These tools are essential to making PCB a viable layout editor.  The
> input we need at this stage is from people who design a lot of PCBs,
> so we know what kinds of abstractions make sense to expose and what
> kinds need to be hidden behind other data structures.

At the bottom, a layout is a set of layers with attributes, containing
shapes, maybe with attributes.

The semantics of those attributes is what encapsulates the builtin
knowledge how to make PCBs, and the tool must fully exploit that
knowledge when presenting a layout to the user.

When we morph the current pcb towards such an abstract layer concept,
the user shall not see the difference unless she activates the new
features that become available with these concepts.

> Maybe to the rendering engines they all work the same, but saying
> "they all work the same" *in general* just isn't applicable here.
> They don't.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 to be totally blind to the theory that you can have
> inflexible wired-in behavior *and* options for flexibility through
> alternate mechanisms.  We need both - they are not mutually exclusive.
> We need a tool that's easy to learn and use *and* has options for
> power user.  Your maniacal lobbying for "factoring" and "abstraction"
> would leave us with a tool that nobody would *want* to use.

We are talking about different thinks, I guess.  The tool shall be very
focussed on traces, elements, vias.  But the engine at the bottom shall
be flexible.  The user shall see this flexibility deep down in the
advanded options section of the via editor, where he will be told to go
when he asks for square via holes in this mailing list.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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
>> 'tagged' layer.
>>
>> That example is probably silly, but someone would probably come up with
>> something more realistic, but still giving me nightmares.
>>
>
> But what if I want a silk layer to just be a copy of a copper layer?
> That may be just as silly, but I'm sure someone could come up with a
> use for it.  Why would such a layer cause nightmares?  When the code
> is worried about connectivity etc., it sees this layer is tagged as
> conductive and includes it in whatever its doing, ignoring the fact
> that it is also silk.  When the code is putting out the silkscreen, it
> notices this layer is tagged as silk and puts it out, ignoring that it
> is also a conductive layer.

You can always tell the board house to use copper minus soldermask as
silk.

>
> Jared

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 different attributes.  The one has attributes to
>> >> tell DRC to flag overlapping components, the other has attributes to
>> >> tell some autorouter not to put copper there, and attributes to tell DRC
>> >> to check for intruding copper.  Future plugins need more layers to tell
>> >> about different constraints.
>> >> 
>> >> Ideally, any layer type is fully defined via attributes.  The most
>> >> common attribute may be "net:conductive" for normal copper layers, so
>> >> that the HIDs know that the layer contributes to the implementation of
>> >> the netlist.  Copper layers need a second attribute "gbr:layer=inner5"
>> >> to tell the (gerber) exporter where to put it.  A third attribute
>> >> defines the DRC rules that apply "drc:rules=default", plus per layer
>> >> override "drc:minwidth=6mil".
>> >> 
>> >> "drc:courtyard=front"
>> >> "drc:keepout=front"
>> >> "route:keepout=front"
>> >
>> >
>> > 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 possible.
>> 
>> I do not understand that argument.
>
> 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 know, that it is conductive
> layer and I should consider it. I can take care of special DRC rules for
> some conductive layers later.

So we do need layer specific DRC rules.  Silk layers get the silk rules
attached.  Copper layers get copper rules attached.

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

Well, that would be a DRC violation :-) The DRC tool shall not suffer
from nightmares if it finds positives.

> That is why I insist on 'typed' layers, not 'tagged' layer.

As long as the user can define arbitrary types, the type becomes an
attribute.  If the user cannot define new types, then there shall be
only very few very abstract types, connected to basic properies, e.g.,
"conductive", "hole/via", "other".

> That example is probably silly, but someone would probably come up with
> something more realistic, but still giving me nightmares.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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.  A Via is a composit, consisting of a circle on the hole layer, and
>>> > various circles on copper layers, and circles on mask layes, and
>>> > thermals.
>>>
>>> The "layer" concept should be physical, not a metaphysical abstraction. 
>>> Objects in a layer may contain holes, but a "hole layer" is nonsensical, a 
>>> toxic conceptual shortcut. An "outline" layer is similarly bad: the 
>>> insulating layers may all have the same shape sometimes, but not always.
>>
>> The outline layer will be part of 'physical' layer. So if you have 2
>> 'physical' layers with different shape, it will play nicely.
>>
>> What I am prosposing is 2 level concept. There will be 'physical'
>> layers, so you can add properties to them. And than there will be
>> 'drawing' surfaces. And 'outline' is just drawing suface telling the
>> 'physical' layer it's edges.
>>
>> But I am not convinced that we need special 'hole' typed layer. Maybe we
>> can things like 'holes' which are not part of any specific layer just
>> float in space. I thing that it would work.
>>>
>>> Trying to model things that aren't layers as if they were layers is one 
>>> common mistake in this kind of tool. Equally common is leaving out layers: 
>>> the insulating layers in a PCB are just as important as the copper, and 
>>> have their own properties (shape, thickness, material, etc.). They're a 
>>> critical part of the layer stack.
>>
>> The problem I see with the insulating layers is that there is nothing on
>> them...So you don't need them as 'drawing' layers. But I agree that
>> there should be a way how to add some attributes to them.
>
>
> 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 any drawings on that
> layer, should not preclude it.
>
> Now the exporter may barf if it finds something it can't cope with,
> like a line drawn on a separator layer.

If you have a foundry that does such things, probably you send them a
gerber layer and tell them that those are the embedded resistors between
copper 2 and 3.  And that other layer are those between copper 5 and 6.

No special exporter required.  But you must keep the drawing layers a
bit more abstract, else you confuse the tools that have invalid
assumptions.

The embedded resitors will be elements in a process specific library.
Not top/inner/bottom layers, that get mapped to the layer present in the
layout, but footprints with explicit layers.  Including a shape on the
resistive layer, and pads on the adjacent copper layers.

The pcb layout tool will not need to know anything about those embedded
devices.  They just emerge and work.  All you need is layers that are
not marked conductive.

And if those strange embedded deviced become common, somebody needs to
add some DRC rules, which at that time are just a few boolean ops on some
layers in a config file.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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
>> > footpring called 'via' and it should receive extra care.
>> 
>> Why single out "via" and "footprint" when they are merely members of
>> an open-ended list of possible composite objects?
>
> We need to single out 'via' so someone who want's simple board can find
> 'via' tool as everywhere. And under word 'footprint' I mean any other
> composite object.

That is up to the HID to find the composits with attribute
"type=via", and present them in a via toll selector.

And to maintein an in memory list of composits of "type=element" and akt
on those when the users asks for elements.

>> > I am ok with that, I just need to figure out how to handle mapping from
>> > footprint layers to layout layers. I don't want concept of 'top',
>> > 'inner', 'bottom' layer at all...that is too naive for me.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
Martin Kupec  writes:

> On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote:
>> >> Trying to model things that aren't layers as if they were layers is
>> >> one common mistake in this kind of tool. Equally common is leaving out
>> >> layers: the insulating layers in a PCB are just as important as the
>> >> copper, and have their own properties (shape, thickness, material,
>> >> etc.). They're a critical part of the layer stack.
>> >> 
>> >> The description language needs to be able to express "feature p in
>> >> layer x is aligned with feature q in layer y" in order to build up
>> >> composites. This is the geometrically sensible way to describe the
>> >> result of drilling through several layers. But the geometric
>> >> description language should not be tied to any particular fabrication
>> >> procedure.
>> > 
>> > This is all too physikal for my taste.
>> 
>> I assert that if you do it any other way, you wind up with the
>> following catastrophe: the code for every layer type needs to
>> incorporate a specific definition of its interaction with the code
>> for every other layer type. A total collapse of factoring, poisoning
>> flexibility and maintainability. But if layers correspond to actual
>> geometric layers, this can be avoided, I believe.

What I like with PCB is that there is very little interaction.  Only
when special actions are called, the interactions are invoked.  E.g.,
when I hit the O key, the connectivity is evaluated.  For that I only
need to know which layers are conductive and what vias connect which
layers.

> 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 performing any
> action, but I think that it can still be interaction with object on the
> same layer.

I do not understand what problems you see with composits.  A layer
consists of the union of all shapes on any level of the composits
hierarchy.  Composits may be referenced at multiple positions, so those
shapes appear multiple times.  When a shape is modified in a composit,
it may affect all copies simultaniously, or the composit will be
duplicated (copy on write), depneding on an attribute or explicit user
action.

> So, i.e., If we would have 'hole' layer. I would have check, that holes
> on hole layer are not intersecting. And also check the intersection of
> attached shapes on each layer. But all what can happen is that some
> layer will yell that something bad happend and I should cancel my
> action.

Where do you want to attach holes. To layers, like John proposes?  To
shapes on a layer?  Or as independent entities, like they are now?  

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie  writes:

>> Why single out "via" and "footprint" when they are merely members of
>> an open-ended list of possible composite objects?
>
> Because a tool that doesn't deal with real-world concepts in a
> user-friendly way is unusable.

Yes.  The real world concepts must exist, in a higher level.  In the
attributes.  The HIDs must implement them in a user-friendly way.  At
the lowest level, there shall be abstractions. 

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. Then there will be no more question if some
feature is supported in elements or not, or how convoluted a via may be.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
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 different attributes.  The one has attributes to
>> tell DRC to flag overlapping components, the other has attributes to
>> tell some autorouter not to put copper there, and attributes to tell DRC
>> to check for intruding copper.  Future plugins need more layers to tell
>> about different constraints.
>> 
>> Ideally, any layer type is fully defined via attributes.  The most
>> common attribute may be "net:conductive" for normal copper layers, so
>> that the HIDs know that the layer contributes to the implementation of
>> the netlist.  Copper layers need a second attribute "gbr:layer=inner5"
>> to tell the (gerber) exporter where to put it.  A third attribute
>> defines the DRC rules that apply "drc:rules=default", plus per layer
>> override "drc:minwidth=6mil".
>> 
>> "drc:courtyard=front"
>> "drc:keepout=front"
>> "route:keepout=front"
>
>
> 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 possible.

I do not understand that argument.

> Each element has a clearance attribute, so definition of extra space
> around pads should be easy. But we can add 'keepout' layer in addition.
>
> Even when we would have more layer, it should be simplier to implement
> them than some arbitrary flags.
>
> Defining DRC rules per layer is a bit different story and I hope it will
> not be too closely related to changing of layer concept, as I don't want
> to touch DRC.
>
>   Martin Kupec
>
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-18 Thread Stephan Boettcher
DJ Delorie  writes:

>> The 'countryard' layer should be exactly the keepout layer.
>
> They're two different purposes, though.  The courtyard is for physical
> placement restrictions, the keepout is for copper routing
> restrictions.

The file format need not know about these distictions.  Both are
graphical layers, with different attributes.  The one has attributes to
tell DRC to flag overlapping components, the other has attributes to
tell some autorouter not to put copper there, and attributes to tell DRC
to check for intruding copper.  Future plugins need more layers to tell
about different constraints.

Ideally, any layer type is fully defined via attributes.  The most
common attribute may be "net:conductive" for normal copper layers, so
that the HIDs know that the layer contributes to the implementation of
the netlist.  Copper layers need a second attribute "gbr:layer=inner5"
to tell the (gerber) exporter where to put it.  A third attribute
defines the DRC rules that apply "drc:rules=default", plus per layer
override "drc:minwidth=6mil".

"drc:courtyard=front"
"drc:keepout=front"
"route:keepout=front"


-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-16 Thread Stephan Boettcher
John Doty  writes:

> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote:
>
>>> Ok. So "via" should be a circle element on "hole" typed layer.
>> 
>> No.  A Via is a composit, consisting of a circle on the hole layer, and
>> various circles on copper layers, and circles on mask layes, and
>> thermals.
>
> The "layer" concept should be physical, not a metaphysical
> abstraction. Objects in a layer may contain holes, but a "hole layer"
> is nonsensical, a toxic conceptual shortcut. An "outline" layer is
> similarly bad: the insulating layers may all have the same shape
> sometimes, but not always.

So, a via needs a separate hole in each copper and insulating layer?  And
each layer needs its own discription of it's shape?

> Trying to model things that aren't layers as if they were layers is
> one common mistake in this kind of tool. Equally common is leaving out
> layers: the insulating layers in a PCB are just as important as the
> copper, and have their own properties (shape, thickness, material,
> etc.). They're a critical part of the layer stack.
>
> The description language needs to be able to express "feature p in
> layer x is aligned with feature q in layer y" in order to build up
> composites. This is the geometrically sensible way to describe the
> result of drilling through several layers. But the geometric
> description language should not be tied to any particular fabrication
> procedure.

This is all too physikal for my taste.

Why are you so attached to the concept of drilling?  For the design of a
layout, all that matters is that there are conductive connections
between layers. 

For me, a layer is something that the designer puts shapes on.  Shapes
with atributes, if required.  The semantics of these shapes on a given
layer shall all be the same.  Some of these are required for netlisting,
some are steering the physical checkout.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-16 Thread Stephan Boettcher
Martin Kupec  writes:

> On Wed, Mar 16, 2011 at 02:42:26AM +0100, Stephan Boettcher wrote:
>> IMHO, .. holes are circles draw on just another layer.  People were
>> asking for slots.  If they find a vendor to do them, they may just draw
>> lines on that layer as well.  Else, DRC shall flag non-circles.
>> 
>> Each such hole layer shall have a spec (attribute) to which (copper)
>> layers they electrically connect.  There will be at least one such layer
>> for each type of blind, burried, and through via.
>> 
>> The GUI will happily stack vias according to the selected routing style
>> into a composites and paste them on the layout, so for simple cases
>> nothing changes from how we work now.
>
> Ok. So "via" should be a circle element on "hole" typed layer.

No.  A Via is a composit, consisting of a circle on the hole layer, and
various circles on copper layers, and circles on mask layes, and
thermals.

A library (routing style) Via would have top, inner, (outer?), bottom
copper layers, which would be mapped to physical copper layers of the
layout according to some mapping, exactly as for footprints.

In addition, some projects would have their own sets of Vias in a
library, where those circles are expressed explicitly for the physical
hole/coper layers of that board, for burried and blind vias, or special
annular ring config on certain inner layers. That library shall be
linked to some Via GUI to efficiently choose from.

> That object will have some description to which "layers" of type cooper it
> belongs to. 

The hole _layer_ should have that description.  The default connects to
all copper.  Blind and burried vias require extra hole type layers, one
for each set of drill stacks.  This information is needed for
connectivity checks mostly.  Some DRC check may verify if the drilling
of the stacks is feasible.

I think this is simpler and more flexible that DJs proposal: to
hierachically group (copper) layers into drill stacks.  That would be a
John D violation, since it originates from a narrow view on how PCBs are
manufactured.  It in no problem to reflect such a narrow view in a DRC
rule, but it is a mistake to cast it into the core data structure.  A
HID may present the layers in such an arangement to the user. Said HID
may then proceed to add the required hole layers and Via types
automatically, after the user pushed the copper layers around as
required for the project.

> And how would you describe the cooper around via on each layer?
> Someone wanted different cooper size/shape on different layers.


>   Martin Kupec

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-15 Thread Stephan Boettcher
Martin Kupec  writes:

> On Tue, Mar 15, 2011 at 03:55:58PM -0600, John Doty wrote:
>> 
>> On Mar 15, 2011, at 3:35 PM, Martin Kupec wrote:
>> 
>> > There will be a struct called "via".
>> > It will contain a "hole" and pointers to attached object on
>> > all affected layers.
>> 
>> No. A "via" is only one kind of composite object. The list of kinds
>> of composite objects that might appear on a board is unbounded. There
>> isn't even a single kind of via in real life. Having an ad hoc
>> implementation of each such object is impractical and confusing.
>> 
>> Well-designed software would avoid implementing such things as
>> special kludges, but would have a general facility for describing
>> them. Then, users could contribute to libraries of such descriptions,
>> so we would not be so dependent on developers to spoon feed us every
>> detail. Footprints are a particular case of this, but other kinds of
>> composite objects (subcircuits, antennas, delay lines, buried vias,
>> fuses, current sense resistors, printed inductors and capacitors,
>> ...) could also be in the library if the software properly
>> distinguished between primitive elements and composite objects.
>
> Ok. You got the point. I don't see how to do it right now, but I will
> think of it.
>
> We need at least "hole" element. And say which layers it goes through.
> But the rest can by "just footprint". The problem I see is that the
> number of layers affected differs, so the footprint has to accomodate
> that.

IMHO, as holes are circles draw on just another layer.  People were
asking for slots.  If they find a vendor to do them, they may just draw
lines on that layer as well.  Else, DRC shall flag non-circles.

Each such hole layer shall have a spec (attribute) to which (copper)
layers they electrically connect.  There will be at least one such layer
for each type of blind, burried, and through via.

The GUI will happily stack vias according to the selected routing style
into a composites and paste them on the layout, so for simple cases
nothing changes from how we work now.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: subcircuit definition and channelised design

2011-03-15 Thread Stephan Boettcher
John Doty  writes:

> On Mar 15, 2011, at 2:50 PM, Stephan Boettcher wrote:
>
>> There should be some way to disable hierarchy-traversal from the
>> commandline, is there? 
>> 
>> Or at least a local gafrc, but even that would push it out of reach for
>> me.
>
> You have to put a little bit of Scheme in some gnetlistrc someplace to
> control it from command line, but it can be done:
>
> http://archives.seul.org/geda/user/Nov-2008/msg00489.html

I had a peek at the man page:

   -c string
   Pass  the  specified  string  to  the  guile interpreter.  This
   allows you to execute arbitrary guile scripts from the  command
   line.   Be  sure  to  surround the string with either single or
   double quotes to satisfy your shell.   The  string  is  execute
   before  any  init  or  netlist backend scheme code is loaded or
   executed.

How about:   gnetlist -c '(hierarchy-traversal   "disabled")'


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

-- 
Stephan 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: subcircuit definition and channelised design

2011-03-15 Thread Stephan Boettcher

Krzysztof Kościuszkiewicz  writes:

> Dnia 2011-03-15 o godzinie 21:03 Bert Timmerman napisał(a):
>
>> http://www.xs4all.nl/~ljh4timm/downloads/geda_sch2sym.tar.gz
>> 
>> #!/bin/bash
>> # gEDA - GNU Electronic Design Automation
>> # geda_sch2sym.bsh
>> # Copyright (C) 2007  Andrew Tan
>> 
>> Says it all.
>
> It is also waiting for review here: 
> https://bugs.launchpad.net/geda/+bug/698670


> IMPORTANT NOTE:
> In order to run geda_sch2sym.bsh, users must make sure the
> "hierarchy-traversal" is "disabled" in the "system-gnetlistrc" file
> (usually located in the "/usr/share/gEDA" folder).

There should be some way to disable hierarchy-traversal from the
commandline, is there? 

Or at least a local gafrc, but even that would push it out of reach for
me.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-03-15 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> DJ Delorie wrote:
>
>> However, I don't think we should start off with "lines have paste".
>> They don't.
>
> My current project happens to be a use case for lines with paste:
> I need to transport lots of current on limited space. And it needs 
> to be very resistant to vibration (this is supposed to survive a 
> rocket launch) So ordinary green wires soldered are considered
> a risk of failure. What we intend to do, is solder copper wires 
> full length on the board. This calls for tracks with exposed 
> copper and corresponding apertures in paste layer. Paste will 
> allow for better control of the amount of solder than with a 
> simple syringe dispenser. 
>
> Currently tracks cannot be uncovered, let alone induce paste apertures. 
> As a work-around I plan to convert the current path into pads just before 
> the layout is exported to gerber. (Maybe, I should write a script...)
> This is of course a kludge. 
>
> Upshot: Please try not to constrain possible attributes and properties 
> of objects. There may be use cases even for seemingly weird combinations
> just around the corner. 

I don't think that paste shall be attributes of lines. Lines and paste
live at the same level.  If you need to connect them, you'd need to go
one level up, like elements are one or two levels up from lines and
paste, or vias are one level up.

To implement this level (lines+paste) you will not need support from the
file format, it's in the GUI.  You may add attributes to lines and paste
objects that effect the GUI to edit them together.

IMHO, the file format shall loose all special support for levels
(elemets, vias), just an arbitray hierachy of grouping, with attributes
that tell the GUI how to present those to the user for editing.

> (Do I sound like John Doty now? :-) 

All will be well :-)

>> Allowing a GUI way to enable/disable layers anywhere in the heirarchy
>> would be cool; you could disable just the assembly objects in your
>> generic silk layer.
>
> +1
>
> ---<)kaimartin(>---

-- 
Stephan Böttcher FAX: +49-431-85660
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: OT: Vintage uP

2011-03-03 Thread Stephan Boettcher

Ethan,

Thanks a lot!

Stephan

Ethan Swint  writes:

> Stephan-
>
> Here's what I've got in the Motorola family:
> MC68010L8 - 1 unit
> SC87876L8 - 1 unit
> MC68000P8 - 2 units
> MC68000P10 - 2 units
>
> These are all 64-pin devices; I'm not sure about the SC87876.  It
> looks like shipping is reasonable - USD$13.25 for a DVD-sized box.
>
> Regards,
> Ethan
>
> On 02/13/2011 05:57 PM, Stephan Boettcher wrote:
>> Ethan,
>>
>> Ethan Swint  writes:
>>
>>> I recently ran across a cache of 'vintage' microprocessors - a
>>> Motorola MC68010L8 and other MC68K chips, Dallas Semi Speed it uP, AMD
>>> 8088, etc.  The are all in new condition, most in ESD foam.  Any of
>>> these of interest to the list?
>> Well, if you could ship to Europe in an unsusicious package to avoid
>> customs excessive duties, I'd be interested in an MC68010L8 and maybe
>> other MC68K chips (what are those? UART? FPU?)  I could pay via paypal.
>>
>> Cheers, Stephan
>>
>>> Regards,
>>> Ethan
>
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

-- 
Stephan Böttcher FAX: +49-431-85660
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 commands to automatically select, cut, rotate, and paste elements

2011-02-25 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Stephan Boettcher wrote:
>
>> For example the outline of the board on the attached picture 
>
> This looks nice. 
> How about a Ben mode rendered image of this layout on the gallery 
> of gpleda.org? (Ideally augmented with the shadow effect of image 
> magick) 

Since you asked:

All six boards for the sensor head of MSL RAD were done with gEDA/PCB:

 
http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/PF/pcbs/TFlex/IMG_1285_800x600.html

 
http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/D/IMG_0208_800x600.html

 
http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/DE/IMG_0368_800x600.html

 
http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/F/IMG_0586_800x600.html

 
http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/ABCDEF/IMG_0811_800x600.html

 
http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/ABCDEF/IMG_0812_800x600.html


http://en.wikipedia.org/wiki/Mars_Science_Laboratory#Radiation_Assessment_Detector_.28RAD.29

>
>> (which will launch into space later this year to land on Mars)
>
> Hey, this increasingly becomes a flock of rocket scientists!
> John Doty does space projects. Yours is going to mars. And my 
> current project will enjoy a short flight in an ESA rocket.
>
> ---<)kaimartin(>---

-- 
Stephan Böttcher FAX: +49-431-85660
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 commands to automatically select, cut, rotate, and paste elements

2011-02-23 Thread Stephan Boettcher
Mark Rages  writes:

> You would be wise to avoid PCB for anything non-rectangular.  It is
> exceedingly painful.

I do recommend pcb for anything non-rectangular.  The arcs can be nicely
done in gnumeric, python, awk, whatever.  With a gui this will be
difficult.

For example the outline of the board on the attached picture (which will
launch into space later this year to land on Mars)



RADE_front.pdf
Description: Adobe PDF document

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Breaking up power planes

2011-02-20 Thread Stephan Boettcher
Russell Dill  writes:

> On Sun, Feb 20, 2011 at 10:05 AM, Kai-Martin Knaak  wrote:
>> Russell Dill wrote:
>>
>>> I'm just wondering what everyones preferred method of breaking up
>>> power/ground planes is.
>>
>> My preferred method is to break the planes as little as possible :-)
>> IMHO, a continuous copper plane is the best you can get for shielding
>> purposes. If large amounts current need to be canalized, I prefer to
>> guide them in fat tracks rather than polygons. With tracks it is easier
>> to ensure a minimum diameter.
>>
>
> My design has several different power and IO rails, and so it requires
> split power planes.I realize its possible to do with the polygon
> editor, it just seems like it'd be much easier with the line drawing
> tool.

You want to split a polygon into different nets?  Does that work?  Even
if you invoke the special magic to not loose isolated parts of the
polygon, will the connectivity check treat them as separate copper and
assign them to different nets?

I've drawn separate polys for each power/gnd net on my boards. 

Let's see, ok, it does work.  I'd still be uncomfortable with such a
layout.



test.pcb
Description: Binary data

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: polygon regression in pcb+gl

2011-02-20 Thread Stephan Boettcher
k...@aspodata.se (Karl Hammar) writes:

> Stephan:
>
>> Do "ssh -v git.gpleda.org" to see which version is used.  Most default
>> sshd installations do not permit protocol version 1.
>
> Can't test that:
>
> $ ssh -v git.gpleda.org
> OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8o 01 Jun 2010
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to git.gpleda.org [97.107.141.5] port 22.
> debug1: connect to address 97.107.141.5 port 22: Connection refused
> ssh: connect to host git.gpleda.org port 22: Connection refused
> $
>
> Regards,
> /Karl Hammar

Peter could, you'd need to spec the port number :-)

(stephan)blaulicht:~$ ssh -v -p 5022 git.gpleda.org
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /home/blaulicht/stephan/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to git.gpleda.org [97.107.141.5] port 5022.
debug1: Connection established.
debug1: identity file /home/blaulicht/stephan/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/blaulicht/stephan/.ssh/id_rsa-cert type -1
debug1: identity file /home/blaulicht/stephan/.ssh/id_dsa type -1
debug1: identity file /home/blaulicht/stephan/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 
Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: checking without port identifier
The authenticity of host '[git.gpleda.org]:5022 ([97.107.141.5]:5022)' can't be 
established.
RSA key fingerprint is d7:07:7f:96:51:11:ab:43:57:0d:fe:92:45:72:e8:93.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
(stephan)blaulicht:~$ 


-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: polygon regression in pcb+gl

2011-02-20 Thread Stephan Boettcher
Peter Clifton  writes:

> On Sun, 2011-02-20 at 10:36 +0100, Karl Hammar wrote:
>> Peter Clifton:
>> ...
>> > generate, and setup .ssh/config with these lines:
>> > 
>> > """
>> > Host git.gpleda.org
>> > 
>> > Port 5022
>> > RSAAuthentication yes
>> > IdentityFile ~/.ssh/keys/id_rsa.gpleda.org
>> > """
>> ...
>> 
>> Don't you know that protocol version 1 i vulnerable for a
>> man-in-the-middle attack?
>
> No, I didn't know that.
>
> Does it require a different type of key to be generated and used, or
> just removing that option to become secure again?

id_rsa is a version 2 key.

The RSAAuthentication may be used for version 1 only, but that does not
mean specifying it makes ssh to use version 1.

Do "ssh -v git.gpleda.org" to see which version is used.  Most default
sshd installations do not permit protocol version 1.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-02-16 Thread Stephan Boettcher
John Doty  writes:

> On Feb 15, 2011, at 9:40 AM, Stephan Boettcher wrote:
>
>> DJ Delorie  writes:
>> 
>>> The two words mean two different things in the English language.
>> 
>> sorry, I wasn't clear on these distinctions.
>
> DJ has a very narrow and negative viewpoint on factoring.

In the end, I do not care how you call what is being done, as long as
the results are more like Unix, and less like Multics :-)

Stephan



>>> Refactoring means changing nonfunctional attributes of the software
>>> (i.e. rearranging code to be more maintainable).
>
> Way, way too narrow. Refactoring can dramatically increase the power at the 
> users' fingertips. Consider a favorite Brian Kernighan example. Take the 
> Multics command:
>
> how_many_users
>
> In Unix, refactor it into:
>
> who | wc -l
>
> Now, you've given the user much more power with fewer commands. For example,
>
> ls | wc -l
>
> counts files, something I recall there was no command for in Multics. 
>
> The large suite of inflexible, specialized commands in Multics collapsed into 
> a much smaller set of commands that were specialized in one sense (what 
> abstraction was served) but generalized in another (what end was served) in 
> Unix. This put a lot more power in users' hands: many things that would have 
> required a page of tricky PL/I code in Multics became simple shell one-liners 
> in Unix. It was much easier to master and remember the smaller, but more 
> powerful, set of Unix commands.
>
>>>  If we're talking
>>> about changing functionality (as we were in this case), we need to use
>>> a different word.
>
> Functionality emerges naturally from good factoring. Without good factoring, 
> functionality requires a large number of complex "features" that are 
> difficult to remember and often don't play well with each other.
>


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-02-15 Thread Stephan Boettcher
DJ Delorie  writes:

> The two words mean two different things in the English language.

sorry, I wasn't clear on these distinctions.  

> Refactoring means changing nonfunctional attributes of the software
> (i.e. rearranging code to be more maintainable).  If we're talking
> about changing functionality (as we were in this case), we need to use
> a different word.
>
> An example of refactoring, in PCB's case, would be changing the
> underlying language from the C/C++ hybrid mess we have now to a clean
> C++ object-oriented structure, without changing the code's
> functionality at all.
>
> An example of redesigning, in PCB's case, would be changing the way
> the user manages the layer stack and what kinds of layers the user can
> describe.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-02-15 Thread Stephan Boettcher
Martin Kupec  writes:

> On Tue, Feb 15, 2011 at 09:45:40AM -0500, DJ Delorie wrote:
>> 
>> > I am not shure if it is possible to have non-circular drill holes in
>> > gerber files. We can have the "pad" around the hole be of any shape,
>> > but the hole itself probably needs to be circular.
>> 
>> We can have any shape hole we want, if we export it as a gerber file
>> instead of an excellon file.  However, that doesn't mean the fab will
>> manufacture it.
>
> I will stick with the current manufactors abbilities...

Hmmm.  We had requests to express plated slots in this group.  If
somebody defines an extra via layer for slots, and draws polygons or
traces on it, the exporter should recognise that and produce a gerber
instead of a drill file.  The rest is negotiation with the vendor.

PCB will be able to check the connectivity by the via connectivity
attributes.

I'd love to draw square polygons (or better traces without rounded caps)
on a via layer and export to gds2 instead or gerber.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-02-15 Thread Stephan Boettcher
Martin Kupec  writes:

> On Tue, Feb 15, 2011 at 11:17:27AM +0100, Stephan Boettcher wrote:
>> And think about vias as well.  Those need a major refactoring as well,
>> to support custom via stacks, blind and burried vias.  
>> 
>> IMHO, vias should be layers as well, with attributes that tell to which
>> conductive layers they connect. 
>> 
>> So maybe it is a good idea to keep vias in mind when redoing they way
>> layers are handled.
>
> I was at the idea, that a via will be assigned set of "physical layers"
> and it will show in each "cooper layer" belonging to that "physical
> layer".
>
> That should be relativly simple to achieve. And by default it will be
> assigned all the "physical layers". Pressing shift or ctrl will make it
> ask what layers you want it to belong. Plus there need to be the
> possibility to change default temporary in order to aid making a lot of
> blind/burried vias at once.

With different annular rings, and clearance on each layer, and
non-circular shapes, ...

A via editor HID shall at least provide means to modify annular and
clearance independently for top, inner, bottom, soldermask top,
soldermask bottom logical layers.  The file formal shall allow to spec
this for each physical layer as well.  When we are at that point, a via
is a stack of structures on various layers.  The hole itself may then be
just a circle on another layer of type via.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-02-15 Thread Stephan Boettcher
Steven Michalske  writes:

> Trashing the spam
>
> Layers should get attributes.
> Conductive
> Thickness
> Resistivity
> Material
> Dieletric constant
> Are a few I can think of off the top of my head
>
> So a way to attach arbitrary attributes is a good plan for flexibility.
>
> Need for other kinds of layers. Like keepouts and part outline.  
>
> Perhaps a layer plugin concept.  A layer that says it wants to be
> processed by a drc plugin of type foo.

And think about vias as well.  Those need a major refactoring as well,
to support custom via stacks, blind and burried vias.  

IMHO, vias should be layers as well, with attributes that tell to which
conductive layers they connect. 

So maybe it is a good idea to keep vias in mind when redoing they way
layers are handled.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: General Layers questions

2011-02-14 Thread Stephan Boettcher

Kai-Martin Knaak  writes:

> Martin did not ask for a general pcb wish list, but for an in depth
> discussion of a single topic. 

A discussion where most people cannot contribute?  What is wrong with
this list for discussion?

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: OT: Vintage uP

2011-02-13 Thread Stephan Boettcher

Ethan,

Ethan Swint  writes:

> I recently ran across a cache of 'vintage' microprocessors - a
> Motorola MC68010L8 and other MC68K chips, Dallas Semi Speed it uP, AMD
> 8088, etc.  The are all in new condition, most in ESD foam.  Any of
> these of interest to the list?

Well, if you could ship to Europe in an unsusicious package to avoid
customs excessive duties, I'd be interested in an MC68010L8 and maybe
other MC68K chips (what are those? UART? FPU?)  I could pay via paypal.

Cheers, Stephan

>
> Regards,
> Ethan

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: transition of pcb internal units to metric (SI, mm)

2011-02-08 Thread Stephan Boettcher
John Doty  writes:

> I doubt PCB will ever be a suitable tool for chip design.

Why?  It should not make that a priority.  But the hierachical features
outlined elsewhere, layer types, a sufficiently generic via mechanism,
its not too far from making it possible to do chip design.

Hierachy, blind and burried vias, all these PCB features are on the
list.  Just steer the development just a little bit to make it general
enough in the core/file formats.  The GUI may be 100% PCB by default and
hide the generality from the user.

Chip design will then need another pile of code to interpret the
drawing in terms a silocon technology, at least a gds2 exporter.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: PCB bug: only names, draw a line, undo: segfault

2011-01-30 Thread Stephan Boettcher
Peter Clifton  writes:

> On Sun, 2011-01-30 at 15:22 +0100, Stephan Boettcher wrote:
>
>> It only happens when I hit u (undo) after drawing a track segment, but
>> did not terminate the draw (with middle mouse button).
>
> That matches the same set of steps where I can trigger the valgrind
> warning.
>
> As an added data-point, I was able to reproduce with "Only names"
> switched off when I started line-drawing, but switched it on mid-way,
> before I hit undo.
>
> A cursory glance didn't suggest what might be wrong yet.. please file a
> bug at:
>
> http://launchpad.net/pcb/+filebug

That site shows a white page with a [continue] button, and then I click
on it, it says 'Invalid OpenID transaction'.  And when I turn on
Javascript, it does nothing more helpfu either.  And anyway, I do not
have an account with launchpad, and I don't think I'd want one. Sorry.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: PCB bug: only names, draw a line, undo: segfault

2011-01-30 Thread Stephan Boettcher

Stefan Salewski  writes:

> On Sun, 2011-01-30 at 14:48 +0100, Stephan Boettcher wrote:
>> PCB version 20100929
>> Compiled on Nov  8 2010 at 05:46:11
>> Debian sid.
>> gtk.
>> 
>> - Settings->Only Names
>> - draw a line
>> - hit 'u' for undo.
>> 
>> -> segfault.
>> 
>
> Works fine for Gentoo AMD64, tested empty board and tut1.pcb.
>
> PCB version 20100929 (GTK)

Ok, I tried again, empty board, and yes, the segfault does not happen
when a line draw is completed (with the middle mouse button).

It only happens when I hit u (undo) after drawing a track segment, but
did not terminate the draw (with middle mouse button).

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


gEDA-user: gnetlist (bug?) subcircuit symbol without pinnumbers

2011-01-30 Thread Stephan Boettcher

Hi,

a few comments/questions on this weekends gnetlist experince:

gnetlist via gsch2pcb complains a lot, and adds a pin U?-? on every net
that connects to a specific symbol for a subcircuit (with source=
attibute). The error messages are not helpful.

It took a while to figure out that gnetlist is unhappy about not finding
pinnumber= attibutes on the pins of that symbol.

Why does a subcircuit need pin numbers? The connectivity is establisched
via pinlabel= (although pinnumber= would be more intuitive, at least
until we get rid of all the attribute overloading, and since pinnumber=
seems to be required for unknown reasons).

Why does gnetlist not tell which entity it is complaining about in its
error messages?

$ gnetlist --version
gnetlist: unrecognized option '--version'

... oh, that is unhelpful as well, no cut'n paste from the gschem about
box either. Let's see, 

$ dpkg -s geda | grep ^Version
Version: 1:1.6.1-4

Debian sid.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


gEDA-user: PCB bug: only names, draw a line, undo: segfault

2011-01-30 Thread Stephan Boettcher

PCB version 20100929
Compiled on Nov  8 2010 at 05:46:11
Debian sid.
gtk.

- Settings->Only Names
- draw a line
- hit 'u' for undo.

-> segfault.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gschem: directly connecting two nets?

2011-01-26 Thread Stephan Boettcher

Peter Clifton  writes:

> On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote:
>> The special symbols is supposed to fuse netnames as issued on the
>>netlist,
>>not labels on the schematic.
>>---
>>If you are also fusing the copper on the board then I would kind of
>>like to see that when I am viewing the schematic.
>>You want to give the user a choice. If I pull up a component view then
>>I want to see the signal names from the original designer. If I am
>>traversing a hierarchy and open an instance view then I want to see the
>>signal names that match the names in the parent instance.
>>John Eaton
>
> For a loop antenna, for example, the solution needs to be in PCB.. allow
> footprints / "functional groups" which implement RF components by
> placing copper on some layer.
>
> For me, this raises a very interesting design question:
>
> How do I go from abstract inductor / transmission line / (capacitance
> even?) representations on a schematic, to correctly DRC'd board layout?

This will probably require an additional tool.  The tool needs to
extract the properties of the wiring from the layout via some techology
file that describes the properties of the board materials (layer stack,
etc).  

The schematic will have attributes on nets that spec what to check for.
IMHO, net segments should be explicitly marked with the short-symbol
that was discussed.  A gnetlist backend will provide a netlist to the
verification tool that includes the attributes and net segments.  The
PCB gnetlist backend merges the net segments.  How to split out the net
segments during extraction is probably not easy.

> The inductor will end up as a shaped piece of copper tracking, and at
> this point, you realise that "net" is a very DC term!

The inductor could be a subschematic with shorted pins via two short
symbols, with a net in between that asks for an inductance check of
some sort.

> We would need to have some way to demarcate the start and end of the
> inductor in PCB, or to draw it on a layer, or with an attribute which
> causes the copper making up the "component" to be disjoint from either
> net connecting to that section. That piece of board layout becomes a
> "component", not an interconnect between components.

The DRC could be told to treat certain layers in a group as component
copper.

> One might imagine a similar method being useful to join two
> hierarchically shorted nets together... have a "link" component which
> joins AGND and DGND, which is implemented by copper drawn on the board
> between those two power planes.
>
> This would then allow preservation of important DRC checks such as
> making sure the correct plane / return path is used for signals.
>
> Regards,

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gerber outlines

2011-01-24 Thread Stephan Boettcher

> ... you can either rename a layer ...

 ... you can either rename an unused empty layer ...

> ... that exclusively contains the objects in the outline layer. 

 ... in particular, no vias and pins.

> ... the width of the lines does not matter. The fab will cut the board
> at the center of the lines.

Is this universally true?  

At least our milling machine mills the outline on the outer edge of the
lines.  The guy who runs the machine says, he cannot easily tell the
programm to mill along a center line.

I prefer to keep the line width within tolerances to both sides, so if
the fab ignores my README specifying the centerline, it is no big deal.

-- 
Stephan 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gerber outlines

2011-01-24 Thread Stephan Boettcher
Rob Butts  writes:

> I'm trying to provide Dorkbot PDX with gerbers for a two-layer circuit
> board.  They require an outline gerber so I followed the
> http://geda.seul.org/wiki/geda:pcb_tips#how_do_i_make_a_board_outline_to_go_with_my_gerbers_to_the_board_maker
> instructions
> by naming the active layer which for me was the component layer 'outline'.

No.  You need to add an extra outline layer, which is empty except for
the board outline, which needs to be drawn as a closed seqence of lines
(and/or arc?).

> I then exported the gerber file and the outline gerber still shows nothing.
> The help link above makes it sound like PCB will generate the outline
> automatically to the 'outline' layer absolute edge.

No such automatism.

> Do I have to draw these lines in or does PCB do this and what should I see
> when viewing the outline gerber layer?

Yes, you need to draw them.

The fab gerber includes an outline trace, which is the 'absolute edge'
of your design when there is nor outline layer.

-- 
Stephan 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gschem: directly connecting two nets?

2011-01-24 Thread Stephan Boettcher
Ouabache Designworks  writes:

> The special symbols is supposed to fuse netnames as issued on the netlist,
> not labels on the schematic.
>
> ---
>
> If you are also fusing the copper on the board then I would kind of like to
> see that when I am viewing the schematic.

PCB requires all connecting copper to be the same net(name). gnetlist
needs to resolve merged nets to a single net.  That happens now for
hierarchy, except when a subcircuit shorts two higher-level nets.  This
could probably be fixed, with a warning and some arbitrary choice how
the net is named.

> You want to give the user a choice. If I pull up a component view then I
> want to see the signal names from the original designer. If I am traversing
> a hierarchy and open an instance view then I want to see the signal names
> that match the names in the parent instance.

There is no instance view in gschem.

> John Eaton

NB, when resolving hierarchy, gnetlist keeps the netname of the outer
level.  Sometimes I'd wish it would keep the subcircuit netname.  This
would also resolve the case when a subcircuit shorts two outer nets.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gschem: directly connecting two nets?

2011-01-24 Thread Stephan Boettcher
John Doty  writes:

> On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote:
>
>> Steven Michalske wrote:
>> 
>>> We would also need a way to force the chosen name of the net to choose
>>> when merging nets.  e.g.  When you merge a net named power with a net
>>> named 3v3_power, who wins?
>> 
>> If a two pin symbol mediates the fusion, this would be determined 
>> by the connections to the symbol. The symbol would comprise a win-pin 
>> and a loose-pin. The winner would be the net that is connected to the 
>> win-pin. 
>
> Works for the simplest case:
>
> net1 net2
> ---(WP,LP)
>
> The combined net would be "net1".
>
> But a little more complicated:
>
> net1 net2  net3
> ---(WP,LP)(LP,WP)-
>
> Is this "net1" or "net3"?

At some point the user looses for his own stupitity.  I'd just require a
well defined topology, and tell the user if the resolution is not unique,
then he has to accept arbitrary results, based on the random order of
evaluation of the shorts.

-- 
Stephan


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gschem: directly connecting two nets?

2011-01-23 Thread Stephan Boettcher
Kai-Martin Knaak  writes:

> Stephan Boettcher wrote:
>
>> You need to invent some 2-pin symbol with some special attributes, and
>> teach the pcb gnetlist backend(s) to interpret those attributes
> ^^^
>
> If there is a way to mark two net-names as physically the same net,
> then each and every backend should act accordingly. It would be an 
> invitation for nasty surprises if some back-ends would support the 
> fusion and others don't. This calls for an interpretation by the 
> frontend. 

Sure, as soon as the semantics have been fleshed out, the implementation
should move into the gnetlist library of helper functions, so that all
backends that do not care about separate attibutes of net segments can
use it.  And the other backends (none yet, but John claims he has use
cases) will grow a helper function that provides nets as a topology of
net segments.

Unless we talk about the current gnetlist, which does not support this
kind of semantic splits :-(

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: gschem: directly connecting two nets?

2011-01-23 Thread Stephan Boettcher
Colin D Bennett  writes:

> Sometimes I would like to directly connect two nets.  There are a
> number of different specific cases in which I would like to do this for
> simplicity in the schematic.  For instance, I might have an "input port"
> component (e.g., input-1.sym) on a connector pin with net "VLCD", and
> then somewhere else in the schematic want to show that "VLCD" is
> connected to "+3.3V".
>
> However, after some investigation as to why I wasn't getting the right
> rats in 'pcb' after a gsch2pcb import, I realized that connecting two
> nets in gschem (using a power symbol and/or an I/O port symbol
> connected with a net line) does not create that connection in the
> netlist!  I think the gnetlist drc did emit a warning due to this, but
> I did not understand the cause...
>
> Is there any correct way to show two nets are directly connected in a
> schematic?  e.g., connecting two I/O ports or two power symbols
> directly.

Hmm, yes.

You need to invent some 2-pin symbol with some special attributes, and
teach the pcb gnetlist backend(s) to interpret those attributes as a
net-unification bridge.  There should also be a convention how that net
should be named in the output.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Visual cue of zero length pin endpoint

2011-01-23 Thread Stephan Boettcher
Andrzej  writes:

> On Mon, Jan 24, 2011 at 12:01 AM, Peter Clifton  wrote:
>>
>> libgeda was recently patched to allow zero length pins. Please point me
>> at where the documentation says this is invalid, and I'll file a bug
>> about getting that changed.
>
> http://www.geda.seul.org/wiki/geda:file_format_spec#pin
>
> "You cannot have a zero length pen (the tools will throw them away)."
>
> The typo in this sentence technically makes it invalid. ;-) Same
> requirement exists also for other data types.
>
>> You are correct there, those driving the zero-length pins change should
>> consider whether this is a problem or not, and if so - what do do about
>> it!
>
> It makes sense to extend the spec to cover zero-length pins (IMHO
> other shapes should stay non-zero sized) but it would be better if the
> spec explicitly said when and for what purposes pin directionality can
> be used. In the current version there is no mention of it but since
> pins are guaranteed to have a direction, it's not unreasonable to use
> this property for all sorts of things.

I just made a symbol with 624 zero length pins.  Please keep them :-)

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Collaborative Development of Boards

2011-01-19 Thread Stephan Boettcher
Markus Hitter  writes:

> Am 19.01.2011 um 22:27 schrieb Stephan Boettcher:
>
>> Markus Hitter  writes:
>>
>>> Am 18.01.2011 um 01:56 schrieb John Griessen:
>>>
>>>> I thought about this some more after sleeping last night, and what
>>>> Markus
>>>> is probably asking for is a position range sensitive diff or auto-
>>>> merge.
>>>>
>>>> When people make changes in PCB that can be merged, it means they
>>>> are
>>>> working in different places, zones, quadrants...  IOW if you could
>>>> say easily *where* you were working was different and not
>>>> overlapping
>>>> another's work, an auto-merge would work -- if it only over-rode
>>>> layout
>>>> traces and footprints in the limited zone of the change made...
>>>
>>> That reminds me on an idea discussed here a few weeks ago: drop the
>>> current footprint logic and replace it with full fledged circuit
>>> layouts. You'd edit the sub-layout in it's own file and insert that
>>> into the total layout as a non-editable, but movable block.
>>>
>>> One possible drawback for both ideas: you can't route tracks through
>>> the "foreign" area/sub-layout, even if there's enough room after
>>> assembling the zones.
>>
>> Why do you need that limitation?
>
> Without that limitation, a zone is no longer a zone and conflicts can
> happen. Doesn't apply for tracks drawn to the main layout, of course.
>
> Also doesn't apply to sub-layouts of undefined size, but then the idea
> of sectoring a board for different contributors becomes a bit
> limited.

Why?  If everybody sticks to a sublayout, at least the VCS merges will
not conflict.  If the drawn copper conflicts, that's what needs to be
cleaned up after the merge.  For efficient collaboration there should
be some aggrement about who draws where, but technically there should
not be any limits how sublayouts overlap.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Collaborative Development of Boards

2011-01-19 Thread Stephan Boettcher
Markus Hitter  writes:

> Am 18.01.2011 um 01:56 schrieb John Griessen:
>
>> I thought about this some more after sleeping last night, and what
>> Markus
>> is probably asking for is a position range sensitive diff or auto-
>> merge.
>>
>> When people make changes in PCB that can be merged, it means they are
>> working in different places, zones, quadrants...  IOW if you could
>> say easily *where* you were working was different and not overlapping
>> another's work, an auto-merge would work -- if it only over-rode
>> layout
>> traces and footprints in the limited zone of the change made...
>
> That reminds me on an idea discussed here a few weeks ago: drop the
> current footprint logic and replace it with full fledged circuit
> layouts. You'd edit the sub-layout in it's own file and insert that
> into the total layout as a non-editable, but movable block.
>
> One possible drawback for both ideas: you can't route tracks through
> the "foreign" area/sub-layout, even if there's enough room after
> assembling the zones.

Why do you need that limitation?

>
> Markus
>
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.jump-ing.de/
>
>
>
>
>
>
>
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

-- 
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: Soft and Hard symbols

2011-01-18 Thread Stephan Boettcher
Peter Clifton  writes:

> On Tue, 2011-01-18 at 16:05 +0900, John Doty wrote:
>
>> Note that there's a bit of terminology confusion. gschem actually
>> manipulates segments of nets (other tools sometimes call these
>> "wires"), while "net" in EE theory is usually a topological whole,
>> where the connection is assumed to be structureless.
>
> wires is a useful distinction here, although it sounds like it implies
> something physical. I'll try to call them "net segments" from now on.
>
> Sometimes a gnetlist backend might wish to request the connectivity of a
> net (the topological whole). IMO libgeda should be able to provide that.
> (A library or convenience function if you will).

It does not happen very often, but in this point my opinion disagrees
with John's, I think.  The whole point of libgeda and gnetlist is to
express connectivity between pins.  Machine-interpreting meaning into
the details of the individual net segments is a confusing concept, that
should not be encouraged by the tools.  If such things need to be
expressed, I'd introduce a new type of symbol, and teach the gnetlist
backend that needs those semantics to treat both/all connections to that
symbol as the same net, but with different attributes.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: multiple attributes

2011-01-17 Thread Stephan Boettcher

al davis  writes:

> How about prefixing simulation attributes with a dot.

No, please,  use a proper namespace prefix, like 

  spice- verilog- sim-
  spice: verilog: sim:

Backend namespaces, use namespaces, with fallbacks into legacy and
global namespaces.

  spice-value=
  sim-value=
  value=

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Collaborative Development of Boards

2011-01-16 Thread Stephan Boettcher
ge...@igor2.repo.hu writes:

> If you edit one object, that won't ever move other objects around by 
> side effect. VCS systems I know depend on this feature. I think PCB 
> already provides this feature, keeping order of objects, 

Not really. When you edit a line, it somehow gets thrown into an
entirely different slot in the list.  Like if there is a vector of
allocated slots, some marked unused, and when something is changed, it
is thrown into the first unused slot.  Probably some feature of some
glib(?) container class?  It's not too bad for vcs diffs, but could be a
little better.  Not worth the trouble to fix this, I guess.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]

2011-01-16 Thread Stephan Boettcher
Peter Clifton  writes:

> On Sun, 2011-01-16 at 11:44 -0600, John Griessen wrote:
>> On 01/16/2011 11:32 AM, John Griessen wrote:
>> > So I don't see how that was a stopper, even without Bill's specific Altium 
>> > experience.
>> 
>> I meant Bob's
>
> I'm lost.. who is Bob?

You do not use a thread view in your mail reader, do you?

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Re: gEDA-user: Collaborative Development of Boards

2011-01-16 Thread Stephan Boettcher
Markus Hitter  writes:

> Being more a mechanics and software guy, I'm astonished how things in
> the electronics world apparently work. Perhaps I'm exaggerating a bit.
>
> Is it even possible to do something in collaboration? I'd appreciate
> any answer.

In our lab we recently had very nice results partitioning the work
across multiple boards.  The mechanics engineer did a fine housing, a
PhD-student made the front-end board with eagle, I made the main board
with gEDA/PCB, and our electronics engineer does the power board, using
eagle.  There was FPGA and ARM7 firmware to do as well.  Lot's of
opportunities to devide work and to collaborate.  You have to agree on
the interfaces for sure.  But collaborating on a single layout is pretty
stupid.

-- 
Stephan



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


  1   2   3   >