Re: gEDA-user: Advanced grids in GTK Pcb

[joeft]

On 2/10/2011 4:49 PM, Kai-Martin Knaak wrote:

joeft wrote:


I see that this site is flagged as containing a virus by a number of AV
programs.

I'd be surprised if this was relevant to linux users in any reasonable way.
A linux virus sighting in the wild would make a major stir in geek worldia,
since there had been none since 2002.

---<)kaimartin(>---


True enough in that I have only used gEDA on linux, but I do 
occasionally *read* this list on a Windoze machine.


Joe T



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

Re: gEDA-user: Advanced grids in GTK Pcb

[joeft]

A Warning!!

I see that this site is flagged as containing a virus by a number of AV 
programs.  The original poster should re-post from another site and 
maybe someone can remove the original posting?


Joe T

On 2/10/2011 2:04 AM, jpka wrote:

Hi!
I'm currently working on advanced user grid management for pcb.
Anyone interested in this? Or maybe want to beta-testing my code?
Example: http://img202.imageshack.us/i/pcbgrids.jpg/
(values are editable in this table)
Also, currently nobody works on grids, or i'm wrong?
I also need help in translation my work to lesstif's pcb, i'm was
notified that more chances to see my code in main tree if i will work on
both GTK&  lesstif.
This is my first post in newsgroup in my life, sorry if anything is
wrong. I writing only to web forums before.



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





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

Re: gEDA-user: )(

[joeft]

Kai-Martin Knaak wrote:
> On Fri, 02 Oct 2009 16:47:39 +0100, Gareth Edwards wrote:
> 
>> I guess it depends what your goal is. Kai-Martin's assumed goal was to
>> produce a (photo?-)realistic depiction of the layout/assembly.
> 
> This is the goal, I assumed Peters 3D trials were aiming at ;-)
> 
> 
>> To me that's not as useful from an engineering perspective as, say,
>> being able to see your board, and, crucially, interact with both the
>> view of the board and maybe its mechanical location in the system, in
>> real time.
> 
> I'd prefer to import 3D data from pcb, including size and position of the 
> components to my favorite mechanical CAD application. The GUI to 
> manipulate 3D object intuitively is non-trivial to the point, that there 
> is no decent open source 3D app, yet. 

I've had the same impression about the lack of a good 3D tool to do this 
(that
is available for reasonable cost).

This is a little off-topic, but the sourceforge update e-mail I just got 
refers to an application
to be used for drawing house plans.  Putting aside for a moment the lack 
of appropriate models
etc., I was impressed by how easy it was to adjust the view (rotation, 
zoom, position ...)
with this tool.  Maybe some part of their UI or rendering code would be 
worth looking at?  It appears to allow you to vary transparency as well.

. == October Project of the Month: Sweet Home 3D ==
.
. Sweet Home 3D is free software designed to draw the plan of a home, 
arrange
. furniture, and display the result in a 3D view.
.
. More info: http://sourceforge.net/community/potm-200910/
.

Joe T

> The mechanical part of the system is already captured by the CAD app. So 
> it is a easy to see, if electronics will interfere with mechanics. In 
> addition I can make sure, that the design of the front panel fits the 
> position of the components. 
> This is so useful, that I tend to manually import the electronics into 
> my mechanical CAD. See for example our laser diode driver:
> http://bibo.iqo.uni-hannover.de/dokuwiki/doku.php?id=eigenbau:lasertreiber
> 
> ---<(kaimartin)>---


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

Re: gEDA-user: wcalc-1.1 released

[joeft]

Dan,

I've found this tool useful in the past and was really glad to see the 
CPW model (which I really needed last week!).

A couple questions:
- what are the units for electrical length?
- the Options and Window pull downs don't seem to contain anything - is 
there supposed to be something there or am I missing something?

(I'm running this on Win XP/SP3 - I haven't tried the Linux install yet)

Thanks -

Joe T


Dan McMahill wrote:
> After way way too long since the 1.0 release, I have finally released 
> wcalc version 1.1.  The home page is still http://wcalc.sf.net
> 
> Wcalc is a transmission analysis/synthesis calculator.
> 
> The main changes in version 1.1 over 1.0 are:
> 
> Added series/parallel RC equivalent circuit calculator.
> 
> Added series/parallel RL equivalent circuit calculator.
> 
> Added self and mutual inductance of two rectangular bars.
> 
> Added coplanar waveguide model.
> 
> Added coupled stripline model.
> 
> Corrected the Q calculations for low frequency (not skindepth) region
> in air core inductors.  Also corrected Q calculation for conductors
> other than copper.
> 
> Corrected the calculation of incremental conductance for the
> microstrip model.
> 
> Corrected a bug in the calculation of conductor losses in the
> microstrip model.
> 
> Added/enabled code for calculating conductor losses in the coupled
> microstrip model.
> 
> When compiling with gtk-2.10 or newer, use gtkPrint for printing.
> This gives a more professional/standard print dialog and also enables
> printing under windows.
> 
> Added a preliminary Dutch translation.
> 
> Converted the figures to all use solid grayscale fills instead of
> pattern fills as the former prints better.
> 
> Several updates to the build system to moderize it a bit.  Uses
> AM_CONDITIONALS more appropriately, uses AC_PROG_LIBTOOL instead of
> AM_PROG_LIBTOOL, etc.
> 
> Update the win32 build script to generate an installer that works
> correctly under vista.
> 
> Add .wc file associations under vista.
> 
> Update the octave build infrastructure to work with octave-3.0 and
> newer where mex support is built into mkoctfile instead of a
> standalone mex shell script.
> 
> Switch to GPL licensing.
> 
> Create several utility functions to make it faster to build new gtk
> forms.  This is only visible to developers.
> 
> Improved autogen.sh to check versions of several of the auto* tools to
> help make it easier to diagnose any issues which may come up.
> 
> Repair compilation with the SunPRO compilers.
> 
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 


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

Re: gEDA-user: Tab holes in PCB

[joeft]

Peter Clifton wrote:
> On Fri, 2009-02-20 at 16:20 -0500, Rob Butts wrote:
>> I have a pcb mounted power jack with rectangular bendable tabs.  Since
>>I'm going to try to make this pcb at home I'd like to put these holes
>>in the layout as they are and not round holes with the diameter
>>equaling the widest part of the tab.  Can I make a rectangular hole in
>>pcb and if so how?  How would the Pin statement look?
>>Thanks
> 
> I don't think you can. Lets look at how this "might" be done
> industrially:
> 
> You're no longer talking about a drill hole in the "excellon" sense of
> the word. You'd be looking at a custom manufacturing step involving a
> router, similar to how they cut the outline of a finished board.. only
> this processing step would be done before the through-hole plating.
> 
> I believe you'd have to describe this step using a mechanical layer,
> along with written instructions to the board manufacturer what that
> layer means. It would almost certainly not look like a traditional via
> in PCB.
> 
> I'm not sure how the vendor would want the slot described, it would be
> something you'd have to agree with them up front.

That's it - give them a "layer" or mechanical drawing that shows how you 
want the slot dimensioned.  Show them the largest radius you can deal 
with and let them pick the tool (cutter) that they like to use.

If you can get by with either:
1) a round hole that is plated
   or
2) slot that is not plated
it would be much easier than asking for a slot that is plated.  Routing 
before plating is an extra or non-standard process step for many shops. 
  That said, you can surely find someone to do it - at a price.

Peter is correct.  Talk to them up front to find out what's easy and how 
do document it unambiguously.

Joe T

> 
> It might be a line / other primitives defining the geometry to be cut
> away. It might be a center-line for the tool path, either accounting
> for / not accounting for the cutter diameter.
> 
> I don't know how other CAD software treats such mechanical layers, how
> the slot routing would be rendered. (Would it look like an elongated
> via, for example).
> 
> 
> Best wishes,
> 


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

gEDA-user: [Fwd: Re: Gerbv-2.0.1 for Windows released, but not working!]

[joeft]

Hadn't tried gerbv on windows yet, but I just installed 2.0.1 and it is
quite zippy (in any rendering mode).  But I notice one thing that
doesn't look right:

1) I seem to remember that when using the measure tool it would draw a
rubber band line from the reference point to the current cursor
position.  The "measured distance" values in the status area at the
bottom reflect the correct measured distance, but there's no line or
reference mark to see where I started from.

environment:
WXP SP3, Intel core2 Duo 2.66 GHz, 2GB RAM
graphics on a separate card: ATI Radeon X1950GT w/ 256M DDR3 RAM

Joe T


Stuart Brorson wrote:
> Just following up on my own thoughts
> 
> On Mon, 1 Sep 2008, Rick Collins wrote:
>> Is there a working version of Gerbv 2.0x for Windows?
> 
> Here's an experiment you can try to help out the gerbv team:
> 
> Try installing gerbv-2.0.1 on several Windows machines with different
> video chipsets.   Then run gerbv and switch to "normal" rendering
> mode.  Then see which run at normal speed, and which are dog-slow.
> Then post to this list the chipsets each machine has and also whether
> the speed was normal or unacceptably slow.
> 
> We'd very much appreciate it, since it would allow us to gather some
> data on the speed problem.
> 
> Cheers,
> 
> Stuart
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 







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

Re: gEDA-user: Help ordering pcb

[joeft]

You probably already have them.  It used to be the case that the 
aperture list was a separate file, but PCB includes the aperture list at 
the top of each gerber file.

Look at the file, once you get past some header info, about 10 lines in 
and you should see some lines that look like this:

%ADD18C,0.0280*%
%ADD19C,0.0600*%
%ADD20R,0.0370X0.0370*%
%ADD21R,0.0170X0.0170*%

these are aperture specifications.  There could be a few or dozens, 
depending on the variety of footprints and copper geometries required.

Later you should see the actual photoplot commands which look like this.

G54D11*X37850Y16690D02*X37840D01*
X37550Y16400D02*Y16050D01*
X38050Y18090D02*Y18100D01*
X37800Y18350D01*

pretty much all the way to the bottom.

Joe T

Robert Butts wrote:
> One of the pcb websites claims one common gerber mistake is a missing 
> aperture list.  What is this and does PCB create it?
> 
> On Fri, Aug 1, 2008 at 10:36 AM, Robert Butts <[EMAIL PROTECTED] 
> > wrote:
> 
> Do I need the unplated-drill.cnc file?
> 
> 
> On Fri, Aug 1, 2008 at 9:49 AM, DJ Delorie <[EMAIL PROTECTED]
> > wrote:
> 
> 
>  > What is the stencil layer?  A pcb fab company wants me to
> identify the top
>  > stencil, bottom stencil and outline layer.  Which gerber
> files are these?
> 
> Stencil is probably the silkscreen layer, assuming you can
> figure out
> the other ones are copper and solder mask.  For outline, if you
> don't
> have an explicit outline layer, use the fabrication drawing.
> 
> board.front.gbr
>front side copper
> 
> board.frontmask.gbr
>front side solder (stop) mask
> 
> board.frontpaste.gbr
>front side paste mask
> 
> board.frontsilk.gbr
>front side silk (stencil or ink)
> 
> board.back.gbr
>solder side copper
> 
> board.backmask.gbr
>solder side solder (stop) mask
> 
> board.backpaste.gbr
>solder side paste mask
> 
> board.backsilk.gbr
>solder side silk (stencil or ink)
> 
> board.fab.gbr
>fabrication drawing (human readable, includes outline and
> drill makers)
> 
> board.plated-drill.cnc
>drills for plated-through holes
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org 
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



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

Re: gEDA-user: Gnetlist bom

[joeft]

Ian Chapman wrote:
> Please excuse my post without a subject.
> 
> Hi again, how do I pull a bill of material out of the schematic?  The 
> documentation and Google leave me wondering if it is a work in process 
> and which version of bom I should use.
> 
>  BOM / BOM2 - Bill of Materials (-g bom and -g bom2)
> 
> *
> 
> Partslist 1,2,3 - More Bill of Materials (-g partslist[1-3])
> 
>   Regards Ian.
> 
> 
> 
> 
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

I usually use '-g -bom2'.  You will need an "attribs" file int he local 
directory so it knows what fields to extract from the schematic.  You 
will probably also want to massage the list into a more human-readable 
format, depending on what info you want in the BOM.

Joe T



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

Re: gEDA-user: [pcb] overlapping pin/pad -- won't form thermal

[joeft]

Ben Jackson wrote:
> On Tue, Mar 11, 2008 at 08:39:31AM -0800, Dave N6NZ wrote:
>> Steve Meier wrote:
>>> I am also interested in why you would want a thermal for connecting a
>>> via onto a pad in which the via is sitting.
>> ?? OK, I'm still under-caffeinated, but I don't parse your question. 
>> I'm guessing you missed my initial rant?  What I was trying to do is 
>> create an oblong pin to ease hand soldering.  So I created a pad 
>> overlapping a pin to create the desired shape.  The whole effort 
>> foundered because pcb won't create thermals on the resulting oblong pins 
>> -- pcb give the pin a thermal flag, but the thermal doesn't render 
>> because of the overlapping pad.
> 
> You can't thermal it to a surface layer, but you can thermal it to an
> inner layer.  You've always had to draw lines to pads to connect to any
> surface polygons.
> 

I think that what this implies is that you can't build a plane layer on 
the outside of a board )like an outside ground plane) with PCB?  I used 
to do this all the time with other tools when designing RF circuits. 
Connecting up a bunch of polygons sounds a little tedious.

Joe T


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

Re: gEDA-user: [CTRL-s]

[joeft]

Peter Clifton wrote:
> On Tue, 2008-03-04 at 12:17 +, Kai-Martin Knaak wrote:
>   
>> Now that gschem knows about [ctrl-c] and [ctrl-v]. Why not also support 
>> save with [ctrl-s]?   
>> 
>
> Surely is should be ":w" ;)
>
> Send a patch, and if no-one objects I'll push it.
>
>   
Hmmm.  What happens if you were trying to automate some processing w/ 
PCB via a script and it encounters a ctrl-s in the input stream?  Maybe 
putting ctrl-s and ctrl-q (x-on, x-off) in as hot-keys isn't a good idea?

(I do like the ":w" idea however :) )

Joe T


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

Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such

[joeft]

>Now, to generalize to things other than simulation netlists..
>
>To represent a layout, "types" might say whether it is a via, 
>trace, fill block, footprint by name.  The attributes are 
>length, width, forms, scaling.  The connections are physical 
>locations.  This is the same info that is in a PCB file now.  
>(or any layout program)
>  
>
Add a type "module" or something that allows a collection of primitives 
to be addressed as an entity of it's own.

Also add as attributes rotation and mirroring (to apply to module)

Joe T



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



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

Re: gEDA-user: usb jack footprints

[joeft]

David Griffith wrote:

>Does anyone have footprints for USB jacks?
>
>  
>
I see that John has already chimed in, but here's another option:

Please also keep in mind the necessity for proper grounding and RFI 
performance.  There are app notes from Intel and Cypress which offer 
some guidance.  (search for Cypress AN1168, " High-speed USB PCB Layout 
Recommendations").


Joe T


Element["" "Connector, USB, rt angle" "J?" "CON_USB_RT" 373500 300500 
-17700 -8600 0 80 ""]
(
Pin[0 0 6500 2000 7500 4600 "" "1" "square"]
Pin[0 9800 6500 2000 7500 4600 "" "2" ""]
Pin[7900 9800 6500 2000 7500 4600 "" "3" ""]
Pin[7900 0 6500 2000 7500 4600 "" "4" ""]
Pin[18540 -18700 11800 3500 12800 6700 "" "5" ""]
Pin[18540 28500 11800 3500 12800 6700 "" "6" ""]
ElementLine [-7700 28500 10700 28500 1000]
ElementLine [-7700 -18700 10700 -18700 1000]
ElementLine [-7700 -18700 -7700 28500 1000]
ElementLine [26000 28500 26500 28500 1000]
ElementLine [26500 -18700 26500 28500 1000]
ElementLine [26000 -18700 26500 -18700 1000]

)


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

Re: gEDA-user: sloppy rupper band mode

[joeft]

Ben Jackson wrote:

>On Sat, Oct 20, 2007 at 10:32:57AM -0700, joe tarantino wrote:
>  
>
>>On 10/20/07, Ben Jackson <[EMAIL PROTECTED]> wrote:
>>
>>
>>>1)  If you move a line or its endpoint:  For purposes of rubberbanding,
>>>it is considered connected to all of the line segments whose ends overlap
>>>the moving line's end(s).
>>>  
>>>
>>That appears to be the problem: Either that it is picking the wrong segment
>>or that it is leaving one of the endpoints behind (unpicked) that belongs to
>>the short segment.  In the case that Kai-Martin showed earlier in this
>>thread, there are three segments and 4 endpoints in the "pick region" that
>>must be sorted through.  It seems as if one of the endpoints gets dropped.
>>
>>
>
>New illustration  A-BC-DEF, where B=C, D=E and B,C,D,E overlap
>
>Well, that's what we've got to decide.  Either the bug is:  one gets
>dropped, meaning the "right" behavior that dragging segment EF should
>move points B, C, D along with E.  OR the bug is too many get included,
>meaning the "right" behavior that dragging EF should only drag D.
>  
>
The more explicit illustration helps...

I agree.  Either it should drag D with segment EF (my preference; it is 
simpler and more useful) or it should drag B,C,D along with segment EF( 
not preferred - it prevents stretching segment CD).  In the past I 
believe it was
dragging B & D along with segment EF, which was not useful.

>I favor the latter, but I am not sure what the rule is by which I'd
>exclude B.  Excluding C is easy, since we search by line I see C and D
>at the same time.  In fact, I'm not sure the rest of the code would cope
>if you added BOTH C and D.
>
>  
>
>>I think you've found the issue with the lines overlapping (i.e. adjacent
>>vertices being closer together than the line width).  What about ignoring
>>the line width while choosing the proper endpoint in the case when the
>>endpoints are closer together than one or two line widths?
>>
>>
>
>That makes it easier to pick D when considering segment CD, but you can
>get the same result by simply picking the closer point.  I already made
>that fix in my view when I noticed it was picking the "first" end every
>time.  It's not much of an improvement, though.  You still get the weird
>3-line-V structure.
>
>[snip a discussion of how crosshair position could be used to select one
>of the two solutions I described above]
>
>  
>
>>Quite
>>often I generate these short lines by routing with "snap to pins/pads"
>>turned on.  Then you are almost always guaranteed to cause a tiny segment to
>>occur right at the end (often "inside" the pad).  In this case, if there is
>>a point that is exactly on the pin or pad and the pin or pad is moved, only
>>the line endpoint exactly on the pin or pad should move.  (Yes, I realize
>>that this may be difficult to do given the way the data is stored.)
>>
>>
>
>Interesting preference.  I'm thinking of SMT pads that end up like this:
>
>+-+
>|  C--|---D
>|   A B   |
>| |
>+-+
>Where A and B are the points defining the pad and BC is the stubby segment
>that steps onto the grid.  When you move that now, one endpoint of BC
>stays behind.  The other endpoint along with the C-end of CD.  You end
>up with one crazy diagonal connecting line CD and one line from B back
>to approximately wherever the pad used to be.  That seems pretty useless
>to me.  Actually, the initial creation of BC seems pretty useless, since
>it adds nothing in the end.
>  
>
Creating the short segment (B-C) is a result of snapping to an off-grid 
pad.  Stretching this segment means moving point C, regardless of 
whether it was inside or outside the boundary of the pad to start with (?)

The situation I run into more often is that the pad points (A,B) are off 
grid, as is C, while D is on grid, but C is outside the pad (see 
below).  It may be simpler than the case you have drawn.  This is the 
picture that represents what I usually see.  Point C is off grid in 
either case.

+-+
| |   D
|   A B---|-C
| |
+-+

Joe T

>>The 3+ line intersection case would be farther down my list.  I don't
>>encounter that too often unless I'm building up a  "geometry" like a
>>transmission line or taper.
>>
>>
>
>I think the way I'm leaning now is to let the 3+ line case break or
>behave oddly and fix the bug by simply taking the one closest endpoint
>when doing line-to-line rubberbands.
>
>  
>



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

Re: gEDA-user: sloppy rupper band mode

[joeft]

Kai-Martin Knaak wrote:

>Rubber band mode is (still) much too sloppy about the decision which 
>segment endpoints to move. 
>
>Imagine a short segment between longer ones like I constantly get because 
>of the metric/imperial nuisance. Thes almost never rubber move in a 
>decent way. Suppose a track looks like this:  
>_
>1   2\_
>  3
>If I drag the top corners at segment 2 there are two sensible rubber 
>modes: 
>a) Segment 1 and 2 stretch. Segment 3 stays in place.
>b) Segment 1 and 3 stretch. Segment 2 moves a matching amount, no stretch
>
>However, rubber band mode almost invariably chooses a third mode: 
>c) All three segments stretch. 
>
>This results in
>
>/|\
>   / | \
>  /  |  \
> /   |   \
>/1  2|   3\
>
>This is rarely a useful transform.
>
>---<(kaimartin)>---
>  
>

I agree completely with your suggested behavior and with the statement 
that what it does now is rarely useful.  My approach usually involves 
deleting the whole mess (all three segments) and starting over.

This problem has been there as long as I can remember (several 
years/versions).  It is affected by things like:
-  the distance (relative to grid spacing) of the two vertices (the ends 
of segment 2 in this example)
- the width of he lines themselves
I believe the problem is in the logic or distance calculations which 
look for the nearest vertex to the selection point.  I think you will 
encounter it most often when the vertex spacing is less than 1/2 line width.

If you haven't seen this problem, your board isn't dense enough :).

There was a bug report submitted on this issue well over a year ago.  
There was also a partial fix submitted to the developers' list at that 
time.  As far as I ever saw, neither got any attention.  In my opinion, 
this is the one of the most serious flaws that PCB has since it can 
cause so much re-work.

Joe T




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

Re: gEDA-user: PCB paste layer, revisited.

[joeft]

Dave N6NZ wrote:

>DJ Delorie wrote:
>  
>
>>>Imagine, that you have a 431 pin BGA. Would you include 431 times
>>>the same padstack in the footprint? I think one should bother with
>>>the whatever shape, and size of the stencil, copper, mask, paste
>>>layers. Those are just "pads".  Then we could link pads to a
>>>padstack, and the padstacks into the footprint.
>>>  
>>>
And footprints into the layout.  It's a hierarchy with everything 
instantiated rather than embedded.  This is the way many (most?) large 
commercial tools work.  The layout editors I used 25 years ago were 
built this way.  I realize it is a significant shift from the paradigm 
and the format of PCB's current data, but it is the direction we should 
be moving.  And I would also second the earlier comment regarding the 
need for a more general "layer" definition to facilitate paste, clearing 
of solder resist 

>>For sanity's sake, let's let a footprint define its pad stacks for its
>>own pads, rather than trying to maintain a global cache of padstacks.
>>
>>Then, a BGA footprint would have one "here's what my pads look like"
>>and 431 copies of "put one here".
>>
>>
>
>Yup.  Right answer.
>
>A footprint needs to be entirely self-contained.
>  
>
I can't agree.  There is no reason to have a pad stack (and drill and 
keepout and paste and...) defined in every footprint that uses a certain 
size pad or pin definition.  How many places do we need to have copies 
of a pad suitable for a .5mm pitch QFP when every such QFP needs the 
same pad geometry? 

One reason to have the pad stacks separately defined and simply 
instantiated in the footprint is to account for a process or fab vendor 
change.  So you want to convert your "library" to RoHS-compliant 
soldering process and the recommended paste patterns need to change.  
I'd much rather edit a pad stack definition once than go through every 
footprint that uses it to make the change.

Joe T.

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



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

Re: gEDA-user: Updating footprints in place

[joeft]

This question has come up in the past.  Dig back in the archives and 
look for a posting from David Rowe.  He generated a script which can do 
footprint replacement in certain situations.  It may be available from 
his web site.  I have used it with success with a number of surface 
mount footprints.

Caveats: make sure the file formats (co-ordinates etc.) are the same for 
the old and new footprint.
Keep a backup copy of your original file!
Full disclosure: I contributed some tweaks to this script - if it breaks 
you can blame me:).

Joe T

Randall Nortman wrote:

>On Sun, Oct 07, 2007 at 12:45:47PM -0400, John Luciani wrote:
>[...]
>  
>
>>You could definately do it with a script but unless you have a lot of 
>>footprints
>>to update or have to update a number of layouts it may not be worth it.
>>
>>
>
>Well, if the script is generic (rather than hard-coding which
>footprints you're looking for), it only ever has to be written once,
>and then used for many different footprints/layouts.  The hardest part
>is searching paths for the updated footprints -- that part could be
>ripped from gsch2pcb (except that's written in C and this is a natural
>job for a higher-level language).
>
>
>  
>
>>The cleanup after the script finishes may be more difficult than the cleanup
>>prior to doing a manual replace.
>>
>>
>
>If footprint changes are minor -- clearances, mask, silkscreen, etc.,
>then cleanup should not be too bad.  If you change pad widths or
>lengths, you might have problems.  If you change the internal
>coordinate reference, fuggedaboutit.
>
>
>  
>
>>If your components are on the grid manual replacement goes quickly.
>>
>>
>
>Well, that all depends on what "the grid" means.  I usually end up
>with boards that have components on different grids, and I often set
>up a module/cluster of components on one grid, then select and move it
>as a single mass, possibly onto another grid, and so the components
>then end up on a fractional grid of some sort.  This is particularly
>likely when I'm using a metric grid on one module and imperial on
>another.  The part I'm looking at right now ended up with its center
>on (1410.50,409.10), for one or both of those reasons (I can't really
>recall).
>
>For now, I have fixed my immediate problem with the power of emacs.
>Maybe I'll write that generic script, someday.
>
>  
>



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

Re: gEDA-user: Request for comments

[joeft]

Steven Michalske wrote:

>On Sep 11, 2007, at 2:49 PM, andrewm wrote:
>
>  
>
>>Steve,
>>
>>Sure I can do a bug/feature request on this (after I
>>read up how too).
>>
>>Just want to make sure that it is something wrong or
>>something people want.
>>
>>Should the two pins same-named be treated as a single
>>entity so they can be used like a jumper or should the
>>connection have to be made manually in the schematic
>>and the pins be named differently.
>>
>>
>>
>
>My feeling is that if pins are numbered the same then they are  
>electrically connected in the part.
>  
>
True.

>
>an example is the 4 mounting pins on a SMA to PCB jack  the 4 outer  
>pins are electrically equal,  you can attach to any of them they are  
>the same net
>
>PCB wanted all 4 pins connected...  but electrically only one needs  
>connection.
>  
>
Not true.  I would never use this type of connector and only connect one 
ground pin.  Add in the
parasitic inductance of the pins and then see if they are electrically 
equal.

>
>Some discussion could be put into this.
>
>do we want sub pins for the net of pins
>so on a SMA example
>
>the center conductor would be pin 1
>the 4 mounting pins would be pins 2.1, 2.2, 2.3, 2.4
>  
>
I don't see the necessity of this.  When I build parts with multiple 
pins all of which I want connected
I give them different numbers.  There may be other types of examples 
where this is needed but I've
never hit one.

thoughts from Joe T.

>so if the net specified connect to pin 2   it would make a electrical  
>connection to any of the pins and be done
>
>if you specified that it was pin 2.1 it would connect to that sub pin.
>
>if you specified 2.*  it would require connection on all sub pins.
>
>this would provide for the most options in how to handle internally  
>connected pins with the same numbering.
>
>
>thoughts gang?
>
>Steve
>
>
>___
>geda-user mailing list
>geda-user@moria.seul.org
>http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>  
>



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

Re: gEDA-user: Some Linux distros to consider

[joeft]

Jason Elder wrote:


.

Conclusion -
1.  OpenSUSE works well, the development packs need to be installed 
post-install (I opened the software installer and selected every 
package that had development in the name).
2.  Slackware - This distro should work well...I think that if you 
choose full install, it installs all of the packages including the 
development ones.  You may also want to choose the GNOME desktop as 
your default desktop during installation. 
3.  Ubuntu - This distro should also work well, just be sure that the 
devel packs are installed or be sure to install them post-OS install.


I'm pretty sure gEDA will work well with any distro out there.  My 
goal here was to find one that I can download, burn, install, have the 
latest version of firefox and openoffice, and then install gEDA with 
minimum hassle.  Also, I've been following some of the distros on 
distrowatch.com and I think many new distro updates will have the 
latest version of firefox and openoffice.  I just wanted to get up and 
running with gEDA.




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



I also recently installed geda on SuSe 10.2.  Had some problems with the 
SuSe net install due to ftp timing out; it went much better from the CD 
images.  geda install went much more smoothly than in the past (Thanks 
Stuart!).  Have run gschem, pcb, and gerbv only so far.


My last challenge was to see if I could build lesstif hid version of 
pcb.  I can't seem to find all the dependencies missing on the SuSe 10.2 
distro.  Anyone have any hints?


Thanks,

Joe T



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

Re: gEDA-user: installation

[joeft]

Stuart Brorson wrote:

My experience has been that if you are missing some system 
dependencies, the first expect session will always fail, whether 
running as root or not.  This may be unique to the openSuSe 
distributions, but I don't think so.  It is more likely just an issue 
exposed by the fact that the openSuSe installations have less of the 
system dependencies installed out of the box.  Maybe the SuSe 
distributions are the best way to test the installer :)?



In general I do test on SuSE 9.3, 10.0 and 10.1, and the installer
does work on those platforms.

As for the dependency installation failing:  I have seen failures due
to several causes:

*  Users running as root.  The expect session wants to see "assword:"
when it tries to log in as root.  If the user is already root, then
the computer doesn't ask for a password.  Therefore, the expect
session just hangs, waiting for the "Password:" which never comes. 
Solution:  Don't install as root.


*  Non-english users.  This one was interesting.  A German user had
the expect session hang immediately after he started the dependency
install.  The reason was that his box asked for his password as
"Passwort:", the German word.  The expect session was waiting for
"Password:".  Therefore, it hung, waiting forever.  I haven't done
anything to fix this yet.  The fix will be for the install wizard to
set the local environment to English only upon startup.  I haven't
implemented this yet because I am not sure what kinds of problems that
might cause (what happens if no English translations are installed?)


Yikes!  Thankfully I can only speak English (and that's on a good day).



*  The WTF catagory.  In this catagory are some occasional,
intermittant failures I see in my testing.  I don't know exactly what
causes them, but I suspect timing issues withing the call/response
process of the expect session.  With the last CD I upgraded the expect
package, so I'm hoping this problem will just go away.  But I haven't
thoroughly verified that yet, either by verifying the design, or by
rigorous testing.


I'm just about to install on SuSe 10.2.  I'll let you know what happens.

Joe T



Stuart

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





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

Re: gEDA-user: Design Flow Roadmap starting point

[joeft]

Igor2 wrote:


On Sun, 18 Mar 2007, al davis wrote:

 


*  Finally, how should PCB behave with a hierarchical
schematic?
 

Right click on a symbol, select "go inside", and another drawing 
opens up showing what's inside.  gschem also should act this 
way.
   



I like this idea very much. In case of PCB it also would make sense to
add a way to display in place what's inside. With an "expand
all" functionality this would allow one to see the whole pcb with all
inner structures at once, without needing to export to ps.
 

The ability to "look inside" or "expand all" is a feature that is 
standard for IC layout editors.  Years ago I used a PC board editor that 
evolved from an IC layout tool and it had this behavior.  In particular, 
you could create sub-blocks of circuitry that might represent individual 
"devices" (or elements in PCB parlance) or more complex blocks that you 
might want to repeat.  You could add these to your layout (with up to 
256 levels of nesting).  You could turn on/off the visibility or 
"editability" of any device at a lower or higher level of nesting than 
the one you were currently working in.  When "editing down" to a lower 
level device it would leave all the surrounding features (the "context") 
visible so you see what you were doing.  Other copies of the current 
block could be immediately displayed with the changes you just made.  
Needless to say, this implementation of heirarchy allowed for some very 
complex designs and much easier re-use than we have now.


Joe T





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

 





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

Re: gEDA-user: installation

[joeft]

Stuart Brorson wrote:


On Sun, 18 Mar 2007, Jason Elder wrote:


Hi, I'm having trouble with the installation, but I don't know if
this should be posted hereI just downloaded the new version
20070221 of gEDA and I was wondering how I can install it as root.



Do not install as root.  If you install as root, and you need to
install system-wide dependencies, the installer becomes confused when
it tries to fire up an expect session as root.


My experience has been that if you are missing some system dependencies, 
the first expect session will always fail, whether running as root or 
not.  This may be unique to the openSuSe distributions, but I don't 
think so.  It is more likely just an issue exposed by the fact that the 
openSuSe installations have less of the system dependencies installed 
out of the box.  Maybe the SuSe distributions are the best way to test 
the installer :)?


Joe T.



Old versions of the installer didn't check to see if the user was
root.  Then, users running as root would find that the installer
failed when it tried to install system dependencies.   Therefore, I 
implemented a check to verify that the user was *not* running as

root.  This change went in to the 20077221 installer (IIRC).

In general, using your Linux box in root all the time is dangerous,
and is considered bad form.  You can make a mistake and harm your
system running as root all the time.  Run as a regular user.

Stuart


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





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

Re: gEDA-user: installation

[joeft]

C P Tarun wrote:


Do not install as root.  If you install as root, and you need to
install system-wide dependencies, the installer becomes confused when
it tries to fire up an expect session as root.



Now I'm confused. In all these years of working on Unix, I've always
thought packages need to be installed as root. How else will you keep
the binaries in a place like /opt or /usr/local where all users of your
system can access them?


In all my (almost 30) years of working on Unix systems this is what I 
always thought as well.  Especially on systems used by more than one 
user (which is/was usually the case).  I don't see how installing system 
dependencies as other than the root user will work in general, 
especially if any of those dependencies are expected to be available to 
other programs sometime in the future.


Joe T



--


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





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

Re: gEDA-user: pcb program

[joeft]

Seb James wrote:


On Mon, 2007-03-12 at 14:10 +, Seb James wrote:
 


On Sat, 2007-03-10 at 17:38 +, Seb James wrote:
   


On Fri, 2007-03-09 at 19:14 -0800, Harry Eaton wrote:
 


I've fixed the problem in rats.c; Just grab the latest
cvs.

h.
   


Thanks Harry. I'll have a look at that on Monday morning, if not before.

 


Unfortunately this patch doesn't fix the problem where the rats-nest
layer gets mis-drawn as blocks of colour.
   



I've been connecting components up without the need of the rats nest
(rows and rows of repeated circuits), and have brought the number of
rats-nest lines down to less than about 2000 (currently 1751). 


It looks like the "filling up the screen with colour" rats nest problem
has disappeared as a result of the reduced number of rats-nest lines.

Seb

 

I believe I've seen the same issue.  In both of the last two designs I 
did I had problems when there were still a lot of unrouted nets (rats) 
remaining in the design.  In addition to filling up the screen with 
color (especially at larger zoom factors), pcb would crash reliably if 
there were too many rats attached to one net (like ground). 

I've also seen problems were, after drawing or optimizing the rats-nest, 
a shorted net was reported in the log window which was bogus.  In one 
case a short was reported when all pins supposedly attached to that net 
had no traces routed to them.  In other words, it was telling me that 
pins not connected to anything were somehow shorted to the wrong net.  
Completing other connections in the design made the problem go away.


Joe T


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

Re: gEDA-user: Google Summer of Code on gEDA Webpages

[joeft]

Werner Hoch wrote:


Hi Ben,

On Saturday 10 March 2007 22:47, Ben Jackson wrote:
 


On Sat, Mar 10, 2007 at 09:53:07AM +0100, Werner Hoch wrote:
   


I'm currently drafting a better spice integration into gschem.
Maybe that could be a project, too.
 


Anyone who is thinking of improving a spice GUI has got to try
Linear Technology's free SwitcherCAD (aka ltspice).  It's the nicest
spice I've ever used.  It's a better schematic entry program than
most, too (and that would include Eagle and gschem).
   



I've played with LTSpice an hour.

Things I like:
* the current and voltage probing (visible marks are missing)
* all entries (simulations and voltage sources) are done with dialog
  widgets and also printed in plain text. 
* changing the model of a diode or transistor

* the property dialog for each circuit element (right mousebutton)

Things I don't like:
* schematic entry (selecting, moving, ...)
* only one simulation at a time.
  This is o.k. for tinkering, but not for real work. I hate it when
  using PSpice (schematics) at work. You can't split your workflow into
  entry, simulation and postprocessing with it.

Regards
Werner

 


While LTSpice can be ease at first approach I've found:
- building your own devices (subcircuits which have their own symbols) 
can be tedious.  You have to do things in two or three places.
- the simulator has had some serious convergence problems (using the 
models for some of their own switch mode power supply controllers!).  I 
keep an older version of the program around just in case I update to a 
broken version.


Joe T


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

Re: gEDA-user: freedog pictures

[joeft]

DJ Delorie wrote:

  I think one good way to approach this would be to pitch the *file  
format*, not the software...at first.  The industry has proven that  
it will standardize on file formats (witness Gerber RS-274X) if they  
work well.  Granted the Gerber format (as far as I know) really  
became well-accepted because equipment that used it was popular, but  
I'm not sure that matters all that much.
   



I think the footprint format would need a lot more flexibility if it
were to be accepted elsewhere.  For example, the ability to have
polygon pads, or different pin diameters on different layers, or paste
patterns for heatsinks.
 



Yes!
And...
Solder resist patterns that are independent of pad definitions.
And most importantly - handling footprints the way that gschem handles 
symbols.  There needs to be a way to instantiate or reference footprints 
*without* embedding them completely in the board file


Joe T



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

 





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

Re: gEDA-user: Installer suddenly dying on Mandriva 2007.0

[joeft]

Al Hooton wrote:


This is on a vanilla install of Mandriva 2007.0.  I have looked through
the list archives, the INSTALL information and googled around, but I'm
stuck.  Hopefully somebody here has the answer as to why the installer
just suddenly gives up near the beginning of things.

I downloaded the gEDA installer ISO about a week ago and burned it to
CD (yes, I just noticed there is a new installer ISO that went up in the
last couple of days, but before I try it I'd like to know if the
following is a known problem or not).  When it gets to the point of
determining that it needs to install readline it asks me for the root
password, waits a couple of seconds, then the installer just disappears.
Here's what I get with both --log and --verbose on the installer command
line:




This is the log window which will display the
spew generated by the installation process



gEDA Installer -- version 20061214,
Copyright (C) 2004 -- 2006 Stuart D. Brorson.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details:
http://www.gnu.org/licenses/gpl.html

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307,
USA.


First check if I am running as root.

whoami
  al
Checking for various required programs . . .

which gcc
  /usr/bin/gcc

which make
  /usr/bin/make

which gtk-config
  which: no gtk-config in
(/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/usr/lib/qt3//bin:/home/al/bin:/usr/lib/qt3//bin)
gtk-config is missing on this machine.
We'll tell the user about that in a minute.

which pkg-config
  /usr/bin/pkg-config
pkg-config version 0.20 found.
pkg-config version found on this system is good.  Great!

find /usr/include /usr/local/include -name 'readline.h' -print | grep
'include/readline/readline.h'
  
We need to install readline.h on this machine.  We'll do that in a

minute.

which gettext
  /bin/gettext

which autopoint
  which: no autopoint in
(/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/usr/lib/qt3//bin:/home/al/bin:/usr/lib/qt3//bin)
We need to install autopoint -- a component of the gettext system -- on
this machine.  We'll do that in a minute.

which gdlib-config
  which: no gdlib-config in
(/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/usr/lib/qt3//bin:/home/al/bin:/usr/lib/qt3//bin)
We need to install gdlib-config on this machine.  We'll do that in a
minute.

which guile
  /usr/bin/guile

which guile-config
  which: no guile-config in
(/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/usr/lib/qt3//bin:/home/al/bin:/usr/lib/qt3//bin)
We need to install guile-config on this machine.  We'll do that in a
minute.

which wx-config
  which: no wx-config in
(/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/usr/lib/qt3//bin:/home/al/bin:/usr/lib/qt3//bin)
We need to install wx-config on this machine.  We'll do that in a
minute.

which wish
  /usr/bin/wish
tclsh version 8.4 found.
tclsh version found on this system is good.  Great!


Preparing to install the readline headers. . . . 


Now start process of building and installing readline.h.

I need root in order to execute this command.


   ---  Starting expect session  ---
Sending su
Timeout waiting for password prompt
Spew received up to now: Password:




That's it -- the installer just stops.  Anybody know what's happening?

Thanks!

-Al





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

 

I've had this same problem with the 20061214 installer, and with the 
previous 2 releases.  Haven't tried Stuart's latest release yet.  I run 
this on SuSe 9.3.  My solution was to manually install readline and the 
other system packages needed.  You can run the installer as root but 
this is not recommended according to the installer documentation.  It 
tends to break things later in the install process..


Joe T


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

Re: gEDA-user: Footprint for an SMT chip resistor array

[joeft]

DJ Delorie wrote:

We've used the EXB-28V series on several boards.  With some feedback 
from one of our board stuffers the footprint solders very repeatably.  
   



What was the feedback, if we may ask?


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

 


As I recall, it involved
(1) Increasing the size of the 4 corner pads.  The Panasonic data sheet 
doesn't do a good job of describing the optimal land pattern.  The end 
pads are really quite a bit larger than the middle pads.
(2) Modifying the solder resist to prevent any thin slivers from showing 
up between the pads.
(3) Sightly reducing the amount of paste on the pads.  I didn't do much 
with this since the bloat/shrink for the paste pattern relative to the 
mask opening seems to be global and I didn't want to mess up any of the 
other small parts on the board.


Obviously these tweaks are relative to the pad design I started with 
(don't remember where it came from).  It has silkscreen under it for 
polarity indication which you might want to remove.


The last board I put this footprint on came out looking very nice.

Joe T


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

Re: gEDA-user: Footprint for an SMT chip resistor array

[joeft]

Michael Sokolov wrote:


Dan McMahill <[EMAIL PROTECTED]> wrote:

 

take a look in the ~panasonic library for footprints like 
PANASONIC_EXB14V.  Those are the panasonix EXB series of SMT resistor 
arrays.
   



Thank you Dan, that's exactly what I was looking for!  And they are M4
footprints, yay!  I love M4!  I adore M4!  (Right now I'm in the process
of reworking pcblib to work with The Real Thing, Dennis Ritchie's
original M4 from UNIX Version 7, instead of GNU M4.  I can't stand cheap
copycats.)

A question though.  Looking at this family of footprints and the
corresponding pages of the Digi-Key catalog, I see that I have a number
of choices.  EXB18V, EXB28V, EXB38V, EXBN8V and EXBV8V will all do the
job.  EXB18V is a bit too small for me, so I'll exclude it from my
consideration, and I have yet to decide whether I want the smaller
28V/N8V or the larger 38V/V8V.  But the really tough one to decide for
me is whether to go with the 28V/38V style or the N8V/V8V style.  Would
anyone happen to have a suggestion as to which is generally better /
easier to work with etc?

Thanks,
MS


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

 


Michael,

We've used the EXB-28V series on several boards.  With some feedback 
from one of our board stuffers the footprint solders very repeatably.  
It's a newlib-style footprint, not m4.  Let me know if you want me to 
post it.


Joe T. 



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

Re: gEDA-user: [pcb] text line size fixed

[joeft]

DJ Delorie wrote:


I added the code needed to make text on the copper, silk, and pinout
be constrained according to the right DRC rule (min line, min silk, or
none).

Now text on the screen looks just like text on the board.


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

 


YES!  Many thanks for tackling this one - it will be a great help!

Joe T.


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

Re: gEDA-user: PCB - grid dots not visible when board is flipped.

[joeft]

DJ Delorie wrote:

This bug has been there for several months.  I looked through the code 
and figured out that it is related to the code that "flips" the view to 
the solder side.  I believe it is only broken in the GTK hid.  I 
submitted a bug report but I don't think anyone has looked at it yet.
   



FYI we're looking for a GTK programmer :-)
 

Yikes!  I would not be the person you're looking for.  In any case, this 
problem is not in the GTK interface per se.  I think what happened is 
that when the lesstif version implemented the left-right flip (vs. 
up-down as it worked previously) there was something that didn't 
propagate back into the GTK code. GTK never did the left-right flip.  
The GTK hid code now checks (incorrectly) to find the viewport 
boundaries and comes up with a result that says there is no grid to draw 
(since it would not be visible anyway).  I hacked in a way around the 
problem (since I like seeing the grid on the back).  Please see the bug 
report for a more concise description.


Joe T



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

 





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

Re: gEDA-user: PCB - grid dots not visible when board is flipped.

[joeft]

KURT PETERS wrote:

I'm sure someone else has noticed this.  I'm using one of the latest 
CVS releases (December-ish) and noticed that the grid dots only show 
up on one side of the board.  Does anyone else notice this?  Is this 
on the "bug list"?

Regards,
Kurt



This bug has been there for several months.  I looked through the code 
and figured out that it is related to the code that "flips" the view to 
the solder side.  I believe it is only broken in the GTK hid.  I 
submitted a bug report but I don't think anyone has looked at it yet.


Joe T






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





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

Re: gEDA-user: how to covnert netlist to schema

[joeft]

ludovic smadja wrote:


Hi,

I've lost some sch file (which are now garbaged) but netlist are ok.

Is there a way to convert a netlist to a schema (a basic schema) ?

regards,
--
Cordialement,

Ludovic SMADJA

You may be out of luck.  The netlist only contains a small subset of the 
information that was probably in your schematic.  It does not help you 
to figure out what the schematic symbols looked like or where they were 
placed on the page etc.  The netlist could be a great deal of help in 
checking or verifying a re-generated schematic however.


If you had also generated a BOM however, a lot more of the modified 
attributes could be captured there.


Joe T







This message was sent using IMP, the Internet Messaging Program.





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





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

Re: gEDA-user: rs232 ferrite size?

[joeft]

DJ Delorie wrote:


What's a good size ferrite to use on an rs232 line?  I've got a spot
for a set of 0603 ferrites on my serial console lines, but I have no
idea what size (uH) ferrite to use.
 

The ferrite bead impedances are usually specified by a graph showing 
both the resistive and reactive impedance vs. frequency.  Choose your 
curve based on what frequencies you want to filter.


One part we use a lot is a Murata BLM18AG102SN1.  They are available 
from DigiKey.  This part has a fairly high resistive component, chosen 
specifically for our use mainly as a power supply filter.  It would also 
be appropriate for slower data signals like RS-232.  If you were 
concerned about too much filtering at higher frequencies, they have 
other parts in this family with less of a resistive component.


Joe T



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

 





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

Re: gEDA-user: Some pcb pecularities

[joeft]

Harry Eaton wrote:


--- DJ Delorie <[EMAIL PROTECTED]> wrote:

 


1) Long lines do funny things if zoomed in a lot.
 


I've recently seen short lines and arcs get exploded
in the lesstif
version too, but haven't tracked it down yet.
   



The "new" GUI drawing code simply scales the line and
then converts the (now overflowed coordinated) to
short ints and sends them X to render. Before the HID
came along, there was clipping code that prevented
this coordinate overflow and thus produces correct
drawing (usually).  But the desire for eye-candy and
"fluff" won out over correctness.  Presenly in CVS
only *polygons* are always rendered correctly
regardless of zoom level.

 



 


3) Auto router and manual line drawing tool
 


interpret line clearance
   


differently. If clearance is set to 10 mil for a
 


particular route style,
   


the auto routed lines will punch a 10 mil gap into
 


polygons. With manually
   


drawn lines the gap is just 5 mil. I'd say, the
 

auto router is correct. 


According to the documentation, "clearance" is the
amount added to the
thickness of the line, so a 10 mil clearance should
result in a 5 mil
gap on each side of the line.  At least, that's what
the file format
spec says.
   



The file specs are for the file. The GUI interface
should define clearance as the gap on each side.
Just like "join" is compliment of clear-line, there
are some historic strangenesses in the file format,
but they should only apply to the file format.  I
believe the current CVS has the clearance correct for
both manual and auto-routed lines.


 


4) Rubber band move of automatically generated
 


vias results in a mess of
   


tracks. Some tiny tracklets seem to be expanded
 

rather than moved. 
   



One end stays where it was and the other moves with
the via - the definition of rubber banding. Still,
it's not what the user wants. This is already an open
bug on the SF tracker.
 

I think this is what the user wants - as long as it's the correct end of 
the correct line that is being moved.


Joe T






Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.

http://autos.yahoo.com/green_center/


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

 





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

Re: gEDA-user: Re: Some pcb pecularities

[joeft]

Kai-Martin Knaak wrote:


On Wed, 17 Jan 2007 11:20:00 -0500, DJ Delorie wrote:

 


3) Auto router and manual line drawing tool interpret line clearance
differently. If clearance is set to 10 mil for a particular route style,
the auto routed lines will punch a 10 mil gap into polygons. With manually
drawn lines the gap is just 5 mil. I'd say, the auto router is correct. 
 


According to the documentation, "clearance" is the amount added to the
thickness of the line, so a 10 mil clearance should result in a 5 mil
gap on each side of the line.  At least, that's what the file format
spec says.
   



Sorry, I confused manually and auto routed tracks (see the other post). So
it seems the autorouter acts according to the file format spec. Meanwhile
the manually routed tracks follow common sense ;-) Anyway, both should act
the same.


 


4) Rubber band move of automatically generated vias results in a mess of
tracks. Some tiny tracklets seem to be expanded rather than moved. 
 


Have you tried running the optimizer after autorouting?
   



This is about manually routed tracks with vias inserted on the fly after a
change of layers. I tried the optimizer anyway, but to no avail. The mess
seems to occure only, if there are short tracks completely hidden under
the via.

---<(kaimartin>)---
 

This item (4) is (I believe) due to a bug that is most often seen when 
there are short segments (as you mention above) and often where the 
spacing between vertices is near to or smaller than the grid spacing or 
the line width is close to (2*grid spacing).  What is happening is that 
it is picking the wrong end (vertex) of some of the short segments and 
moving them  Picture 3 line segments spanned by 4 vertices (A,B,C,D).  
A-B and C-D are relatively long, while B-C is shorter then the line 
width.  If you try to move segment C-D or vertex C it looks like it 
selected vertex B instead.  (This is easier to draw than describe:).  It 
is not an issue with automatically generated vias, the key is simply 
having short line segments.   We looked into this several months ago and 
figured out part of the problem.  A bug was entered on SF at the time 
but has not been looked at since as far as I know.  I run into this one 
all the time and find it really annoying.


Joe T


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

Re: gEDA-user: Silk on vias

[joeft]

David Kuehling wrote:


Hi,

reading through the manufacturer's design rules, I cannot find any
comments on how much distance silk text should keep from vias.  Just
wondering, whether there problems one should be aware of (like silk
detaching and geting to places it doesn't belong?)  Or can vias just be
overprinted?

regards,

David
 

If the vias are tented (covered with solder resist) you can print over 
them, although the ink will run on occasion and decrease the legibility 
of the text.  (Vias are tented by default with pcb.)  If you are 
printing small text (< "100%") I would stay clear of vias if you want 
all the silk to be readable.


Joe T


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

Re: gEDA-user: Re: GEDA Code Sprint: Idea

[joeft]

Dan McMahill wrote:


joeft wrote:


DJ Delorie wrote:


I find this semi fork disconnecting.
  




I partly agree.  One of the ideas behind HID is that you can have two
GUIs that *act* differently, not just *look* differently.  That way,
each GUI could respect the rules of its usability guide.  So some
differences are to be expected.  However, it would be nice if
significant functional (i.e. usability) bits were shared, like user
definable menus.

 


Is there anyone to maintain the GTK interface at the moment?
  




I'm having the same concern.  I'm not in a position to use the 
lesstif version at the moment and am finding that:


1) There are new features that have been added only to the lesstif 
version that would be a big help (as kaimartin has already stated).


2) There are some subtle things that are broken as a result of the 
hid split.


( Such as: crosshair snapping to components and pads has changed, the 
grid doesn't display correctly on the back side ...)


It would be great if the gtk hid could pick up some of these changes, 
but it would be better yet if it did not regress as a result if the 
hid split.



If someone cared to create and maintain some sort of feature matrix 
indicating what was implemented, missing or broken in each GUI, that 
would probably be helpful.  It would be a good place to refer to if 
someone had some time and was looking for a project.  I'd imagine that 
could help keep both the gtk and lesstif HID's on par.


-Dan


I'm guessing that a complete list would have to combine inputs from the 
developers and the users that run into issues as they use the program. 

I've noticed some other things which I would be glad to contribute to a 
"list" somewhere.  The two items I mentioned earlier are already 
submitted to the sf bug tracker for pcb.


Joe T








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





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

gEDA-user: pcb crash when highlighting net

[joeft]

I am nearing completion on a layout and am encountering repeated crashes 
with pcb.  They occur when I hit "f" to highlight a net.  The problem 
seems to be that pcb is deallocating memory it shouldn't.  The error 
message looks like this:


*** glibc detected *** free(): invalid next size (fast): 0x081c5d30 ***

It is very repeatable and seems to also need the following conditions:
- rat's nest is turned on
- there are still un-routed traces on several nets
- many of the un-routed traces are ground, ground has the most net 
connections (>200), and ground is the net I highlighted when it crashed.

- incorrectly connected (shorted) nets may make things worse.

As I proceeded further with the design I found the susceptibility to 
crashing changes.  Having more of the nets routed makes it more robust.


Here's a traceback that I captured.  I can also supply the pcb file if 
it would help.  It's a bit big to include it here.


Traceback from crash when net is highlighted.  PCB 20060822, gtk hid, 
SuSe 9.3.


[EMAIL PROTECTED]:~/projects/db8b> pcb -gdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db 
library "/lib/tls/libthread_db.so.1".


(gdb) r
Starting program: /usr/local/bin/pcb-bin
[Thread debugging using libthread_db enabled]
[New Thread 1082867936 (LWP 7233)]
write to pipe "cat - > 
'/home/joeft/projects/db8b/highlight_net_U23-3_crash.pcb'"

*** glibc detected *** free(): invalid next size (fast): 0x081c5d30 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread 1082867936 (LWP 7233)]
0xe410 in ?? ()
(gdb) where
#0  0xe410 in ?? ()
#1  0xbfffe104 in ?? ()
#2  0x0006 in ?? ()
#3  0x1c41 in ?? ()
#4  0x407342c1 in raise () from /lib/tls/libc.so.6
#5  0x40735b75 in abort () from /lib/tls/libc.so.6
#6  0x407687aa in __libc_message () from /lib/tls/libc.so.6
#7  0x4076e007 in malloc_printerr () from /lib/tls/libc.so.6
#8  0x4076f6cb in free () from /lib/tls/libc.so.6
#9  0x0807e73e in FreeLayoutLookupMemory () at find.c:494
#10 0x0807fad5 in LookupConnection (X=447330, Y=416496, AndDraw=1 '\001',
Range=1000, which_flag=0) at find.c:3302
#11 0x080551d4 in ActionConnection (argc=1, argv=0x0, x=447330, y=416496)
at action.c:2268
#12 0x080a3d35 in hid_actionv (name=0x80c324e "Connection", argc=1,
argv=0xbfffe460) at actions.c:216
#13 0x080a3df1 in hid_actionl (name=0x80c324e "Connection") at actions.c:194
#14 0x080ae8a3 in ghid_port_key_press_cb (drawing_area=0x831e4f8,
kev=0x81b4bf0, ui=0x826b718) at gui-output-events.c:460
#15 0x4015781e in gtk_marshal_BOOLEAN__VOID ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#16 0x403fe8db in g_closure_invoke () from 
/opt/gnome/lib/libgobject-2.0.so.0

#17 0x4040dd8b in g_signal_chain_from_overridden ()
from /opt/gnome/lib/libgobject-2.0.so.0
#18 0x4040eff2 in g_signal_emit_valist ()
from /opt/gnome/lib/libgobject-2.0.so.0
#19 0x4040f626 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0
#20 0x4023ef14 in gtk_widget_get_default_style ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#21 0x4024e6ac in gtk_window_propagate_key_event ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#22 0x4025122c in gtk_window_activate_key ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#23 0x4015781e in gtk_marshal_BOOLEAN__VOID ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#24 0x403fe279 in g_closure_ref () from /opt/gnome/lib/libgobject-2.0.so.0
#25 0x403fe8db in g_closure_invoke () from 
/opt/gnome/lib/libgobject-2.0.so.0

#26 0x4040e179 in g_signal_chain_from_overridden ()
from /opt/gnome/lib/libgobject-2.0.so.0
#27 0x4040eff2 in g_signal_emit_valist ()
from /opt/gnome/lib/libgobject-2.0.so.0
#28 0x4040f626 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0
#29 0x4023ef14 in gtk_widget_get_default_style ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#30 0x401513f4 in gtk_propagate_event ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#31 0x4015274f in gtk_main_do_event () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0

#32 0x40341ed2 in gdk_add_client_message_filter ()
from /opt/gnome/lib/libgdk-x11-2.0.so.0
#33 0x40456967 in g_main_context_dispatch ()
from /opt/gnome/lib/libglib-2.0.so.0
#34 0x40458ce2 in g_main_context_acquire ()
from /opt/gnome/lib/libglib-2.0.so.0
#35 0x40459cf7 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0
#36 0x40152be3 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#37 0x080b4e98 in ghid_do_export (options=0x0) at gui-top-window.c:3841
#38 0x08083a84 in main (argc=1, argv=0xb0c4) at main.c:763




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

Re: gEDA-user: updating layout with new footprint

[joeft]

Ostheller, Joel A. wrote:

I finished a layout, but decided that I really should change one of my 
footprints. Is there a way to update my .pcb for all updated 
footprints without having to redo placement and hand routing? //


 

A while back David Rowe posted a perl script to this list to 
automatically update footprints in a PCB file.  I added a couple very 
minor tweaks to work with the part building conventions I use.  The 
algorithm is fairly simple-minded, but I've used it with good success on 
several occasions.


I can send it to you if you are interested.  No guarantees.

Thanks again to David for making this tool available in the first place.

Joe T



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





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

Re: gEDA-user: Re: GEDA Code Sprint: Idea

[joeft]

DJ Delorie wrote:


I find this semi fork disconnecting.
   



I partly agree.  One of the ideas behind HID is that you can have two
GUIs that *act* differently, not just *look* differently.  That way,
each GUI could respect the rules of its usability guide.  So some
differences are to be expected.  However, it would be nice if
significant functional (i.e. usability) bits were shared, like user
definable menus.

 


Is there anyone to maintain the GTK interface at the moment?
   

I'm having the same concern.  I'm not in a position to use the lesstif 
version at the moment and am finding that:


1) There are new features that have been added only to the lesstif 
version that would be a big help (as kaimartin has already stated).


2) There are some subtle things that are broken as a result of the hid 
split.


( Such as: crosshair snapping to components and pads has changed, the 
grid doesn't display correctly on the back side ...)


It would be great if the gtk hid could pick up some of these changes, 
but it would be better yet if it did not regress as a result if the hid 
split.


Joe T



Not really.  Dan fixes bugs in it, but there's nobody to add features to it.

 


Or will we all switch to lesstif in the long run because this is the
only GUI that can access those shiny new features that the pcb
engine will receive during code sprints?
   



Drat!  My secret plan is out!  ;-)

Note that the *engine* features automatically apply to all GUIs.  It's
only the GUI-specific features that are, well, GUI-specific.


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

 





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

Re: gEDA-user: Line width of silk-screen text

[joeft]

DJ Delorie wrote:


I'm curious to know what the "not a great" reason is.
   



The pinout window uses the same routing to draw the pin numbers.  We
just need some way of knowing when it's appropriate to grow the silk,
and when it isn't, which probably means adding a parameter to all the
text drawing routines, or some global.

 

But... pcb has had the ability to draw the pin numbers and draw 
silkscreen text for a long time, going back several versions.  And the 
silkscreen text used to be drawn "correctly" (i.e. the same size as it 
will be when it is photoplotted).  Did the silkscreen text get broken as 
a result of it being combined with another drawing routine?  Is there 
any way it can be made to work the way it used to?


Joe T


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

 





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

Re: gEDA-user: Line width of silk-screen text

[joeft]

DJ Delorie wrote:


Is there a way to change the default line thickness used by the default
font without increasing the font size itself?
   



Set the minimum silk width in the "board sizes" dialog.  It will emit
gerbers with the right size, even if it shows up thinner on the screen
(yes, there's a reason for that, no, it's not a great reason).
 

I'm curious to know what the "not a great" reason is.  Showing the 
silkscreen on-screen the same size it will be fabbed is important when 
laying out tightly spaced components.  Shouldn't WYSIWYG be the 
expectation in this case?  As I recall, a couple versions back, PCB used 
to show the silk the correct size - is there a way to configure the 
previous behavior?


Thanks,
Joe T

 


Or would you recommend I chose a different manufacturer?  After all
the 0.18mm requirement seems to imply that boards designed even with
PCB's default settings won't be producable.
   



8 is pretty good.  I've seen 6, but not less, in prototype deals.


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

 





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

Re: gEDA-user: New version of gEDA Suite availabl

[joeft]

Stuart Brorson wrote:



I would be interested in
hearing experiences of other distro users.


I tried the install on a SuSe 9.3. A previous installation has been done 
on this system so many of the "system" packages were already present.


Here's what I found --

12/14/06

- Having the install forced to run as a user other than root seems to be a
 constraint.   Not everyone wants to put the install files and 
executables in
 ${HOME}/geda-install.  This approach makes it very difficult to put it 
in a
 more universally accessible location like /usr/local/bin.  (Think of a 
system

 with more than one user.)

- gtkwave install breaks with this error:

Failure executing command "tar -zxvf gtkwave-3.0.7.tar.gz", ReturnCode = 2
In ErrorQuitWindow_10.

which in the verbose log seems to be caused by:

tar: gtkwave-3.0.7/man: Cannot utime: Operation not permitted
tar: gtkwave-3.0.7/man: Cannot change mode to rwxr-xrwx: Operation not 
permitted

tar: gtkwave-3.0.7: Cannot utime: Operation not permitted
tar: Error exit delayed from previous errors
(repeated several times)

Having the gtkwave installation fail in this manner probably shouldn't 
kill the

whole installer.

- gnucap would not build.  Since I don't need it at the moment I skipped 
over

 it.

- pcb doesn't install.  The logic for checking for libjpeg and libgif still
 appears to be broken.  It appears that if you have support already in 
place

 for png *and* gif *and* jpeg the install will finish.  Otherwise it will
 fail.  I haven't found a way to pass in a flag to the installer from the
 beginning to tell it to disable lesstif, gif, png, or jpeg so that it can
 succeed in some form.


Joe T




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

Re: gEDA-user: FreeDog meeting minutes (20061206)

[joeft]

Ales Hvezda wrote:



* An idea was tossed out to make PCB's default build/run mode be set
 to Lesstif, as the Lesstif PCB is more configurable at runtime.
 DJ noted that Lesstif has an active developer (DJ) whereas gtk+ is
 more in "maintenance" and could use a gtk+ expert to push it forward.
 Stuart mentioned that newbies expect (without even knowing it) to
 see the gtk+ interface, and they would be blown away by the Lesstif
 interface.  John suggested that it would be nice if *all* version of
 PCB were built and installed.  This would enable the user to easily
 evaluate all interfaces for themselves.
 

The lesstif version affords some nice flexibility, but before you do 
this, and further shift resources away from supporting the gtk gui, 
please, please try to ensure that existing users can build a lesstif 
version.  I spent a good deal of time (and eventually failed) trying to 
build a lesstif version on a SuSe 9.3 system.  Gathering up a set of 
compatible dependencies seems to be a real challenge.  Looking at 
lesstif.org and x.org still left me with a couple problems.  If one of 
the developers could take a few of the wrinkles out of the lesstif build 
process (or put a *complete* lesstif rpm file on the install disk) it 
would be greatly appreciated.


Thanks,

Joe T



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

Re: gEDA-user: Crash with lesstif version of pcb

[joeft]

John Griessen wrote:




joeft wrote:


DJ Delorie wrote:




DJ,

More info on this problem (hopefully useful to others)

I'm not sure why but there were some missing links in /usr/lib to 
some of the required shared libraries.  In particular, there was no 
/usr/lib/libXm.so.


There is however a libXm.so.3.
Just for grins I make a link to it.  (Don't know if it will be the 
correct
version etc. or what).  To start with I re-do the make, make install 
steps.


This actually works - the program now starts a




I have seen this also.  It relates to changes from xfree86 to xorg 
Xwindows.


Some standard ways of using .la files are changing and some packages 
in debian are not correct...I also found a link would fix the lack.  
Just hit and missed and hit finally...



John G


John,

I would love more insight on what you did to make this work.  First off 
- I'm building on a SuSe 9.3 system.  It has XFree86 Xwindows (as far as 
I know).  Right now I can't figure out what's missing and have found no 
way to get a running (lesstif) pcb version.  I am building lesstif in 
the hope that some of the other problems I've been seeing will be 
addressed with the lesstif GUI. 

In particular - I'd love to know how to get the grid to display 
correctly on the back side of the board at all scales.  Last time this 
came up in the list, the thread got de-railed and the issue was never 
completely addressed.


Thanks,

Joe T



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





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

Re: gEDA-user: Crash with lesstif version of pcb

[joeft]

DJ Delorie wrote:


Perhaps you had an old Xaw version of pcb installed, and its
pcb-menu.res is overriding the built-in lesstif version?

 

I don't recall ever having the Xaw version on this machine, although 
I've had the GTK version installed for quite a while.  Where do I look 
to see if there is a conflicting version of  pcb-menu.res?


Joe T


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

 





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

Re: gEDA-user: Crash with lesstif version of pcb

[joeft]

DJ Delorie wrote:


#2  0x40127026 in XmStringCreateLocalized (text=0x0) at XmString.c:4427
   



This looks suspicious.  I'll investigate when I get a chance.



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

 


DJ,

More info on this problem (hopefully useful to others)

I'm not sure why but there were some missing links in /usr/lib to some 
of the required shared libraries.  In particular, there was no 
/usr/lib/libXm.so.


There is however a libXm.so.3.
Just for grins I make a link to it.  (Don't know if it will be the correct
version etc. or what).  To start with I re-do the make, make install steps.

This actually works - the program now starts and puts up a main display 
window,

but the menus are incomplete.  I now get pages of messages that say:

Warning: Cannot find callback list in XtAddCallback

In this case however, libXt appears to be intact.  Next I tried to do a 
clean

sweep: make clean; ./configure; make; make install;, but the result was the
same - apparently some Xt functions are broken or maybe I've got a 
mismatched

libXm, or ?

Joe T

(One final note: the first guess might be that the gdlib install is broken.
However, gdlib was built from the SystemPackages dir on the CD and is
(hopefully) the correct one.)


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

Re: gEDA-user: LED in reverse

[joeft]

Karel Kulhavy wrote:


Do you know at which voltage a typical red LED breaks down in reverse? 100V?
 

No, more like 5v or so.  LEDs are not designed for high reverse 
breakdown voltages.



What happens when the diode is charged slowly with a current source of say
0.5mA until it breaks down and it's internal capacitance discharges by
avalanche?  Will it blink or stay dark in the process?
 

If you are talking about a current applied in the "reverse" direction it 
won't light up at all.  I haven't looked at the very bright LEDs that 
have been marketed recently, but in general I would say that most LEDs 
make lousy capacitors and won't store much charge at all.


Joe T


Wikipedia says an avalanche reaches maximum in picoseconds. If the avalanche
shines, does the light generated reach maximum in picoseconds as well?

CL<


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

 





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

Re: gEDA-user: pcb text

[joeft]

I understand.  I'm thinking that it used to "work" however.  Is my 
memory failing me?


Joe T

DJ Delorie wrote:


I think you've explained the behavior I've viewed as a bug.
   



Yes, it's a bug.  My explanation was why it's not an easy (i.e. fixed
already) bug.


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

 





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

Re: gEDA-user: pcb text

[joeft]

DJ

I think you've explained the behavior I've viewed as a bug.  The pin 
numbering code should allow narrow lines for readability while you are 
editing - this is good.  However, the silkscreen text must be drawn with 
accurate width in the editor so that it can be placed to prevent their 
landing on pads etc.  Allowing it to be artificially thin can get you in 
trouble.


Joe T



DJ Delorie wrote:


Could anyone tell me what is going on?
   



The gerbers and PS output honor the "minimum silk thickness" DRC
setting.  The GUI doesn't.  The reason it's not fixed is because the
same code does the pinout numbers, and if you make them thick enough
they're just blobs.


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

 





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

Re: gEDA-user: no pins in JUMPER10

[joeft]

I would suggest that "Y" be used for crystals rather than "X", which 
might prevent collisions when someone uses their netlist for SPICE 
simulations that have subcircuits.


Some lesser used prefixes I've seen:
F Fuse
and some two letter prefixes (if you can deal with more than one letter 
prefixes...)

TP Test point
FB Ferrite bead
RN Resistor Network

Joe T


Carlos Nieves Ónega wrote:


El mié, 08-11-2006 a las 08:14 -0500, John Luciani escribió:
[snip]
 


Below are the refdes conventions that I use (that I have
seen on *many* schematics).

I may have missed a few since this is BC (before Cappuccino).

(* jcl *)

Substitute an integer value for 

value  component type
 -
R Resistor
L Inductor
C Capacitor

B Battery
J Connector
P Connector (usually plugs that mate with J)
K Relay
S Switch
T Transformer

D Diode
Q Transistor
U IC
X Crystal
   



Added to the wiki:
http://geda.seul.org/wiki/geda:master_attributes_list#refdes

Thanks,

Carlos



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

 






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

Re: gEDA-user: bug or feature in recent versions of PCB?

[joeft]

I've observed this same behavior on a Suse installation (also w/ GTK 
hid).  Maybe stealing focus is not the issue?  My first impresstion when 
I had it happen was that the event generated by the mouse click (as when 
drawing lines) came back saying the right button rather than the left 
button had been pressed.


Joe T


Tomaz Solc wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

 


Do you hit the breakpoint, or do you get the drawing errors without
hitting the breakpoint?
   



Yes, I always hit the breakpoint immediately after I click the left
mouse button for the second time to place the end of the line.

 


If the breakpoint is hit (and you haven't moved the mouse pointer
outside the drawing window while drawing a line), then I suspect some
other application on your system is stealing focus for a moment and then
returning it.
   



I also tried this with only X running (no GNOME desktop, window manager
or any other applications running). In that case I never hit the
breakpoint and also there is no weird scrolling.

Do you have any idea what application would be stealing the focus? I'm
not running anything special - just the stock GNOME installation that
comes with Debian. Gschem and other tools don't seem to have any
problems with this.

Best regards
Tomaz Solc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFU2NSsAlAlRhL9q8RAiN4AJ47Xkxfnbqj3Evm0hrOc4YwiYCNhQCfYSr+
fbNxcJeqt1BhkMSnXIq5sI8=
=nV+L
-END PGP SIGNATURE-


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

 





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

Re: gEDA-user: Fiducial

[joeft]

John Griessen wrote:




Dan McMahill wrote:


Does this need to be a feature?


I'm not an expert in PCB layout tools but  it seems worthy 


I think it is important but I'm not sure when I'll have time.  I 
wonder if maybe just a "nopaste" flag for pins/pads is enough. 



If we could show it as a layer and add a rectangle, I think it would 
be less error prone.   Checking for such rare things as an added 
rectangle on soldermask or paste could be like:   show only 
solderpaste layer, select all, see count.


Having the paste patterns shown explicitly and having a way to 
explicitly create a paste pattern would be the general way to do it.  
Same thing for the solder mask.  There have been lots of times where I 
just wanted a rectangle cleared of solder resist. that is not tied to a 
part.


PCB really should be able to cleanly deal with layers that are not copper.

Joe T



As far as one side only fiducial workarounds, how about these:

Make opposed, offset L lines in a copper layer so their edges are on 
intersecting X and Y axes.  Etching results might make the edges eaten 
back from a perfect line through them all, but you could still use 
them as fiducials by aiming for the middle of the gap.  This 
approximates a fiducial of alternating squares of black and clear.


Another is a zero length line to get a circle of copper layer.  Same 
as a zero diameter via, but on one side only.






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





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

Re: gEDA-user: PCB lesstif pcb-menu.res ideas

[joeft]

John Griessen wrote:




DJ Delorie wrote:


Choose via tool the usual way.  Now PCB is ready to act on a left
button down event.  In comes a scroll wheel event.  Now PCB suspends
polling the mouse for an instant, and reponding to the new event,
changes the value of ViaDrillingHole up a mil for the up button, or
down a mil for the down button.



I think what you're asking for is tool-sensitive bindings.  Thus, if
the via tool is the current tool, you want up and down to do
via-specific things,



Yes, that's one way to think of it.

Another way is just an add on to what you already did with the 
multi-keys bindings.  If F1,  whoops!   You already defined multikeys 
bindings to work on plain ascii only, so F1 key is not one of those 
keys.  So that's not an easy falling-out-of-what-just-happened thing 
to do -- I was thinking follow F1 with more keys, some of which were 
mouse buttons...


Is there an easy way to let the function keys also be some of the user 
bindable keys?  We have some pretty good reasons to use some of the 
letter keys as a one letter mnemonic.  They can be same as gschem 
and/or different one letter mnemonics -- r for route, g for grid, z 
for zoom, v for view full.


One letter commands increase usability.  I'd like to have them in 
gschem too, and yet, while gschem stays as it is, I want to be able to 
change some key defs in PCB to match gschem so I keep my head straight 
as I switch from one to the other in a schematic driven design.


John G


Making/allowing key defs to be the same in PCB and gschem is a great 
idea.  And while you're at it, is it worth thinking about enabling 
strokes for PCB?


Joe T


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

Re: gEDA-user: Problems with PCB grid

[joeft]

Harold,

You were right the first time.

There *was* a thread about this issue a couple of weeks ago.  The thread 
got diverted to a discussion of an install problem and the original 
issue with the missing grid was never addressed.  Other people have 
noticed that the grid disappears in certain cases:


When viewing the far side, the grid is only displayed over part of the 
main drawing window.  The degree to which the grid is displayed depends 
on the scale - i.e. how much you are zoomed in.


This problem appears to be recent; it was not observed in earlier releases.

If anyone familiar with the code can chime in - I'd be willing to try 
and chase down the problem if someone could give a hint as to where to look.


Thanks

Joe

Harold D. Skank wrote:


People,

Sorry about that.  It appears that I simply hadn't zoomed in enough.
The grid _IS_ there.

Harold Skank

On Fri, 2006-10-06 at 09:28 -0500, Harold D. Skank wrote:
 


People,

I can't find this reference in my mail notes, but I seem to recall a
recent thread of problems from pcb-20060822 mentioning that the grid was
not visible in the most recent release of PCB.  I have updated to the
200609?? version of PCB, and I am having the same problem.

Since I cannot find mention of this in any of the bug reports, I suspect
that it must be a set-up problem.  Could someone there fill me in?

Harold Skank



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





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

 





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

Re: gEDA-user: Newbie PCB DRC questions

[joeft]

Peter,

I don't believe these small segments are due to the autoroute process.  
I see them a lot and I've never used the auto-router.  I believe they 
can occur when:
You add a line containing several segments with snap to pins and pads 
turned on.  This can put a short (< 1 grid long) segment in the line.
Then if you move or delete one of the longer line segments attached to 
short segment the short segment can be left behind.  If it is under a 
pad or via, it is of little consequence to the photoplotter, but is 
still seen by the DRC.  Sometimes moving a segment next to an off-grid 
segment like this will make a mess as it moves the line segment on the 
far side of the short segment.  (This appears to be an issue caused by 
the vertex selection code - see the mailing list archives 
[http://archives.seul.org/geda/user/Jun-2006/msg00058.html] where this 
was brought up a few months ago.)


As you've found, turning off pads and or vias, and drawing with line 
filling off can let you see these hidden "features" and delete them.


Joe

Peter Baxendale wrote:


3. Sometimes when DRC reports "copper areas too close", I go to the
coordinates specified in the message and I cannot for the life of me
find anything closer than 10 mils. (And I still have it checking for 5
mil spacings.) Does DRC sometimes get fooled into thinking that
connected lines should be separated?  Or am I misinterpreting the
errors?
   



I've seen similar things with auto routed tracks. Sometimes, if I zoom
right in and play about with layer visibility a bit I can see a very
small piece of track under/over a via. Deleting this makes the drc error
go away. I assume these bits of track are some kind of artifacts of the
auto route process. I don't know why this should produce that particular
error.



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

 





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

Re: gEDA-user: choosing power MOSFET's

[joeft]

While not entirely about choosing the best FETs, there is a good general 
article about class D audio amplifier design in the most recent issue of 
Analog Dialog (from Analog Devices).


http://www.analog.com/library/analogDialogue/archives/issues/vol40n2.pdf

Joe

gene glick wrote:

Can anyone help?  I am not certain on how to weed my way through the 
very broad offering of MOSFET's.  The application is for class-D audio 
amp.  Things like gate charge have me a little lost.  Rds makes sense 
in that it affects the power consumed in the fets.  Ramp time and 
ton/toff have me a tad confused also.  Why don't the manufactures list 
a ton min?  They seem to always list Ton max, though.


I am open to any suggestions.

thanks

gene


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





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

Re: gEDA-user: GEDA code sprint reminder -- one week from today!

[joeft]

Harry -

These are very welcome additions to PCB.  (6) especially will save me 
literally hours of manual checking.


Thanks!

Joe T



Harry Eaton wrote:

Unfortunately, I have family commitments so I won't be able to 
participate in the code sprint.
I have been sprinting on my own quite a bit recently solving the 
long-standing problem of dead copper in polygons.
I have alpha-quality code up on sourceforge now and it could use some 
testing, so if you're fairly skilled with pcb
and would like to help find all the new bugs I know must be lurking, 
give it a spin. It's in a cvs branch tag named

"clipper".

Some features it has:
(1) Gerbers are always positive-only, which should increase the number 
of fab vendors that are happy with them.
(2) Thermals can be diagonal or horizontal/vertical or solid to the 
plane (shift-click with the thermal tool to cycle through the styles)
(3) Thermal fingers are user-editable. Treat them like normal lines in 
the layout.
(4) Any "dead" copper in polygons is automatically removed. Select 
"check polygons" in the settings to view an outline of removed copper)
(5) The rats-nest will no longer believe objects connected to polyogn 
islands are still connected to the polygon.

(6) Thermal fingers are checked for DRC violations.

There is still a little work to be done to complete the DRC code, but 
it should mostly be functional.


There is no need to concentrate on testing the features above - the 
changes affected many areas of the code, so bugs may well exist in 
operations that appear to be unrelated to these features.


Cheers,
harry






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





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

Re: gEDA-user: Milling channels in a PCB?

[joeft]

Stuart,

I've done this by hand and had a shop do this kind of thing.  Good luck.

Most fab shops can route spaces between boards (in a panel) or parts of 
a board.  Many (most?) are not set up to mill partially through a 
panel.  They may not have the machine(s) or tooling to do it.  Control 
of depth, the correct tool (end mill)  are required.  You didn't say 
what size the features were you need cut out.  As DJ points out, the 
shop may have a limited set of tool diameters available.   The shop may 
balk at really narrow slots (< .025").  If you have access to a 
mechanical CAD program it may help.  Doing a really detailed drawing is 
essential.  And ask them what data format their milling machines expect 
(I would be surprised if they can use gerber output).  Without a doubt 
there will be some translation step required to get the data in the form 
they need.


When you design the board, it would probably help to keep all copper 
(especially planes) away from the depth of your cut.


If you find a shop that is willing to do this and does a good job please 
let us know who it is.


Joe

Stuart Brorson wrote:


Guys --

I have a PCB specification/manufacturing question, and I figure some
of the gurus on this list might have the answer.  I want to create a
PCB with some material (0.030", say) milled off the top of the board
at specific locations.  That is, I want to cut grooves into -- but
not through -- the board.

What is the best way to acheive this (besides buying a milling machine
and doing it myself, that is)?  Specific questions:

*  How do I capture this information so a PCB fab house can use it?
Gerbers only give 2D info, they don't specify anything about where to
mill or route a channel into the PCB.  Or should I define a separate
"mill" layer, and call out the milling depth in the fab drawing?

*  Is it possible to capture this milling info using PCB?  I guess I
can just draw tracks on the "mill" layer . . . . . right?

*  Which PCB houses do this kind of work?

I'd prefer to hear from folks who have actually had this type of job
done, rather than just guesses or hearsay.  OTOH, all suggestions are
welcome.

Cheers and thanks for any info,

Stuart


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





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

Re: gEDA-user: [pcb] MinMaskGap action

[joeft]

Phil,

You didn't mention whether this was "incidental" silkscreen like a 
"ElementLine" that overlapped the pad or something related to the pad 
itself..  A previous version of pcb would in some cases generate 
silkscreen rectangles in the gerber output on some surface mount pads.  
I was never able to figure out what combination(s) of features would 
cause this to happen, but it does appear to be fixed in the most recent 
revision of pcb.  (You can and should look pretty carefully at your 
gerber output to make sure it is correct.)


Joe


ptay wrote:



DJ,

About a year ago I got some boards back with silkscreen printed over 
some pads.  Since, I've manually kept the silkscreen off the pads.  
... Does MinMaskGap work on silk too?


Phil



DJ Delorie wrote:


F.1.41 MinMaskGap

MinMaskGap(delta)
MinMaskGap(Selected, delta)
Ensures the mask is a minimum distance from pins and pads.  Checks all
specified pins and/or pads, and increases the mask if needed to ensure
a minimum distance between the pin or pad edge and the mask edge.


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





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





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

Re: gEDA-user: Fiducial

[joeft]

Dan's suggestions are similar to what I've received from one of our 
suppliers:


Use a .050" diameter copper circle with .100" solder mask opening in 4 
places.  Making the part as a pin may include a drilled hole (which you 
don't want).  What I did was make a part with one surface mount pad of 
the proper size.  Be sure to place it on both sides of the board - 
they'll need it to load parts on both sides.


Joe


Dan McMahill wrote:


Jeff VR wrote:


I'm working on laying out my first PCB board.  I understand that the
pick and place machine uses reference points on the board called
fiducials when placing my components.  I'm planning on having my board
assembled by a MyData 12 machine.  So how do I incorporate this symbol
and element on my PCB.  I found a similar question on this mailing
list dated a couple of years ago but it had no response.

I searched the schematic symbol library and footprint libraries and I
couldn't find anything obviouse.  A little guidance from a seasoned
PCB deasigner would be greatly appreciated.

Thanks,
Jeff



I suggest creating a schematic element and a footprint for a fiducial 
and instantiate it in your schematic.


I can't comment on that particular machine.  In general though, you 
should use a minimum of 2 "global fiducials" and preferably 3.  With 2 
you can correct for x,y offsets and rotational offsets.  With 3 you 
can correct for some nonlinear distortions like scaling, stretch, and 
twist.  This is paraphrasing part of the IPC-7351 document.  By 
global, I mean they're not for some particular part on the board.  You 
should place these at 3 of the 4 board corners.  The document 
recomments that you locate 2 diagonally across the board and the 3rd 
one has one x cooridinate and 1 y coordinate in common with the 
others.  For example


(X1, Y1), (X2, Y2), (X1, Y2)

You may or may not need local fiducials near some high pin count fine 
pitch parts.  If you do, place 2 of them diagonally across from each 
other just outside the package corners.


The prefered shape and size is a filled circle of copper with solder 
mask completely removed.  The diameter should be 1.0 mm.  The diameter 
area free of soldermask should be 2x the diameter of the fiducial.


I'd probably make an element with 1 pin to put in schematic and layout.

-Dan


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





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

Re: gEDA-user: Hidden rectangle in PCB causing headaches

[joeft]

Hugo,

Thanks for filling in some other cases that the DRC might handle 
better.  In fact, we ran across the last case you describe below on this 
same design.


Joe

Hugo Elias wrote:

> We've just completed a board which had us scratching our heads when 
we ran the DRC.  We also found problems in the gerber output.



Hi Joe,

I've been having similar nightmares with the DRC. The other
problem is when you have 2 rectangles exactly touching
(with zero gap between them).

I have also thought about a couple of ways the DRC interface could
be improved. As far as I understand it, a DRC error is always between
exactly 2 objects? EG 2 track segments, or a via and a poly. Is
this correct?

So, basically, the user needs to be able to identify exactly which
two objects, even if they are invisible

1. It would be very helpful if the DRC could tell you in the log
which layer(s) the two offending objects were on.

2. instead of colouring in a whole load of things in green, and 
something in cyan. Why not outline the two objects with a dashed

outline or something. Then the user would immediately be able to see.

3. Instead of saying in the log "copper areas too close".  Why not say
something like "via too close to track" for example.

The other thing that can *really* get you is when a track is accidently
'joined' to a rectangle nearby, even though it doesn't look like it.
I.E. the track is between two other tracks which clear the rectangle,
but the rectangle overlaps the joined track.  This causes PCB to think
there's a short, even though there isn't.

Hugo Elias





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





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