from:"Rick"


At 05:20 AM 12/2/2010, you wrote:

On Wed, 01 Dec 2010 19:38:32 -0500
Ethan Swint eswint.r...@verizon.net wrote:

 Sorry for my late reply - but have you tried the BOM export (File -
 Export Layout-BOM).  One of the output files from that is an XYRS
 (X, Y, Rotation, Side) text file.

 http://archives.seul.org/geda/user/Feb-2009/msg00351.html

Yes, but as I pointed out earlier, it doesn't do what I want. It averages the
coordinates of the pins/pads, and it is not good when you working with
asymmetric element such as SOT223.


My experience is that there are two points on a pick and place 
package.  There is the centroid, which I understood to be the center 
of the outline of the part and is used to define the orientation 
point on the part for positioning.  There is also a pick point which 
has to be in a spot where the vacuum nozzle can lift the 
component.  This are mostly the same spot, but on unusual parts, not 
always.  I can't imagine the XYRS file generator is not capable of 
outputting the appropriate centroid position.  Is it possible that 
you are seeing the pick point thinking it is the centroid?


The feedback from my assemblers is that I should give the X and Y 
coordiates of the centroid of the part for placing it on the 
board.  The rotation is nice for them to have, but they mostly don't 
trust them and so always go through a process of verifying both 
placement and rotation of each part as it is placed on the board for 
the first item.  It may actually be a virtual dry run using the 
machine display.  But they have told me they ignore all other info 
such as glue spots and pick points.  They know where they want the 
glue spots and pick points and have no reason to trust your data for that.


If the XYRS file output does not output proper centroids, I see this 
as a major issue.  If they are not outputting the correct value for 
asymmetric parts, how do you see the centroid being defined exactly?


Rick 




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

Re: gEDA-user: Random thoughts on the future interface of PCB

Was it just me that got a copy with no paragraph 
breaks?  Looking at the ascii art I assume it was 
sent with line breaks somewhere.


Rick


At 03:02 PM 12/2/2010, you wrote:
Hi guys, Just thought I'd write some of this 
down and put it out there. I've spent some time 
recently thinking way into the future about the 
GUI / usability for an advanced PCB editing 
program. I started along the lines of... how 
would PCB design work if my input device was a 
graphics tablet (something akin to the Wacom 
Cintiq would be awesome). PCB design is a real 
hybrid of art, precision engineering and black 
magic. For laying tracks, some gestural actions, 
fluid drawing and possibly even multi-touch 
interfaces might provide user interface 
opportunities never before seen in this kind of 
CAD application. Some randomly sorted ideas: 
Scrap straight line rats in favour of using the 
topological auto-router?   This is not quite the 
same as auto-routing a single net. Each 
rat   would only avoid existing laid down 
geometry, and would be allowed to   cross other 
rat lines. Also, I'd imagine flattening any 
route   generated to be in the rats plane. (The 
rat would not jump between   layers as an 
auto-routed trace might, even if the route taken 
could   only be made effectively through 
multiple layers).   Obviously this is nice, as 
the user can pick rat-lines which have   routed 
well and request PCB turns the rats into solid 
tracking. Manually placed, rubber-banded 
topological tracking?   How about guiding a 
track routing by drawing the topology you 
desire,   weaving in and out of other 
components?   The topology between obstacles 
could easily be extracted from a   hand-stroked 
line drawn with a pen, mouse, or perhaps 
some   high-resolution touch-screen 
interface.   Dynamic zooming about the current 
touch-point / mouse cursor when   drawing in 
amongst detailed objects, or the user is forced 
to slow   down would aid lower resolution input 
devices. Rendering would have to   be FAST and 
slick to pull this off without disorienting the 
user.   Following topological drawing, tracks 
could be allowed to evolve as if   they were 
sprung-loaded (Ã  la liquid-pcb), or processed 
through some   routine to solidify them.   For 
sprung loaded tracking, I'd imagine having a 
virtual obstacle   object the user can place on 
the board to constrain the tracking.   Sprung 
loaded / pushed tracking would be updated if the 
user were to   place and drag an obstacle:   | | 
| | | -   | | | | | -  | | | | |   | | 
| | |  | | | | | | | |  \ \   | 
| | | |  | | |.\ | | | |-.| 
|   | | | | |  | | | / | | | 
|  / /   | | | | |  | | | | | | 
| | | |   I also imagined a stroked gesture 
where the user draws a ring around   a bunch of 
tracks, as if to tie a rubber-band around them. 
This action   would group them for operations 
such as re-routing.   I wonder if this requires 
the notion of treating 
individualtrack-segments as a topology. This 
would be handy anyway, to aid   manual 
rubber-banding. Drawing could potentially be 
made quicker if we   had higher-level data than 
individual line-segments (it would reduce   the 
number of round capped sections requiring 
drawing). Magnetic component placement   An 
augmentation to the grid really - make 
components resist being   pushed past favourable 
alignment points with other components?   This 
wouldn't STOP  components being placed off these 
points, just   give some resistance.   This 
feature would also be quite neat for component 
placement, where   some future addition of a 
courtyard / mechanical interference 
spec.   within the package definition would 
constrain placement to resist   motion closer to 
other packages than desirable.   This could be 
absolutely enforced when placing a component, or 
act to   PUSH the component being run into. 
(Obviously dependant on a good   algorithm to 
re-track the pushed part).   I was imagining 
this feature being useful for placing an array 
of   parts such as resistors / capacitors. We 
would need the ability to semi-lock tracks I 
think...   Obviously some tracks won't be up for 
auto-pushing, and their geometry   will be set 
in copper (to adapt a metaphor). Obviously it 
should be   possible to edit such tracks, but we 
might want the to be un-pushable. How about more 
novel ways to define planes?   Full pours 
support goes without saying ;)   I've looked at 
various commercial boards recently, and it would 
appear   that many use negative layers to draw 
tracking. High power stuff,   where practically 
everything is copper, just with some 
isolation   between regions. The complexity of 
the polygons which make up these   traces would 
be too prohibitive to use PCB's normal polygon 
tool.   They _look_ as if someone has drawn 
negagtive traces to split up a   plane. should 
we support that?   Alternatively, what about 
defining traces / topology

Re: gEDA-user: PCB: coordinates and angles of the components

   At 02:36 PM 12/2/2010, you wrote:

 On Thu, 02 Dec 2010 12:21:00 -0500
 Rick Collins gnuarm.2...@arius.com wrote:
  If the XYRS file output does not output proper centroids, I see
 this
  as a major issue.  If they are not outputting the correct value
 for
  asymmetric parts, how do you see the centroid being defined
 exactly?
 Most of my footprints are generated, and the zero point is the
 center of the
 package. I think they are OK for pick point.
 There are other footprints, which I made manually. In that case, I
 imagine the
 best pick point and I put the zero point there.

   I'm not asking about the pick point.  I'm asking about the centroid.
   They are completely different things.  As I think I said, the centroid
   is to tell the assembly house where to put the part.  The pick point is
   a point on the part where the machine will attach the nozzle and has
   nothing to do with the position where the part is to be placed.
   Further, regardless of how you set your files, the pick point is
   selected by the assembly house to optimize how they pick the part.  You
   have no way of knowing where this will be.
   The centroid needs to be a spot on the part that everyone knows without
   requiring it to be explained.  Unfortunately for oddly shaped parts, it
   does not seem to be well understood how to select the centroid.  One
   document I have from Screaming Circuits says it is the center of the
   part including the pins and the body.  I have yet to be able to find
   this info in an IPC document.  The IPC document seems to leave out some
   other important info about rotations.  You would think they would
   figure out this is a problem and fix it...
   I can't say if your centroids will give you trouble, but from what you
   are telling me, you are not defining them correctly.  From what I have
   read, I'm not sure PCB does it correctly either.  I found some
   references on the web that says they use the geometric center of the
   pins not including the package.  I don't think that is right.
   Screaming circuits is not the ultimate reference for defining how this
   is to be done, but they have a document that covers all the bases and
   is easy to understand.  In fact, when I pointed out that they had a
   discrpancy with the IPC docs, they immediately fixed it and put the
   updated doc on their web site.  [1]www.screamingcircuits.com
   Rick

References

   1. http://www.screamingcircuits.com/


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

Re: gEDA-user: Random thoughts on the future interface of PCB

I don't know.  I've been told it is the Eudora email program that I 
still use.  But it only happens with a few emails, always from one of 
two mailing lists.  Someone in this list once tried to get to the 
bottom of it and found there were some things he could do to prevent 
it, but he doesn't always do whatever it was and I still get some of 
his without line breaks.  I don't recall if I've seen yours that way 
before or not.


I would switch to T'bird, but I'm just very leery of changing 
*anything* to do with email because I am so dependent on not just 
getting the mail, but retrieving old messages and even using it as a 
reminder and many other things.  I've just got a lot invested in how 
I work with Eudora to try to switch until I have an extended 
downtime.  As a first step, I am using T'bird as my calendar program, 
replacing the old Palm desktop.  The last time I upgraded the Palm 
desktop lost all color, so it was time for it to go.  :^(


Rick


At 04:06 PM 12/2/2010, you wrote:

On Thu, 2010-12-02 at 15:46 -0500, Rick Collins wrote:
 Was it just me that got a copy with no paragraph
 breaks?  Looking at the ascii art I assume it was
 sent with line breaks somewhere.

 Rick

I got it back with line-breaks!

I've just re-installed, so it is possible some setting is off in my mail
client though. It is auto-wrapping paragraphs here, but the ascii art
did indeed have newlines.

Looks like something (your mail reader?) has decided it knows better
about the line-breaking and re-flowed the text?

Are you on Windows / Linux / ...? Could it be a line-ending issue?

--
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



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




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

Re: gEDA-user: mirrored footprint

2010-11-25 Thread Rick Collins


At 05:01 AM 11/25/2010, you wrote:

I am missing the reason you must mirror the footprints, however.
Aren't the pins still in the same orientation they would be with the
standard footprint?  Since your DIP packages are mounted in the
normal-side-up orientation, it seems the pins should be in the right
order, unless you have placed the IC on the component side of the
board in pcb... ?


Yes, the component is at the same position, but traces are on the 
opposite side of board so something must be mirrored. SMD traces are 
at component layer. Through hole components have traces on solder 
layer. Or both of them? Well, you confused me now :-) Maybe I did 
not have to mirror the footprints.


regards,
Jan



Yes, of course you have to mirror the ICs that you are changing from 
through hole mount to surface mount.  As you say they are on the 
opposite side of the board from the pads, so now the pads need to be 
mirrored, unless the software is capable of moving the pads from one 
layer to the other without changing how they look on the screen.  But 
normally it treats this as moving the part from one side to the other 
and you have to mirror the footprint to keep pin one oriented correctly.


Heck, if it wasn't needed to mirror the footprint, it wouldn't work 
correctly after you do mirror it.


Rick 




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

Re: gEDA-user: mirrored footprint

2010-11-25 Thread Rick Collins


At 05:05 PM 11/25/2010, you wrote:

On Nov 25, 2010, at 4:05 PM, Rick Collins gnuarm.2...@arius.com wrote:

 At 05:01 AM 11/25/2010, you wrote:
 I am missing the reason you must mirror the footprints, however.
 Aren't the pins still in the same orientation they would be with the
 standard footprint?  Since your DIP packages are mounted in the
 normal-side-up orientation, it seems the pins should be in the right
 order, unless you have placed the IC on the component side of the
 board in pcb... ?

 Yes, the component is at the same position, but traces are on 
the opposite side of board so something must be mirrored. SMD 
traces are at component layer. Through hole components have traces 
on solder layer. Or both of them? Well, you confused me now :-) 
Maybe I did not have to mirror the footprints.


 regards,
 Jan


 Yes, of course you have to mirror the ICs that you are changing 
from through hole mount to surface mount.  As you say they are on 
the opposite side of the board from the pads, so now the pads need 
to be mirrored, unless the software is capable of moving the pads 
from one layer to the other without changing how they look on the 
screen.  But normally it treats this as moving the part from one 
side to the other and you have to mirror the footprint to keep pin 
one oriented correctly.


 Heck, if it wasn't needed to mirror the footprint, it wouldn't 
work correctly after you do mirror it.


 Rick

Rick,
Carefully look at an so8 and a dip 8

And really explain why you need to mirror a footprint.

Because the top side of a dip footprint is identical pinout as so8. 
(At half of the pitch). Just remove the bottom pads.



Another way to think of it,  if you took an dip package and made it 
into a gullwing and soldered it to the dip footprint. You would have 
vias through the board to that mirrored  footprint so that 
mirrored footprint was put on the wrong side of the board and you 
had to move it through the layers.


Ok, I see that.  I was thinking that if you designed a single sided 
board the component footprint pads would only be on the bottom so 
that when you flipped them to the top for the surface mount part, 
they would now be the wrong orientation.  I see what you are 
saying.  However, if you use an auto router, how do you tell it to 
ignore the bottom pads?


I guess you can edit the footprint to remove the bottom pads, just 
leaving the top pads, but I wouldn't find it any harder to design a 
footprint from scratch that is actually intended for surface mount 
work.  I think the round pad of a through hole part is not the best 
design for a surface mount part which should have oblong pads.  But I 
guess this is all hand soldered and is likely hobby stuff, so it 
doesn't matter as much since it is labor intensive anyway.


Rick 




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

Re: gEDA-user: solderpaste on pads for BGAs

2010-11-18 Thread Rick Collins

Specifically, the solder balls on the part are to provide some space 
between the part and the board.  The solder paste is as large as the 
pad and makes sure the full pad is wet with solder and completes the 
connection.


Rick


At 04:23 AM 11/18/2010, you wrote:

Hi all,


I'd like to ask if solder-paste is necessary for BGAs. The BGA already has
some tin, so the solder-paste on the pad wold be a bad idea.

Do I miss something?

Thanks,
Levente

--
Kovacs Levente leventel...@gmail.com
Voice: +36705071002




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




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

Re: gEDA-user: New branch of PCB

2010-11-17 Thread Rick Collins


I guess I didn't realize PCB was mainly for hobby use...  WHAT???

Rick


At 06:09 AM 11/16/2010, you wrote:

With TopoR having a freeware version for 2 layers and up to 256 nets
(or some other fairly high for 'hobby' use limitation), there's not
really any point on bothering improving built in autorouter...
Does PCB have Specctra DSN/SES export/import? Just use that (or
implement if it doesn't) and then use any of the autorouters that
work.

-tc

On Tue, Nov 16, 2010 at 7:52 PM, Jan Martinek ho...@dp.fce.vutbr.cz wrote:
 On 11/15/2010 09:24 PM, Stephen Ecob wrote:

 On Tue, Nov 16, 2010 at 12:47 AM, Kai-Martin Knaak
 kn...@iqo.uni-hannover.de  wrote:

 Stephen Ecob wrote:

 Motivation
 Having laid out a couple of boards with PCB 20091103 I became aware of
 some bugs in the autorouter that made the job difficult:

 Are you talking about the default auto router. Or is this about the
 shiny,
 new toporouter?

 I'm talking about the default auto router.


 Oh, that's a pity. But are there any common parts of source code which both
 routers share? I mean - if you fix some bug in default auto router, will
 that fix the same bug in toporouter?

 I suppose that if Anthony Blake finishes his toporouter someday, all effort
 for improvement the default autorouter may be pointless. Toporouter's
 algorithm is really better, but there are failed asserts sometimes.

 Jan Martinek


 ___
 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling

2010-11-11 Thread Rick Collins


At 05:31 PM 11/11/2010, you wrote:

Alberto,

Thanks for the comments.

On 11/11/2010 04:24 PM, Alberto Maccioni wrote:

With a dxf file, in a CAM program, you can program your fine line 
cutting with a tiny v bit, then program apocket operation with a 
larger bit to remove the remaining copper.

Are you sure you want to do this? Is it for aesthetic reasons or
because of better isolation?
Besides thrashing large amounts of bits and requiring hours of work it
won't make your pcb's work better; if you need good isolation it's
better to insert several traces between the ones you want to isolate.


I would like to remove floating copper for RF and static electricity 
reasons. The 'pcb' program thinks that floating copper is enough of 
an issue to have code to detect and remove it.


I have seen blogs where guys take tweezers and rip the floating 
copper off the boards they have isolation milled. I would like to 
have the cnc machine do it. I agree that it will destroy lots of 
bits, though. It is a trade-off between disposable etching chemicals 
and disposable bits.


My understanding is that the bits tend to break just at the tip of 
the conical bit.  The broken bits can still be used for removing the 
floating copper perhaps.  This may not apply to your machine as this 
was a very old machine I saw being used.



Rick  




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

Re: gEDA-user: Restrict facility?

2010-11-09 Thread Rick Collins

You might want to take a look at FreePCB.  This is a Windows based 
PCB layout tool that interfaces to an autorouter which does support 
keepout regions for the router.  www.freepcb.com


Rick


At 09:47 PM 11/9/2010, you wrote:
I am looking at migrating from Eagle to PCB and thus am a complete 
newbie to PCB, although an old hand at printed circuit boards.


Eagle has a facility, both in component packages and on the board, 
where you can create rectangular areas that are no go for the 
router. I've spent some time looking, thus far without success, to 
see if there is an equivalent facility in PCB. That could be because:


 a) There is no such facility.
 b) The manual fails to mention it.
 c) It's there but I'm just missing it.

Can anyone confirm that such a facility does/does-not exist? In 
Eagle these are called restrict layers but searching the geda 
archive for restrict yielded only some acrimonious discussion about GPL.


Thanks

Cam Farnell


___
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 Assembly process

2010-10-17 Thread Rick Collins

I'm not sure which assembly house you plan to use, but all that I 
have used work the same way.  You provide the Gerbers (or that 
boards), a BOM and an XYRS file.  If they can't work with that, they 
won't be doing much business.   Is TARGET a PCB layout program?  When 
in doubt, you need to ask the assembly house, not 
strangers.  Communicate with your vendors, they will appreciate it.


Rick


At 03:22 PM 10/17/2010, you wrote:

Hello all,

I have an question for PCB board assembly company's in Europe.

At the moment i work together with PCB pool i generate with the pcb 
program gerber files and submit it via web and a

few day's later i got my PCB :) works very nice.

Very cool stuff thanx's a lot for this wonderful and genius software.

At the moment i plan to do a produce of 400 PCB's. And let the 
machines the assembly part.


 at the moment PCB pool supports only EAGLE or TARGET files for 
automatic assembly machines.


Is there an tutorial which information need an assembly company for 
part's placement ?

Or is there an list of assembly company's that can do this with geda PCB ?


best regards

Michael
--
[] this Email is made of 100% Recyclable elektrons
[] url  : www.smog.at
[] mailto : michael.the...@smog.at
[] key: www.smog.at/key





___
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: Unresolved rat lines, zero-ohm resistor, wire bridge

2010-10-16 Thread Rick Collins

I'm not sure I understand the problem with #1.  Can't you take the 
mostly routed design and back annotate the jumpers so that they are 
parts in the original schematic?  Then you get what you are looking 
for in #3 which you think is the best approach.


Rick

At 12:17 PM 10/16/2010, you wrote:

Hello,

I am trying to design a single-sided board with SMD components only 
(no drilling). The toporouter (which is absolutely awesome, btw.) 
routes almost all rat lines with only several left unresolved. But, 
what now? I can do several things:


1) Make the PCB and connect suitable places with wire.
  disadvantage: The PCB cannot be published without further 
explanation. And, it is not beautiful.


2) Insert dummy components like zero-ohm resistors or jumper wire in 
schematics with the hope, that some traces can be routed below the components.
  disadvantage: The schematics looks crazy. Moreover, surprisingly, 
it does not help. The autorouter sees different circuit and 
magically designs different traces. Often, number of unresolved rat 
lines increases. And, it is totally unpredictable where exactly to 
insert the dummy components and how many of them.


3) Make double sided PCB and the other side realize with wire bridges only.
  Disadvantage: This is a bad idea as number of vias is much higher 
that number of unresolved rat lines.


4) Use #1 but do some manual post-processing.
  disadvantage: At any change in the schematics the manual work 
must be done again.


The best solution (for me) would be #3 if:
- the number of vias would be as small as possible
- vias should be in pairs so that the wire connects exactly two.

Or this:
- if some rat lines cannot be solved, make a pair of pads (or pins) for them.

Does anyone have an idea?

Thank you very much,
Jan Martinek


___
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: Unresolved rat lines, zero-ohm resistor, wire bridge

2010-10-16 Thread Rick Collins

No, I am not suggesting #2.  You don't want to reroute the design 
after you add the jumpers.  Once you have a routed design, add the 
jumper pads to the layout so that wires can be added to the bottom of 
the board to complete the unrouted connections.  Then use back 
annotation to update the schematic and you are done!  DO NOT try to 
auto-route the layout again from the schematic.  As you say, this 
does not work well.


You have to accept the fact that if the auto-router does not complete 
the routing, you have to manually route the remainder of the 
board.  Once you do manual touch-up of any kind, that is no longer a 
part of the automatic process and will need to be redone if you want 
to change the design later.  In your case, if you want to auto-route 
the board again, you need to remove the jumpers from the schematic, 
make the changes to the schematic, rerun the auto-route, do your 
touch-up again, back-annotate the schematic and be happy. :^)


Rick


At 01:29 PM 10/16/2010, you wrote:

Hi,

no, it really does not work. I think you are suggesting #2. The 
autorouter is unpredictable. If I change anything in the schematics, 
the autorouter comes with different design, often worse than before 
with more unresolved rat lines. Adding a jumper in schematics does 
not result into reducing rat lines.


One example: I had six unresolved rat lines. I added six resistors 
into appropriate places in schematics. And, voila, I ended up with 
_nine_ unresolved rat lines and almost no traces went underneath the 
resistors. The autorouter did not find the solution.


Jan Martinek

On 10/16/2010 06:53 PM, Rick Collins wrote:

I'm not sure I understand the problem with #1.  Can't you take the
mostly routed design and back annotate the jumpers so that they are
parts in the original schematic? Then you get what you are looking for
in #3 which you think is the best approach.

Rick

At 12:17 PM 10/16/2010, you wrote:

Hello,

I am trying to design a single-sided board with SMD components only
(no drilling). The toporouter (which is absolutely awesome, btw.)
routes almost all rat lines with only several left unresolved. But,
what now? I can do several things:

1) Make the PCB and connect suitable places with wire.
disadvantage: The PCB cannot be published without further explanation.
And, it is not beautiful.

2) Insert dummy components like zero-ohm resistors or jumper wire in
schematics with the hope, that some traces can be routed below the
components.
disadvantage: The schematics looks crazy. Moreover, surprisingly, it
does not help. The autorouter sees different circuit and magically
designs different traces. Often, number of unresolved rat lines
increases. And, it is totally unpredictable where exactly to insert
the dummy components and how many of them.

3) Make double sided PCB and the other side realize with wire
bridges only.
Disadvantage: This is a bad idea as number of vias is much higher that
number of unresolved rat lines.

4) Use #1 but do some manual post-processing.
disadvantage: At any change in the schematics the manual work must be
done again.

The best solution (for me) would be #3 if:
- the number of vias would be as small as possible
- vias should be in pairs so that the wire connects exactly two.

Or this:
- if some rat lines cannot be solved, make a pair of pads (or pins)
for them.

Does anyone have an idea?

Thank you very much,
Jan Martinek


___
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




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

Re: gEDA-user: pcb crooked traces

2010-10-12 Thread Rick Collins


At 11:26 AM 10/12/2010, you wrote:


But if we limited everything to 2m, using unsigned integers, we'd
be okay with 32 bits. I'm not sure what you're saying here.

Having said that, I still want negative coordinates. So do we need
to limit things to 1m? Yuck.


He is saying that to avoid overflow in internal calculations, you 
could have parts up to 1 meter on a board up to 1 meter with the part 
placed at the upper edge of the board putting the upper edge of the 
part at 2 meters.




Well, ``probably slower'' isn't a good reason for anything. I doubt
your speculation on both 32- and 64-bit machines, so testing will
need to be done.


WHOA!!!  We should actually measure how much the application would 
slow rather than speculate or use pointless metrics such as how fast 
a test program doing nothing but a math operation runs...  what a concept!!!


So who is going to bell the cat?

Another thought.  Using 1 nm as the base unit does everything anyone 
wants, but limits the max size board on 32 bit machines.  But do we 
really need 1 nm resolution?  This allows exact representation in nm 
of 0.01 mil in inches.  Do we need exact representation of 0.01 
mil?  Would 0.1 mil be adequate?  Using 10 nm as the base unit 
internally gives exact representation down to 0.1 mil and allows much 
finer resolution, just not exact representation in inches.  With a 10 
nm base unit the max board size goes to 20 meters which certainly is 
enough for everyone, including those wishing to design kitchens!


Durn metric system!  Why can't our system be good enough for the rest 
of the world? :-\


Rick  




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

Re: gEDA-user: pcb crooked traces

2010-10-12 Thread Rick Collins


At 12:46 PM 10/12/2010, you wrote:

On Tue, 2010-10-12 at 11:44 -0400, Rick Collins wrote:

 WHOA!!!  We should actually measure how much the application would

For x86 architecture you may read

http://en.wikipedia.org/wiki/X86
http://en.wikipedia.org/wiki/X86-64

it mentions MMX and similar, which made fast 64 bit integer operation
available for 32 bit systems -- if the employed compiler supports it.

Do you intend to use our PCB in future or even start coding?


Do you have to code to use PCB?  I thought this was the user mailing list???

BTW, who exactly is meant by our?

Rick



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

Re: gEDA-user: pcb crooked traces

2010-10-10 Thread Rick Collins

I don't think you are trying very hard.  If the value input by the 
user in metric is rounded off to a value that is not exact, there is 
a loss of precision that can not be recovered no matter how well 
programmed the application is.  I gave an example of when this would 
be significant and you seem to think that the programmer can make 
special cases to work around this.  I'll lay it out again working in 
the abstract to show the possibilities.  If you don't like the 
abstract, just adjust for a 0.8 mm pin spacing and you will see a 
real example that is close to the limit.


The user has a connector with metric spaced pins.  When the metric 
value is input, the value is rounded off to the nearest 0.01 mil 
giving an error of 0.005 mil.  At this point there is no way to 
recover that error, it is recorded in the system that way and the 
precision is lost.  This value is used to calculate the position of 
all the pins in the connector resulting in an accumulated error of 
0.005 * N.  At 100 pins this the accumulated error is 0.5 mil.  That 
may not be a show stopper, but I would prefer to avoid it if 
possible.  At 200 pins the accumulated error is 1.0 mil, 
etc.  Clearly this is quickly reaching a point of being very unacceptable.


Earlier you suggested that this can be dealt with by doing the pin 
position calculations in metric before converting to inches.  Great 
idea, but who does the calculations?  The user?  The tool that 
generates the footprint?  How do you educate the users so they all 
are aware of this problem so they can always work around it?  I think 
this is a poor solution since it first requires that the limitation 
of the tool be known and worked around by everyone in the solution 
path.  OR... the tool can be changed to remove the limitation by 
using 1 nm as the base unit which can represent both metric and 
inches ***WITHOUT ANY LOSS OF PRECISION***.  It is that simple.  Why 
adopt a messy, complex, error prone solution when a solution is 
available that deals with the problem simply, accurately and permanently?


Rick


At 10:12 AM 10/10/2010, you wrote:

Rick Collins wrote:
While accumulation of error is an issue with floating point, the 
connector or any predefined

shape is a particularely bad example:
At least I wouln't convert the spacing and then sum up the erratic 
value but convert
all the original values, which gives exactly 1 conversion error 
per position, irrespective
of the number of pins/position. And that's exactly how the read 
routines operate.
To do it the wrong way, they would need to be fortune tellers, 
because there is

no 'array' element in new-lib files.


Then please come up with some of your own.  I am sure there is no 
shortage of examples just because I haven't thought of them.
I believe such an example will be hard to find in a well programmed 
CAD application.
The reason is, that significant accumulation of discretization 
errors happens when

nummerous small values get added to a large value or with small differences of
large numbers.
Typical examples for these problems are:

*) solving large badly conditioned linear equation systems
*) numerical treatment of initial value problems of ordinary 
differential equations

*) statistical computations

Even for those apps there are algorithms that account for the problem -
skilled developers are aware of it and avoid it.
The general procedure in a CAD system is, to place primitives in a virtual
space with as few operations as possible and derive some data (screen view,
gerbers, drill coordinates,...) from this model as straight forward 
as possible,

again involving only a hand full of operations per primitive. Since the
primitives are independent of each other, there is no accumulation of error.

One example of the tiny difference of large numbers is, to fill an area
with parallel traces, using the same trace width as center distance.
Depending on the display scale you might see chinks. As far as I know,
this is known bad practice. I'm not a developer of pcb, so if there
really are issues with this, others speak up please.


___
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: GNUduino - Arduino made with gEDA


I assume one is gEDA... what is the other?

Rick


At 01:56 AM 10/9/2010, you wrote:
Good on you.  It really gripes me when open hardware projects use 
something like Eagle for the schematic/pcb flow.  The current object 
of my derision for doing that is the RepRap foundation.  Today there 
are at least two reasonable choices for open source schematic and 
pcb design -- why do open hardware projects go with closed-source 
tool flows?  I boggle.


-dave


On Oct 8, 2010, at 9:56 PM, jeffrey antony wrote:

Hello all,
I have designed a board named GNUduino



___
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 crooked traces


At 05:44 AM 10/9/2010, you wrote:

Is this seriously turning into a pissing match


So stop pissing on each other.  I'm getting tired of the 
blow-by.  This goes for Armin as well.  Is there some reason we can't 
keep this civil?



Rick



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

Re: gEDA-user: pcb crooked traces


At 06:51 AM 10/9/2010, you wrote:

Rick Collins:
 At 05:04 PM 10/8/2010, you wrote:
 Rick Collins:
   At 02:28 PM 10/8/2010, you wrote:
   Andrew Poelstra:
 On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote:
...
 With integer types you get aliasing artifacts, which actually is a
 rounding error. We have this problem in the current incarnation of pcb.

 That is what you aren't getting.  The problem is not aliasing in
 any way I understand aliasing.
...

Maybe I should use the word truncation instead. I thought that
the aliasing effect would make my point obious because most of you
have experienced it.

Wikipedia:
 In signal processing and related disciplines, aliasing refers to an
 effect that causes different signals to become indistinguishable (or
 aliases of one another) when sampled.

 So, in what way are floats worse than ints (I'm talking about
 representaion, not about performance) and why could we not reasonably
 use floating-point?

 Floats aren't any worse if they have the resolution... but they
 aren't any better either!

Agree, though there are corner cases e.g. x/3 gives truncation for
integers, and big_value * big_value2 can give overflow where a double
will thrive.

...
   C, As a side note, if you use double's for the internal representaion,
 then you don't loose precision compared to having an 
int32_t. You can

 convert an int32_t to an double and back without loosing precision.
  
   The issue is not using singles or doubles.  The issue is whether the
   base unit is metric (which can perfectly represent inch units of
   interest) or whether the base unit are inch based which can't
   represent inch units perfectly.
  
   I suppose they could always change the base units to some small
   fraction of a mil so that even the accumulated error would always be
   negligible.  But why bother changing and only getting an
   approximation if you can get it perfect?
 
 Ack. I know that using a basic unit of mm's or part thereof will solve
 the mil/mm problem.
 
   My point was that this does not have anything with integer vs.
 floating points.

 Ok, I agree.  I guess all this was about nothing.

Yes, don't dissmiss floating-point on false grounds. If it is for the
performance, fine, but then you have to test.

If ints and doubles comes out equally in a performance test, I'd choose
doubles, since arcs, sin() etc. is done in doubles (unless you are using
your own function tables).

 And I also hinted the reader that he/she could swap the
 32bit ints for doubles and you would get the exactly the same results
 (unless you divide of cause, then doubles comes out better).

 Now I'm lost again... maybe.  If you stick with inches, no, using
 doubles buys nothing.

Well, it buys me a little, but it is not the solution for the mil/mm
problem.

  The point about using doubles is that to use
 metric, it seems like going with a unit of nm is appropriate.   Then
 you are limited to 2 or 4 meter max value with 32 bit ints.  Going to
 double resolves that problem by giving you another factor of 4
 billion in your range.

 I guess we are talking past each other while agreeing... yes?

Absolutely.



Unfortunately, you argue each little point and have not stated 
much.  My point is that switching to a metric internal representation 
will allow inches to be represented exactly down to 0.01 mil as well 
as metric down to 1 nm.  This will eliminate some of the current 
problems and introduce none other than changing the current size 
limit to 2 meters.  In reality, this is extremely unlikely to be any 
issue, but because it is smaller than the solar system, some folks 
seem to think we need to have an alternate solution.  Using 64 bit 
doubles would allows the entire solar system to be represented on a 
PCB in 1:1 scale, but might create a noticeable slow down, however we 
don't know that for sure since no one can say how much the slow down 
would be.  Using floating point would allow perhaps the entire galaxy 
to be represented on a 1:1 PCB, but I am speculating now since there 
may not be equipment large enough to build such a board.


Do we both agree on this?  Anyone else disagree?

Rick 




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

Re: gEDA-user: pcb crooked traces


At 03:36 PM 10/9/2010, you wrote:

Rick Collins gnuarm.2...@arius.com writes:

 To be perfectly correct, anyone who needs more than 84x84 inch boards
 will need to recompile PCB with 64-bit units.  If it is me, I have no
 idea how to, so I can not.  But I don't plan to.  If I need boards
 larger than 84x84 inches, I will hire one of you to either layout the
 board for me or to recompile the tools.  :^)

Any 64-bit Linux distro will provide it ready to go.



64 bit Linux distos include a 64 bit version of PCB?

Rick



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

Re: gEDA-user: GNUduino - Arduino made with gEDA


I thought maybe it was FreePCB.

Rick


At 09:14 PM 10/9/2010, you wrote:
KiCAD --  I haven't tried it myself, so I don't know much about it's 
capabilities.


-dave

On Oct 9, 2010, at 3:48 PM, Rick Collins wrote:

 I assume one is gEDA... what is the other?

 Rick


 At 01:56 AM 10/9/2010, you wrote:
 Good on you.  It really gripes me when open hardware projects 
use something like Eagle for the schematic/pcb flow.  The current 
object of my derision for doing that is the RepRap 
foundation.  Today there are at least two reasonable choices for 
open source schematic and pcb design -- why do open hardware 
projects go with closed-source tool flows?  I boggle.


 -dave


 On Oct 8, 2010, at 9:56 PM, jeffrey antony wrote:

 Hello all,
 I have designed a board named GNUduino



 ___
 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




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

Re: gEDA-user: pcb crooked traces


At 06:31 AM 10/8/2010, you wrote:

On Fri, Oct 8, 2010 at 5:46 PM, Armin Faltl armin.fa...@aon.at wrote:
 Gabriel Paubert wrote:

 Really, the inch is by definition 2540µm, not the other way around since
 over 50 years ago.


 As far as I know, 1 = 25400um, but I see your point ;-)

 The only practical consideration I see is, that the internal unit of PCB
 allows handling with integer-arithmetic (makes comparisons a lot
 faster and safer than floating point).
 Assuming 32-bit signed numbers with 1/100mil this gives:
   254nm resolution and +-545.46m coordinate range
 32-bit signed and 1nm gives:
   1nm resolution ;-) and +-2.147m coordinate range


The point is that using 1 nm allows both metric 
and inch coordinates to be represented without 
introducing errors.  Working in units of 0.01 mil 
does not allow metric to be expressed without 
rounding error.  This error may show up in most 
designs, but if a consideration is to allow 
boards larger than 2 meters across, I would think 
that the possibility of rounding error for metric 
measurements accumulating to a significant error could be a problem.




 I don't know, if pcb really uses fix-point arithmetics, but even if
 not a reasonable internal unit has some importance. AFAIK with
 floating point, the average internal number should be around 1.

 HTH, Armin


No floating point, all integer to avoid rounding errors.

DJ,  are the pcb units still wrapped in the accessor macros for
converting between internal representation and real world values?

If so...  Guys change the converters and have at your hearts content.
It should be a 2 hour patch.

Now for conversion errors, are you really seeing errors in your metric PCBs?

As far as I am concirned the internal unit is meaningless provided it
is fine enough.

I know no fab house that is going to have a 
tolerance as good as 254nm or .01mil


That is not the concern.  The problem is that on 
input a metric value will have a rounding 
error.  When that error is compounded by the 
arithmetic (for example accumulative error in a 
large connector or chip pin spacing) the final error can become significant.




So as far as it matters in the real world, getting other things done
in pcb is much more important, than a conversion to metric base units.
 meaning proposing that we make PCB 64 bit and nanometers is
redicolus.  We will double our ram usage and not gain ANY benifits.


Going to 64 bits buys you nothing if you don't 
increase the resolution of your internal units... 
other than allowing you to design PCBs nearly the size of the solar system.




And to think this started out cause I suggested to use a really corse
grid to start layouts, and keep things pretty.

Use metric if your primarally using metric parts and use mils if your
using inch defined parts.

Chances are that people arn't placing their parts by snapping to pin
one to move it on grid when placing anyhow.


Why not?  That is exactly what I do.  I put my 
parts on grid and where practical, set the grid 
to match my parts.  That keeps my traces from having jaggies.


BTW, in the program I use, I can turn on snap to 
grid and route orthogonal and 45 degrees 
only.  This allows me to route from pins to the 
grid without having any trace segments that are 
not on a 45 degree angle.  Does PCB also support this?




BTW, I'd vote for 1 unit, and a scale value.  That is if you are
making a 10 meter antenna,  Then you set the PCB's scale to 0.1mm.


I'm not sure what that even means.  Are you 
suggesting that the internal representation be adjusted by the user?


Rick



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

Re: gEDA-user: pcb crooked traces


At 10:01 AM 10/8/2010, you wrote:

On Fri, Oct 08, 2010 at 08:41:06AM -0400, Rick Collins wrote:
 At 06:31 AM 10/8/2010, you wrote:

 BTW, I'd vote for 1 unit, and a scale value.  That is if you are
 making a 10 meter antenna,  Then you set the PCB's scale to 0.1mm.

 I'm not sure what that even means.  Are you suggesting that the
 internal representation be adjusted by the user?


Not quite. The ``internal resolution'' would be the same, but the
visible units (on the gui and in the exports) would be scaled by
the scale factor, on a per-.pcb basis.



If I understand correctly, this would not solve the problem.  The 
problem results from working with data in metric format which can not 
be represented exactly using an inch based internal integer.  If the 
internal representation is metric, then inches can be represented exactly.


Are you suggesting that 32 bit integers representing nm could be used 
and the 2/4 meter limitation could be resolved by using a scale factor?


Am I up to speed now?

Personally, I can't imagine a PCB larger than 2 meters much less 4 
meters.  Or is the possibility of uses other than PCB design being 
considered here?


Rick 




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

Re: gEDA-user: pcb crooked traces


At 02:10 PM 10/8/2010, you wrote:


 FYI -- the largest dimension I ever did on a board was 54 inches.

The largest board I've done in PCB was a quarter mile... I had a my
house element.  It was tiny.

But I was only testing pcb's limits at the time...

 I couldn't say what the standard panel sizes are in the industry,
 but I could make an effort to find out.

I'm guessing they're around 0.5 to 1.0 meter, based on the size of the
drill machines...


To find out would probably require a few calls to some of the larger 
PCB fab houses.  If the drill machine were the ultimate limit, I 
would think that would only limit one dimension.  Even if the table 
doesn't travel enough to cover the whole board, it can be 
repositioned after the first pass.  But you can't drill further into 
the board than the machine will reach.  I guess it may not be the 
same as CNC work, but I've done this with my drill press a number of times.


Rick



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

Re: gEDA-user: pcb crooked traces

And a board can be secured easily from two sides.  It is the 
alignment that requires some effort, but it can be done.


At 02:28 PM 10/8/2010, you wrote:


All the drilling machines I've seen are limited in both directions.
The board stack needs to be firmly pinned in place to ensure accuracy.


___
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 crooked traces


At 02:55 PM 10/8/2010, you wrote:


 Please forgive my ignorance, but can't one just define a 64bit
 integer on a 32bit system?

Yes, but there's a loss of performance if you do that.


Any idea of the loss of performance given that virtually all PCs 
these days are actually 64 bit machines?  The laptop I am typing this 
on is a 64 bit, dual core 2 year old bargain basement priced machine 
I bought in a hurry for $550.  It would have been a $400 machine, but 
I wanted the 17... er, 430 mm display.


But then I forget about the people who want to design kitchens on 
their iPads... ;^)


As someone pointed out, couldn't that be a build option?  If someone 
needs to design boards larger than 2 meters, would it be a hard thing 
to do to build a 64 bit version?


Rick 




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

Re: gEDA-user: pcb crooked traces


At 02:28 PM 10/8/2010, you wrote:

Andrew Poelstra:
 On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote:
...
  The only practical consideration I see is, that the internal unit of PCB
  allows handling with integer-arithmetic (makes comparisons a lot
  faster and safer than floating point).
...

That might be true, but if you are talking about an internal
representation with nm resolution, then you have the same problem as
for the floating point, there are too many separate values that
basically is the same value and you can't tell them apart looking at a
board.

...
 I don't think we could reasonably use floating-point. There is no
 room for rounding error when designing tight areas of a PCB.

That is nonsense, it is all about tolerances.

1, going from physical components to footprint file is basically a
   big averageing operation

2, going from pcb-file to physical pcb is a big rounding operation
   with some added noise, or do you believe you can make pcb's with
   nm's precision?


Yes, it is about tolerance... and error.  How much error will be 
introduced into a design if the system rounds all metric measurements 
to 0.01 mils?  How much tolerance is acceptable?   When you can 
answer these two questions for all designs and all users you can't 
expect anyone to believe this is nonsense!  If you have a 
connector, for example, with 100 pins spaced on metric centers, the 
accumulated error can approach a half mil or 0.0127 mm.  That may be 
a significant fraction of the pin spacing and likely not a good 
idea.  Larger connectors would have more accumulated error.


I think your response above shows you don't actually understand the 
issue.  Of course the issue is one that would not be of concern to 
most users, most of the time for most designs, by far.  But it 
started with an issue of traces that were showing up as multiple 
jagged traces where a straight one was expected because... a metric 
grid was selected and the round off error was making grid points off center.


There are other possible issues.  When a metric input value is 
rounded off and then replicated, as someone said, for large 
connectors or mechanical attachments, the accumulated error can 
become significant and parts not fit.



...
 Suppose we stored a scaling factor in the .pcb files, of x10, x100,
 x254, etc? Then we could use nanometer precision by default and go
 bigger if we need a bigger board.

A, What is an integer plus a scaling factor?
   -- it is a floating point value.


No, it is a block floating point value.  In this case the scale 
factor is not applied to the entire design until you display values 
or produce output.  The internal calcs are still all integer.




B, If you implement it as an integer (value) and an integer (scale),
 you could just as well do the scaling thing in some postprocessing
 step, outside of the pcb program. That is basically how gschem handles
 dimensions, it doesn't care.


Or you can do it inside of PCB so that the user doesn't have to 
remember that all the displayed units are off by a factor of 10 or 2 or 5.




C, As a side note, if you use double's for the internal representaion,
 then you don't loose precision compared to having an int32_t. You can
 convert an int32_t to an double and back without loosing precision.


The issue is not using singles or doubles.  The issue is whether the 
base unit is metric (which can perfectly represent inch units of 
interest) or whether the base unit are inch based which can't 
represent inch units perfectly.


I suppose they could always change the base units to some small 
fraction of a mil so that even the accumulated error would always be 
negligible.  But why bother changing and only getting an 
approximation if you can get it perfect?


Rick 




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

Re: gEDA-user: pcb crooked traces


At 03:42 PM 10/8/2010, you wrote:


 Any idea of the loss of performance given that virtually all PCs
 these days are actually 64 bit machines?

My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit
OS for compatibility.  So, 64-bit math is a performance hit for me.
We can have the default unit be whatever the native long size is,
32-bit on 32-bit, 64-bit on 64-bit, so you always get the biggest
fastest size.  But we can still detect when your fastest size isn't
big enough for some odd HUGE layout file.


I am asking how much of a performance hit.  Has anyone actually done 
anything to calibrate this?  Unless we have some idea of how much the 
performance hit would be, there is not much point in discussing 
it.  A 1% slowdown is not worth talking about.  A 1000% slowdown 
would be an issue.  Numbers in between would be worth discussing.


Performance issues fall into three categories in terms of impacting 
the user.  A delay up to 0.3 seconds is not really noticeable as a 
delay to the user.  From there up to 3 seconds is noticeable, but not 
enough to lose focus on your task.  About 3 seconds to 30 seconds 
delay you lose focus on your task which significantly impacts your 
productivity and is very irritating.  Beyond about 30 seconds and the 
user is inclined to leave the work station.  Do you think the 64/32 
bit performance issue would push any of the current operational 
delays across any of these thresholds?




 As someone pointed out, couldn't that be a build option?  If someone
 needs to design boards larger than 2 meters, would it be a hard thing
 to do to build a 64 bit version?

Of course it can.


Then why should we worry about the remote possibility that a user 
will want a PCB larger than 2 meters?  Their problem could be solved 
by creating a 64 bit version.  I just saw your later post that 
clearly states your position so I guess I have my answer.


Rick 




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

Re: gEDA-user: pcb crooked traces


At 05:04 PM 10/8/2010, you wrote:

Rick Collins:
 At 02:28 PM 10/8/2010, you wrote:
 Andrew Poelstra:
   On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote:
 ...
The only practical consideration I see is, that the 
internal unit of PCB

allows handling with integer-arithmetic (makes comparisons a lot
faster and safer than floating point).
 ...
 
 That might be true, but if you are talking about an internal
 representation with nm resolution, then you have the same problem as
 for the floating point, there are too many separate values that
 basically is the same value and you can't tell them apart looking at a
 board.
 
 ...
   I don't think we could reasonably use floating-point. There is no
   room for rounding error when designing tight areas of a PCB.
 
 That is nonsense, it is all about tolerances.
 
 1, going from physical components to footprint file is basically a
 big averageing operation
 
 2, going from pcb-file to physical pcb is a big rounding operation
 with some added noise, or do you believe you can make pcb's with
 nm's precision?

 Yes, it is about tolerance... and error.  How much error will be
 introduced into a design if the system rounds all metric measurements
 to 0.01 mils?  How much tolerance is acceptable?   When you can
...

Please, I was commenting about the misunderstandings about
floating-point, not about mils and mm's.

With integer types you get aliasing artifacts, which actually is a
rounding error. We have this problem in the current incarnation of pcb.


That is what you aren't getting.  The problem is not aliasing in 
any way I understand aliasing.  It is that you can't represent an 
exact metric value in an inch system.  When you multiply an arbitrary 
number of few digits by 2.54 (convert inches to metric) you get two 
or three more digits than you started with. Try dividing the same by 
2.54 (convert metric to inches) and you get a lot more digits than 
you started with, maybe infinite, I'm not sure.  So in an inch based 
system you will never be able to represent metric numbers 
exactly.  The opposite is not true, a metric based system can 
represent an inch value exactly.  So you will not get a round off 
error of an input value.  All points you need to calculate will be 
exact and the jaggies won't happen.


This is not the same a finite resolution of a display or other bit 
mapped output.  We aren't talking about the pixels lighting up on a 
CRT... er, LCD.  We are talking about the end point of a trace not 
being in the right position so that a 45 degree trace can not connect 
them... exactly.  That is what produces the jagged traces the OP 
complained about, if I understand the discussion correctly.




So, in what way are floats worse than ints (I'm talking about
representaion, not about performance) and why could we not reasonably
use floating-point?


Floats aren't any worse if they have the resolution... but they 
aren't any better either!




 There are other possible issues.  When a metric input value is
 rounded off and then replicated, as someone said, for large
 connectors or mechanical attachments, the accumulated error can
 become significant and parts not fit.
...
   Suppose we stored a scaling factor in the .pcb files, of x10, x100,
   x254, etc? Then we could use nanometer precision by default and go
   bigger if we need a bigger board.
...
 C, As a side note, if you use double's for the internal representaion,
   then you don't loose precision compared to having an int32_t. You can
   convert an int32_t to an double and back without loosing precision.

 The issue is not using singles or doubles.  The issue is whether the
 base unit is metric (which can perfectly represent inch units of
 interest) or whether the base unit are inch based which can't
 represent inch units perfectly.

 I suppose they could always change the base units to some small
 fraction of a mil so that even the accumulated error would always be
 negligible.  But why bother changing and only getting an
 approximation if you can get it perfect?

Ack. I know that using a basic unit of mm's or part thereof will solve
the mil/mm problem.

 My point was that this does not have anything with integer vs.
floating points.


Ok, I agree.  I guess all this was about nothing.



And I also hinted the reader that he/she could swap the
32bit ints for doubles and you would get the exactly the same results
(unless you divide of cause, then doubles comes out better).


Now I'm lost again... maybe.  If you stick with inches, no, using 
doubles buys nothing.  The point about using doubles is that to use 
metric, it seems like going with a unit of nm is appropriate.   Then 
you are limited to 2 or 4 meter max value with 32 bit ints.  Going to 
double resolves that problem by giving you another factor of 4 
billion in your range.


I guess we are talking past each other while agreeing... yes?

Rick 




___
geda-user

Re: gEDA-user: pcb crooked traces

   At 05:07 PM 10/8/2010, you wrote:

  So... if pcb were to be limited to a 2 meter by 2 meter board,
 would
  it actually be a painful limitation to anyone?
 MAXINT nm is 84.5 inches (just over 7 feet).
 Anyone who needs more than 84x84 inch boards can re-compile PCB with
 64-bit units.

   To be perfectly correct, anyone who needs more than 84x84 inch boards
   will need to recompile PCB with 64-bit units.  If it is me, I have no
   idea how to, so I can not.  But I don't plan to.  If I need boards
   larger than 84x84 inches, I will hire one of you to either layout the
   board for me or to recompile the tools.  :^)
   Rick


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

Re: gEDA-user: pcb crooked traces


At 08:32 PM 10/8/2010, you wrote:


 A delay up to 0.3 seconds is not really noticeable as a delay to the
 user.

An 0.3 second delay updating the screen while moving a part is *very*
slow.  My refresh rate is already annoying, I don't need it to be more
annoying.


My point is that as a qualitative statement this may sound 
reasonable.  But unless you find a way to make a quantitative 
measurement, you really don't know that it will be more annoying 
because you don't know that it will be noticeable.


Many years ago I paid a premium price for a 486 based computer partly 
because of talk of the built in floating point being so much faster 
than software based floating point.  Only later did I find that in 
the end it made little difference in the apps I was running because 
most of the processor time was spent in the control portion of the apps.


I find that a lot of times things get optimized even if no one knows 
for sure they are a problem.


Rick



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

Re: gEDA-user: pcb crooked traces


At 08:44 PM 10/8/2010, you wrote:


 To be perfectly correct, anyone who needs more than 84x84 inch boards
 will need to recompile PCB with 64-bit units.  If it is me, I have no
 idea how to, so I can not.  But I don't plan to.  If I need boards
 larger than 84x84 inches, I will hire one of you to either layout the
 board for me or to recompile the tools.  :^)

If we do it right, it's as simple as:

   ./configure --enable-huge-boards
   make


After about a couple of hundred other steps...

Rick



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

Re: gEDA-user: pcb crooked traces

2010-10-07 Thread Rick Collins

Rather than picking an arbitrary grid I have found a happy mix of 
most of the small pitch metric parts (0.65 mm pitch MSOP, SSOP, 
TSSOP) and a 0.1625 mm grid.  I typically use 6/6 space/trace design 
rules which most houses work with ok which is the same as my grid 
(give or take the metric/inch difference).  The traces are on a two 
grid unit pitch and when I go diagonal, I just offset the corners on 
adjacent traces to get a good approximation to the space 7.5 mil.  I 
don't have to worry with an automatic tool to pack traces which I 
think makes rip-up and rerouting easier.


When I have other pitch parts, I just route out from the part and the 
second vertex will be on the grid.  BTW, the tool I use can route so 
that the traces are always on right angles or 45 angle.  Does PCB do 
that?  Then you don't get odd angle traces.


Rick


At 10:29 AM 10/7/2010, you wrote:
 I cannot get rid of the jagged diagonal lines on my 
design.  There's lots of them.  The picture shows a couple of 
examples.  I've tried different grid sizes, line widths, but 
nothing fixes the problem. Redrawing them in order to eliminate any 
sections does not help.  On PCB, it shows at some zoom levels but 
not others.  It is in the gerbers as well and it is in the 
photo-mode picture I attached.



Another thought,  When I am laying out mixed pitch mm vs mil parts, I
often leave the grid at a comfortable 10 or 25 mil setting. Turn on
snaps to pins and pads. Then I largly ignore the grid.  What I am
saying here is that I Use the grid as a guideline.

So to accomplish this I draw from the off grid pin out to the pcb and
let the 45degree tail end on the grid.  then off to the rest of the
layout, on grid.

When that tail is not quite correct, while drawing I use the u key to
undo the 45 degree tail,  this leaves the off grid stub that i can
continue drawing from.

Having a small grid usuially allows me to make a messier layout.


If these things don't help then we have a bug.

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: gschem sym files

2010-10-04 Thread Rick Collins

I have seen this handled in other CAD packages not by making the pin 
an NC in the symbol, but by having a feature in the schematic where 
the pin can be No Connected so that it is not flagged as an error 
if it has no wire.


Or course, it makes some sense to have a special type of NC in a 
symbol if the data sheet says to not connect it.  I have seen 
those.  They often don't even tell you why.  I think typically it is 
a factory use pin and they don't want any noise pickup.  Grounding it 
would upset the operation of the chip so it just needs to float with 
as little copper as feasible.  So either you should not be able to 
connect a wire to it (just make it a graphic pin and not a real pin) 
or flag an error if a connection is made.


Rick


At 12:24 PM 10/4/2010, you wrote:

 Since nc is just a piece of copper attached to the (plastic/ceramic)
 package, why should drc complain?

 A nc pin would be like pas, but gives no error if unconnected.

The documentation of the Renesas TinyH8 states:
... Do not connect anything to the nc-pins. They might be used as test
pins under certain conditions or used for damping purposes, which you don't
,know.

This would imply that a 'nc' should prohibit any connections to it
whatsoever, so there is no chance of a connection, and that another type:
'don't care' or 'ignore' or 'unknown' or 'x' should be made that will not
give an error if unconnected, but will also not give an error IF connected.

 I would also like to see a pwr_src pin type which would be the output of
 the voltage regulator (or source).  That way the DRC would warn you if
 you shorted two power sources together or if you forgot to hook one of
 your power input pins to the power plane (and only connected it to a
 capacitor instead).
 +1
+1
Very useful.


Andrew Miner




___
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 footprint guidelines

2010-10-03 Thread Rick Collins


At 08:24 AM 10/3/2010, you wrote:

Rick Collins wrote:
I really have no idea how things work in the gEDA/PCB world.  With 
FreePCB the library has a default orientation for parts and there 
is a centroid vector to allow the pin 1 orientation to be set 
compatibly with the Gerber files.  If you use someone else's design 
you need to verify that their library parts were done correctly or 
you need to use the same footprints which are a part of the layout 
and so are available.  There is no reason to screw up something as 
simple as this.
How the Gerber file looks depends on the footprint definition. Once 
one knows *exactly*

a) how the transformations work
b) that all libraries/generators(/custom made footprints) conform to 
a sensible standard
checking is as superfluous as with screw diameters and pitches and 
before that point

I don't believe it's simple enough.


I really don't know what you are talking about.  The footprint will 
show up on your layout in some orientation.  That is the orientation 
it will have on the board in the Gerber files.  How will the 
transformations affect that?  What you see is what you get.


You are making this way, way, WAY too complicated.

Rick 




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

Re: gEDA-user: new footprint guidelines

2010-10-03 Thread Rick Collins


At 06:09 PM 10/3/2010, you wrote:

Rick Collins wrote:

At 08:24 AM 10/3/2010, you wrote:

Rick Collins wrote:
I really have no idea how things work in the gEDA/PCB 
world.  With FreePCB the library has a default orientation for 
parts and there is a centroid vector to allow the pin 1 
orientation to be set compatibly with the Gerber files.  If you 
use someone else's design you need to verify that their library 
parts were done correctly or you need to use the same footprints 
which are a part of the layout and so are available.  There is no 
reason to screw up something as simple as this.
How the Gerber file looks depends on the footprint definition. 
Once one knows *exactly*

a) how the transformations work
b) that all libraries/generators(/custom made footprints) conform 
to a sensible standard
checking is as superfluous as with screw diameters and pitches and 
before that point

I don't believe it's simple enough.


I really don't know what you are talking about.  The footprint will 
show up on your layout in some orientation.  That is the 
orientation it will have on the board in the Gerber files.  How 
will the transformations affect that?  What you see is what you get.
Yes, what I see is what I get. And to see it, I have to read the 
source code of the CAD

system, unless it's stated somewhere more accessible - like in a standard ;-)


That's what you don't get.  You don't need to know diddly about the 
CAD system.  The CAD system will produce output files that match your 
layout as you have prepared it.  If it does anything else, it is very 
broken.  At most you might want to verify that the data in the XYRS 
file matches the Gerber files for a small number of representative 
parts.  Why do you think you need to verify the results by reverse 
engineering the code???  That is the stuff I am talking about over 
thinking the problem.   All you need to do is look at the output.




E.g., where is the centroid of a 3-leged part? Is it:
a) the center of the bounding box of the pads
b) the center of the bounding box of the pad centers
c) the center of gravity of the pad centers (each weight 1)
d) the center of gravity of the pad areas
e) (0, 0) in the footprint definition file (or a designated vector inthere)
...

That's what I need to know, before I can trust libraries and an XYRS files.
Tbh, I'm not particularely happy, that this seems to be handled by some
black magic withing 'pcb' instead of the library definitions.


When you find out what PCB does, a through e, what will that tell 
you?   If you don't know what the standard is, how will you know if 
your design is correct?


Rick 




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

Re: gEDA-user: new footprint guidelines

2010-10-03 Thread Rick Collins


At 10:23 PM 10/3/2010, you wrote:

On Mon, Oct 04, 2010 at 12:09:22AM +0200, Armin Faltl wrote:
 Rick Collins wrote:
 At 08:24 AM 10/3/2010, you wrote:
 Rick Collins wrote:
 I really have no idea how things work in the gEDA/PCB world.  With
 FreePCB the library has a default orientation for parts and there
 is a centroid vector to allow the pin 1 orientation to be set
 compatibly with the Gerber files.  If you use someone else's design
 you need to verify that their library parts were done correctly or
 you need to use the same footprints which are a part of the layout
 and so are available.  There is no reason to screw up something as
 simple as this.
 How the Gerber file looks depends on the footprint definition. Once
 one knows *exactly*
 a) how the transformations work
 b) that all libraries/generators(/custom made footprints) conform to
 a sensible standard
 checking is as superfluous as with screw diameters and pitches and
 before that point
 I don't believe it's simple enough.

 I really don't know what you are talking about.  The footprint will
 show up on your layout in some orientation.  That is the orientation
 it will have on the board in the Gerber files.  How will the
 transformations affect that?  What you see is what you get.
 Yes, what I see is what I get. And to see it, I have to read the source
 code of the CAD
 system, unless it's stated somewhere more accessible - like in a
 standard ;-)
 E.g., where is the centroid of a 3-leged part? Is it:
 a) the center of the bounding box of the pads
 b) the center of the bounding box of the pad centers
 c) the center of gravity of the pad centers (each weight 1)
 d) the center of gravity of the pad areas
 e) (0, 0) in the footprint definition file (or a designated vector inthere)

Take as an example a SOT89 transistor like NXP's BCX52-16 (I've
just used one in a recent design) and look at the recommended footprints:

Package page: http://www.nxp.com/#/page/content=[f=/packages/SOT89.xml]
Package drawing: http://www.nxp.com/documents/outline_drawing/sot089_po.pdf
Reflow footprint: http://www.nxp.com/documents/reflow_soldering/sot089_fr.pdf

I'm not sure what point a pick and place machine would like to
use as centroid, probably the crossing of the two axes in the
last drawing. This apparently rules out options b, c, and d, but
seems to work with option a.

I'm guessing here, but pick and place machine have to orientate the
part very fast, so it is important that they pick the component from
a principal axis of inertia. It is not always easy to determine where
the axis lies when the component is asymmetric, which is frequent with
power components.

For another example, look a DPAK or D2PAK components (SOT404, SOT428, etc).
I'm not even sure that they option a) would work, but it might be
a good default, provided you can override it.


Pick and place machine operators don't want you to tell them how to 
pick a part.  All they want from you is to tell them where on the 
board to put it.  That is why the XYRS file uses the centroid and not 
the center of mass.


The centroid is just the center of the extents of the part or the 
footprint.  It doesn't matter if the part has one, two, three or 
three hundred pins.  Just draw the outline of the entire part and 
find the center.  There are some parts where this can be a bit 
tricky, but those would be some really odd asymmetric switches and 
the like.  I know of no ICs that need anything more than a 
rectangular outline to find the centroid.


I don't know why there is a need to reinvent PCB assembly.  It is 
kept simple just because the more complex it is made, the less likely 
it will work right.


Rick  




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

Re: gEDA-user: new footprint guidelines

2010-10-02 Thread Rick Collins

How does that work?  I'd like to try that.  I guess it will only work 
for an XYRS file generated by PCB.  What is that format?  Maybe I can 
convert my XYRS file into that and check it.


Rick


At 03:56 AM 10/2/2010, you wrote:

FYI gerbv will put the xy file generated by pcb onto your gerbers.

Steve

On Sat, Oct 2, 2010 at 10:42 AM, Steven Michalske 
smichal...@gmail.com wrote:
 As you guys continue to debate this...  Look at how pcb makes the 
xyrs data files. You'll findout that it generates it from the pcb 
file not the library.  It takes the center of the part from the 
pins and pads.  Then it puts pin 1 somewhere consistent.  See the 
source for details.





 On Oct 2, 2010, at 5:55 AM, Rick Collins gnuarm.2...@arius.com wrote:

 At 05:34 PM 10/1/2010, you wrote:
 Rick Collins wrote:

 If for whatever reason the designer used 2 different footprints for
 the same part occuring
 several times on a board, if the footprints are position/rotation
 inconsisten...
 
  I have no idea why anyone would do that.

 Real world example:
 PhD student Foo designs some super noiseless detector circuit. The
 measurements turn out a success. Researcher Bar, a long time friend who
 works on some unrelated project, asks Foo for help to get him started on
 noiseless detector. PhD Foo gladly provides the schematic and layout. For
 his project Bar needs to add some minor features to the 
hardware. Of course,

 she uses a different local library than Foo ...


  Sure the designer can totally screw up a design.

 I wouldn't call this totally screwed.

 If you work on a design and use a different, incompatible 
library from the original without checking for consistency, yes, 
the designer totally screwed up.


 I really have no idea how things work in the gEDA/PCB 
world.  With FreePCB the library has a default orientation for 
parts and there is a centroid vector to allow the pin 1 orientation 
to be set compatibly with the Gerber files.  If you use someone 
else's design you need to verify that their library parts were done 
correctly or you need to use the same footprints which are a part 
of the layout and so are available.  There is no reason to screw up 
something as simple as this.


 Oh, I almost forgot, NEVER ask a PhD anything to design 
PCBs.  What the heck are you thinking???


 Rick


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



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




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

Re: gEDA-user: PCB: Change default file-filter in open-dialog

2010-10-01 Thread Rick Collins

Maybe this is too obvious, but if it is update or forward 
annotate, then why not call it that?  One of the things that makes 
learning a package difficult is having to learn new nomenclature.


As to toolbar vs. menu, I prefer to not clutter the toolbar with 
things that aren't used a lot, especially when they have major 
impacts on your work as in opps, I didn't mean to click THAT 
button.  Since I switched to a laptop I find my accidental button 
push rate has gone up a lot.  Would an update operation be undoable?


Rick

At 10:51 AM 10/1/2010, you wrote:


Import schematics is more of an update or forward annotate.  You
use it to migrate any changes in the schematic, to the layout.  It
really wants to be on a toolbar button...


___
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 footprint guidelines

2010-10-01 Thread Rick Collins


At 02:47 PM 10/1/2010, you wrote:

Rick Collins wrote:

Where I want to get us, is being a consistent customer, for whom they
no longer need to think about step b).


From what I can tell, they don't bother with the two steps.  The 
machine picks the part from the feeder and before placing it, the 
operator verifies it is oriented correctly.  Done once for a given 
feeder and a given side of your board, the rest of the parts from 
that feeder should be good.
If for whatever reason the designer used 2 different footprints for 
the same part occuring
several times on a board, if the footprints are position/rotation 
inconsisten...


I have no idea why anyone would do that.  Sure the designer can 
totally screw up a design.  What is your point?




This is 100% reliable and not really a lot of time on their part.
Even if they do the steps you are talking about, they will do the 
step I have outlined.  They aren't engineers and they don't think 
like engineers.  They don't want to figure out what things don't 
work, they just want to make them work.  Their way is much easier 
in the long run I am sure.
The guy talking to me has 'MSc.' before his name ;-) No idea how 
much he's involved with the

actual operation of the machines.
Even austrian farmers try to figure out and avoid reasons for 
problems - no cowboy mentality?


I don't care much about Austrian farmers.  I am talking about what 
board assembly houses do.  I am sure they are capable of working with 
specs and heading problems off at the pass.  But they seem to know 
what works best for them and assuming that everyone from the three 
different camps are on the same page is not something that works for 
them I gather.




See above / please check yourself.


I don't have PCB, so I can't check.
in that case you have to believe me or others, that with the 
internal coordinate system

of 'pcb' X+ is to the right and Y+ is down.


Why do I care what any PCB package uses internally?  If they don't 
have positive Y up and positive X down at the user interface, how the 
heck am I supposed to coordinate that with Gerber files and the rest 
of the world?  Why not use polar coordinates?  Are you talking about 
something truly internal or at the user interface?



The assembly house I'm talking to, offers to provide standard parts. 
I imagine,

they use a combination of machine vision and having resolved step a) from
above once and forever with their part suppliers.


When you say parts, do you  mean footprint data for the CAD packages?
No, I mean this assembly house holds some standard parts in store 
(0603, 0805 resitors, caps,...
of common values) and will sell them to you if you like - can save 
you and them

some hassle.


I use full turnkey.  They buy all the parts I need.  So far it has 
been TONS easier and I am still making good profits.



The bottom line is, ask your assembler what they want.  Don't 
assume anything.

I will.

[snip]

About the .xy-file I'll have to read, how the footprint coordinates
and placement in the board influence the actual values. I think it
will be a bit tricky to check the footprints, since pcb doesn't show
the true coordinates but computes an offset on the fly to make all
screen coordinates positive - this is a bad idea for working on .fp-files.


That doesn't make a lot of sense to me, but I'm not sure why it is bad.

To check, whether all the footprints I use conform to IPC-7351(B), esp.
if the centroid is at (0, 0) of footprint it would be easiest, to 
just load them

into the design program. But pcb is cheating on you: the footprint-definition
describes say a 2-pad part with pad-centers at (-2.0mm, 0mm), (2.0mm, 0mm)
and centroid at (0mm, 0mm). When loading the footprint definition 
(that's the .fp-file)

on it's own, pcb will do some guesswork to squeeze everything in it's
positive coordinate quadrant and compute an offset (failing occasionally btw.
leaving parts of text and lines in nirvana).

Then it will tell you that above pad-centers are at (0.7mm, 1.5mm), 
(4.7mm, 1.5mm)

and center mark at (2.7mm, 1.5mm). The same applies if the definition had been
(2000, -100), (2004, -100) and (2002, -100) - there's no way to tell 
the numbers

in the definition by looking at the GUI.


I don't care much how a CAD program works internally.  But it has to 
use the centroid of the part for indicating the coordinates of the 
part location or it is not compatible with the assembly system.   My 
assembly house didn't care much about the rotations since that is 
easily verifiable and fixed.  But if the coordinates are offset from 
the centroid they claim to have a hard time finding and fixing 
that.  The only coordinates that matter are what the designer sees 
and what shows up in the XYRS file.  I don't care at all how the CAD 
system arrives at the values.




And what I'm trying to figure out atm, to verify the data to be sent to the
assembly house is, how the footprint definition, the guess work and the
actual placement get

Re: gEDA-user: new footprint guidelines

2010-10-01 Thread Rick Collins


At 05:34 PM 10/1/2010, you wrote:

Rick Collins wrote:

If for whatever reason the designer used 2 different footprints for
the same part occuring
several times on a board, if the footprints are position/rotation
inconsisten...

 I have no idea why anyone would do that.

Real world example:
PhD student Foo designs some super noiseless detector circuit. The
measurements turn out a success. Researcher Bar, a long time friend who
works on some unrelated project, asks Foo for help to get him started on
noiseless detector. PhD Foo gladly provides the schematic and layout. For
his project Bar needs to add some minor features to the hardware. Of course,
she uses a different local library than Foo ...


 Sure the designer can totally screw up a design.

I wouldn't call this totally screwed.


If you work on a design and use a different, incompatible library 
from the original without checking for consistency, yes, the designer 
totally screwed up.


I really have no idea how things work in the gEDA/PCB world.  With 
FreePCB the library has a default orientation for parts and there is 
a centroid vector to allow the pin 1 orientation to be set compatibly 
with the Gerber files.  If you use someone else's design you need to 
verify that their library parts were done correctly or you need to 
use the same footprints which are a part of the layout and so are 
available.  There is no reason to screw up something as simple as this.


Oh, I almost forgot, NEVER ask a PhD anything to design PCBs.  What 
the heck are you thinking???


Rick 




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

Re: gEDA-user: new footprint guidelines

2010-09-29 Thread Rick Collins

At 08:38 AM 9/29/2010, you wrote:

Hi,

Rick Collins wrote:

At 04:53 PM 9/28/2010, you wrote:
For all those, that follow the discussion from here or vaguely
remember some other rotations:

Rick Collins wrote:
I had to go through all this some time ago and recently I wanted
to iron out all the difficulties so that the assembly house could
use my XYRS file (location and rotation data) directly without alteration.

That ended up being a fool's errand, but I did learn a few things.
IPC has a standard for this which everyone seems to use. For
two pin symmetrical parts, pin one is to the left. For IC type
parts, pin one is in the upper left quadrant for parts with pin
one in a corner or for parts where pin one is in the center of a
side pin one is on the upper most side. This is the zero degree
rotation point for the part. All rotations are counter-clockwise
from this position.
on 2010-08-15 Rick wrote in thread 'Specification of Rotations for
Auto Assembly':
I just found something that changes what I thought I knew. I
have a PDF of an IPC magazine from 2005 where they are touting a
leap forward in land pattern generation. An illustration
showing pin 1 in the upper left for SOT components is what I used
as my reference.
That and the post in the FreePCB forum of a normally very reliable
source. But I found a copy of IPC-7351 and it clearly says that
for SOT and most other IC parts, the original rotation is with pin
1 in the LOWER left. That is what FreePCB does in the library
editor by default.

This isn't Ricks fault: reading the 2005 IPC-7351 I can confirm
this, while the 2009 IPC-7351B says,

that pin 1 is in the upper left corner ;-)
Shall I comment on this ? I'll just use upper left...

I'm not sure what you are saying. Did you have a point you wanted to make?
The point I wanted to make is, that there's nothing wrong with our
memories but
that the 2009 version of IPC-7351 contradicts the 2005 version
(probably 2003 as I see now),
maybe in order to conform to EIAJ/ANSI 481C. So this conformance
should be veryfied.

Do you have a copy of the 2003 version of IPC-7351? I think there
was no 2003 version of the spec. If I understand the little bit I
can find on this it was only released in 2005.

I went through a very lengthy search for a rational basis for
picking a standard. Virtually no one seemed to actually know the
source of the standard they used or what anyone else was using. It
seems like the board fab and assembly business is full of cowboys
who just want to make the current project work rather than to
figure out a system that would help everyone. In the end I found
that the incorrect IPC-7351 that I found was an initial short form
version from 2003, limited to naming conventions and a brief
listing of pin 1 orientations, not a full spec. I had also found
some other materials that had wrong information attributed to
IPC-7351, but not official (dated in 2003). The officially
released standard came out after, in February 2005, with the pin 1
orientation of all ICs either in the top left or the top. Without
knowing the whys, I can see that IPC-7351 seems to be what is more
supported than anything else. IPC claims that IPC-7351 matches
EIAJ/ANSI 481C. I have not found an official copy of IPC-7351 that
shows any other orientation than what was stated. If you have an
official copy of the released IPC-7351 spec that says pin 1 of ICs
is anywhere other than top or top left, I would like to see it.
Regretably I do not have any official version (bought in paper
directly from the relevant standads body)
but only pdf-files from the internet, that show the different names
IPC-7351 and IPC-7351B and
the respective release dates of 2005 and 2009. Neither do I have an
EIAJ/ANSI 481C paper.

The latest reference I found now is:
http://landpatterns.ipc.org/IPC-7351BNamingConvention.pdf
The old version I may have been looking at is 2003, not 2005:

http://www.pcbstandards.com/forums/attachment.php?attachmentid=501d=1064619067

These are the naming conventions only and do not explain anything,
they just list some basics. The full spec from Feb 2005 is 92
pages. This rev has no suffix letter. There has been a rev A in Feb
2007 and and a rev B in 2010. I don't believe any of the released
revisions change any footprints that have been published, but rather
add new footprints.

about EIAJ/ANSI I found only:
http://www.smtnet.com/library/files/upload/The-Universal-PCB-Design-Grid-System.pdf
http://www.thefreelibrary.com/The+future+of+CAD+libraries%3A+will+IPC-7351+be+adopted+globally%3F+Take...-a0129548051

I don't find any info on EIAJ/ANSI 481C in the first reference. The
second is the same article I found the referrence in. Tom Hausherr
had his article published in a number of publications in the Feb 2005
time frame. Or at least the same article shows up in a number of places.

All pdf's I have do not specify any coordinate axe

Re: gEDA-user: Cutouts

2010-09-29 Thread Rick Collins


What link?

In general, rectangular openings are not well received by the PWB 
maker.  If they are large enough (somewhere in the range of 0.1 or 
0.2 inches wide or more) they can be routed, but that often costs a 
bit more.  A small rectangular pin is typically accommodated by 
notching the edge of the board, but if you want it in the middle, 
that would be a long notch.


Oh, wait, you mean electrical connection pins!  I was thinking of an 
alignment pin.  I had this exact problem and I just used round holes 
large enough to push the pins through.  In fact, I fudged the sizes a 
bit so I didn't have lots of different drills.  My power connector 
(may be similar to yours) used five rectangular electrical pins and 
one alignment pin.  The round holes seemed to work just fine.  CUI 
jack barrel 5.5x2.1 mm PJ-051AH


Is this what you are talking about?

Rick


At 06:44 PM 9/29/2010, you wrote:

Hi,
im designing something using a 3.5mm audio jack that is space confined, i
need to use a jack that mounts in the middle of the circuit board.
unfortunatly i cant figure out how to make the cutout in the footprint or
the rectangular(with circular ends) pins. the link is a picture of the
footprint.
thanks, 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: new footprint guidelines

2010-09-29 Thread Rick Collins

At 07:00 PM 9/29/2010, you wrote:

Rick Collins wrote:
The point I wanted to make is, that there's nothing wrong with our
memories but
that the 2009 version of IPC-7351 contradicts the 2005 version
(probably 2003 as I see now),
maybe in order to conform to EIAJ/ANSI 481C. So this conformance
should be veryfied.

Do you have a copy of the 2003 version of IPC-7351? I think there
was no 2003 version of the spec. If I understand the little bit I
can find on this it was only released in 2005.

Apparently not - only the URL below with the 2003 note in the footer.

I went through a very lengthy search for a rational basis for
picking a standard. Virtually no one seemed to actually know the
source of the standard they used or what anyone else was
using. It seems like the board fab and assembly business is full
of cowboys who just want to make the current project work rather
than to figure out a system that would help everyone. In the end
I found that the incorrect IPC-7351 that I found was an initial
short form version from 2003, limited to naming conventions and a
brief listing of pin 1 orientations, not a full spec. I had also
found some other materials that had wrong information attributed
to IPC-7351, but not official (dated in 2003). The officially
released standard came out after, in February 2005, with the pin
1 orientation of all ICs either in the top left or the
top. Without knowing the whys, I can see that IPC-7351 seems to
be what is more supported than anything else. IPC claims that
IPC-7351 matches EIAJ/ANSI 481C. I have not found an official
copy of IPC-7351 that shows any other orientation than what was
stated. If you have an official copy of the released IPC-7351
spec that says pin 1 of ICs is anywhere other than top or top
left, I would like to see it.
Regretably I do not have any official version (bought in paper
directly from the relevant standads body)
but only pdf-files from the internet, that show the different
names IPC-7351 and IPC-7351B and
the respective release dates of 2005 and 2009. Neither do I have
an EIAJ/ANSI 481C paper.

The latest reference I found now is:
http://landpatterns.ipc.org/IPC-7351BNamingConvention.pdf
The old version I may have been looking at is 2003, not 2005:

http://www.pcbstandards.com/forums/attachment.php?attachmentid=501d=1064619067

These are the naming conventions only and do not explain anything,
they just list some basics. The full spec from Feb 2005 is 92 pages.
This rev has no suffix letter. There has been a rev A in Feb 2007
and and a rev B in 2010. I don't believe any of the released
revisions change any footprints that have been published, but
rather add new footprints.

On the last page of the pcbstandards.com-URL there is a 16-item list titled
Component Zero Rotations Pin 1 Location:. It describles pin 1 of a e.g.
SOIC, SOP, TSOP, etc. as at bottom left.
This is no longer the case in the 2009 and 2010 versions.

This is just a 3 page list of the land pattern naming
conventions. This is not really the standard at all. The standard
document is 92 pages long (the 2005 version) and has five pages of
very detailed drawings of each part type showing pin 1
orientations. I can't find a copy of the newer revisions that I
don't have to pay $100 for. The point is that when this was
published in 2003, it was not a standard yet as far as I can
tell. The original revision of the full standard came out in Feb
2005 and has no suffix. The 2007 and 2009 standards (A and B
respectively) should have the same detailed drawings of parts and
land patterns showing pin 1 orientations. I can send you this doc if
you would like.

about EIAJ/ANSI I found only:
http://www.smtnet.com/library/files/upload/The-Universal-PCB-Design-Grid-System.pdf

http://www.thefreelibrary.com/The+future+of+CAD+libraries%3A+will+IPC-7351+be+adopted+globally%3F+Take...-a0129548051

I don't find any info on EIAJ/ANSI 481C in the first
reference. The second is the same article I found the referrence
in. Tom Hausherr had his article published in a number of
publications in the Feb 2005 time frame. Or at least the same
article shows up in a number of places.

Sorry, there isn't really any info, the standard is just mentioned I think.
There are some sites claiming to provide EIA-481-D-2008 for download.
They all require registration and since they look a bit like warez
distributors I didn't.

All pdf's I have do not specify any coordinate axe direction, so
one is free to choose
and it's not relevant for rotation as long as the CAD-system has a
fixed top side for the design.
Real boards of course tumble around in space with 6 degrees of
freedom as do parts
so here the crazy busines with coordinate systems goes on, since
the fab may have

no intrinsic way to tell where top was in the design.

(I'm used to question coordiante systems, since mechanical (3d)
cad will orient

your model on the screen any way you

Re: gEDA-user: new footprint guidelines

2010-09-28 Thread Rick Collins


At 04:53 PM 9/28/2010, you wrote:
For all those, that follow the discussion from here or vaguely 
remember some other rotations:


Rick Collins wrote:
I had to go through all this some time ago and recently I wanted to 
iron out all the difficulties so that the assembly house could use 
my XYRS file (location and rotation data) directly without alteration.

That ended up being a fool's errand, but I did learn a few things.
IPC has a standard for this which everyone seems to use.  For two 
pin symmetrical parts, pin one is to the left.  For IC type parts, 
pin one is in the upper left quadrant for parts with pin one in a 
corner or for parts where pin one is in the center of a side pin 
one is on the upper most side.  This is the zero degree rotation 
point for the part.  All rotations are counter-clockwise from this position.
on 2010-08-15 Rick wrote in thread 'Specification of Rotations for 
Auto Assembly':
I just found something that changes what I thought I knew.  I have 
a PDF of an IPC magazine from 2005 where they are touting a leap 
forward in land pattern generation.  An illustration showing pin 1 
in the upper left for SOT components is what I used as my 
reference.  That and the post in the FreePCB forum of a normally 
very reliable source.  But I found a copy of IPC-7351 and it clearly 
says that for SOT and most other IC parts, the original rotation is 
with pin 1 in the LOWER left.  That is what FreePCB does in the 
library editor by default. 


This isn't Ricks fault: reading the 2005 IPC-7351 I can confirm 
this, while the 2009 IPC-7351B says,

that pin 1 is in the upper left corner ;-)
Shall I comment on this ? I'll just use upper left...


I'm not sure what you are saying.  Did you have a point you wanted to make?

I went through a very lengthy search for a rational basis for picking 
a standard.  Virtually no one seemed to actually know the source of 
the standard they used or what anyone else was using.  It seems like 
the board fab and assembly business is full of cowboys who just want 
to make the current project work rather than to figure out a system 
that would help everyone.  In the end I found that the incorrect 
IPC-7351 that I found was an initial short form version from 2003, 
limited to naming conventions and a brief listing of pin 1 
orientations, not a full spec.  I had also found some other materials 
that had wrong information attributed to IPC-7351, but not official 
(dated in 2003).  The officially released standard came out after, in 
February 2005, with the pin 1 orientation of all ICs either in the 
top left or the top.  Without knowing the whys, I can see that 
IPC-7351 seems to be what is more supported than anything else.  IPC 
claims that IPC-7351 matches EIAJ/ANSI 481C.  I have not found an 
official copy of IPC-7351 that shows any other orientation than what 
was stated.  If you have an official copy of the released IPC-7351 
spec that says pin 1 of ICs is anywhere other than top or top left, I 
would like to see it.


Rick 




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

Re: gEDA-user: gnetlist -g drc2 and pintype

Tying a digital input directly to a power rail is a bit like doing a 
crossword puzzle in ink.  You need a lot of confidence to do that in 
a real design.  I typically use a resistor to pull them up or 
down.  That can always be hacked, power connections can be hard to 
access to modify them.


Rick

At 09:22 AM 9/27/2010, you wrote:



kai-martin knaak wrote:

Karl Hammar wrote:



 Running gnetlist -g drc2 on a schematic I get:

 input/output -- pwr



input and output are meant to refer to signals. The DRC assumes 
that signals should never be connected to power lines. With analog 
circuits there is no strict dividing line between signal and power. 
So DRC should be taken with a large grain of salt on these circuits.


From what I know, it's a bad idea to leave logic inputs floating, 
so on TTL/CMOS gates,

one will tie them to GND if not used. GND is a power line, isn't it?


___
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 footprint guidelines

I am curious about the reasoning for picking values of design 
rules.  I have not found the assembly houses to be very useful for 
this sort of info.  They seem to be willing to work with whatever 
they are sent and will only give feedback when something causes real 
trouble for them.



At 12:51 PM 9/24/2010, you wrote:


Yes, the old library parts are pre-hires and the pads can be way off
and should be fixed.  Thanks!

If we're hand-coding footprints, we could use 0.5mm instead of
1965 and preserve the *meaning* of the units.  We lose some
compatibility with older PCBs, but if the purpose is to update the
current distribution that shouldn't be a problem.

We should probably go with build-time generated footprint files,
rather than continue to use the m4 runtime generation.  That allows us
to use more than just m4, too.  Makefile rules for standard %.whatever
to %.fp conversions...

My general rules:

Mask should be 3 mil away from copper, and slivers should be at least
6 mil wide.  That means, if there's less than 12 mil between pads you
go with a gang-opening.


Where did you get these numbers?  Did a manufacturer give this as 
their capability limit?




Silk should not overlap the *mask opening* and should be 3 mil away at
least.  5 mil min silk lines.


Same here, who's rules are these?



Origin and license should be stored in element attributes, not file
comments, so they're copied into schematics.


IPC has developed a set of rules for designing footprints to match 
parts of all sorts and has even provided a library of data for 
this.  They provide three standard sets, Most, Nominal, Least which 
differ in the amount of land protrusion.  Armin's footprint is likely 
a Most catagory footprint from his description.  IPC-7351 seems to 
be very widely adopted and would be a great starting point for any 
footprint library.




It would probably be a good idea to have more than one design for each
footprint; one for reflow'd boards and one with longer pads for hand
soldering.

All QFN parts should have some visual aids to centering :-) On my last
board, I added four diagonal lines on the silk layer to align each
corner (like a big X), that worked out well.

Refdes should be properly placed and sized but I'm not sure what's
best.  For example, on every single RESC1608N part I place I have to
make the refdes smaller and move it off the pads.  Getting size right
is far more important than position; it's easy (and often needed
anyway) to move things around in only-text mode.


I don't bother with putting the refdes in any particular location for 
a library part.  The times a default location would work out is so 
seldom, that it just isn't worth the effort. I put the refdes in the 
middle of the library part and move it to suit the design.



Rick 




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

Re: gEDA-user: new footprint guidelines

I had to go through all this some time ago and recently I wanted to 
iron out all the difficulties so that the assembly house could use my 
XYRS file (location and rotation data) directly without 
alteration.  That ended up being a fool's errand, but I did learn a 
few things.  IPC has a standard for this which everyone seems to 
use.  For two pin symmetrical parts, pin one is to the left.  For IC 
type parts, pin one is in the upper left quadrant for parts with pin 
one in a corner or for parts where pin one is in the center of a side 
pin one is on the upper most side.  This is the zero degree rotation 
point for the part.  All rotations are counter-clockwise from this position.


Then comes the really tricky part.  For parts on the bottom side, the 
general rule (not in the IPC standard) is to either view the parts 
from the bottom with the board mirrored about the Y axis with the 
same pin one orientation (upper left in the mirrored image) and 
rotation counter-clockwise, or to view the bottom from the top with 
rotation clockwise ( with the footprint mirrored about the Y axis so 
pin one is on the right, in the upper right corner or top) giving the 
same results.


All X,Y positions are with respect to the centroid of the part.

I would expect the software can do all of this, but you need to 
layout your footprint with this in mind.  In Free PCB, they use a 
centroid vector to specify the location of the centroid of the part 
and the angle of the zero degree rotational position.  Not sure how 
this is done in gEDA.


As you say, you can deviate from this and the board house will likely 
still give you correct boards as long as you are consistent.  But 
even though the parts on my board were clearly labeled with pin 1, a 
board house assembled all of my prototypes with the chips reversed 
once.  Now I am much more cautious about the XYRS file, almost paranoid...  8-S


Rick


At 10:42 AM 9/27/2010, you wrote:

Just 10 minutes ago I had my 1st talk with my first assembly house.
Guess what! I'm asked to provide rotation data.
In the other mail I'm currently editing, I'm trying to provide definitions on
where X- and Y-axis is on a part, including where X+ is on mechanically
doubly symmetrical polar parts etc.

As of now, I'll probably have to check/provide every angle by hand,
but for future footprints, the definitions have to be absolutely clear.
If there are contradictory standards, we will have to opt for one.

As Rick said, they are able to adapt to any coordinate system, but at
least the designer must know, what he means himself ;-)

Regards, Armin


Rick Collins wrote:

I am curious about the reasoning for picking values of design rules.
I have not found the assembly houses to be very useful for this 
sort of info.  They seem to be willing to work with whatever they 
are sent and will only give feedback when something causes real 
trouble for them.



___
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 footprint guidelines

I've done that.  I go to the assembly house to test my boards so they 
can be repaired before I accept delivery and talk with them all the 
time.  The only complaint they have is a connector that hangs over 
the edge of the board which I can't do anything about unfortunately, 
it is due to an old mistake by my customer which would require 
obsoleting lots of equipment in the field.  Like I said, if it 
doesn't cause them any real problems, they don't worry about it.


Rick


At 12:52 PM 9/27/2010, you wrote:

On Mon, Sep 27, 2010 at 9:56 AM, Rick Collins gnuarm.2...@arius.com wrote:
 They [Assembly houses]
 seem to be willing to work with whatever they are sent and will only give
 feedback when something causes real trouble for them.

You have to ask, unfortunately.  When you send a new project in to a
house, ask to talk to the people on the line, about what would make
the design better.  Don't let the sales department give the no
problem  answer based on the customer is always right idea.  Talk
to the people doing the work.

If you are making only a few boards the unspoken problems don't really
mater that much, but if you are making any kind of quantity of boards
it could mater a lot in the bottom line pricing you'd get from the
assembly house.


___
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: Functional blocks and PCB format changes

2010-09-17 Thread Rick Collins

I've actually given this some thought.  On one 
hand it seems like a footprint file language 
might seem like a good idea.  But there is a lot 
to consider.  What is the real advantage over the 
scripts you currently use to generate a fixed 
format footprint file?  What is the advantage 
over a footprint generator?  One of the clear 
disadvantages of a footprint language is the 
difficulty in verifying that you have correctly 
drawn the footprint.  You would need a tool for 
that which would look a lot like a footprint 
generator.  It can also be problematic dealing 
with bugs when the language gets used in the corner cases or unusual ways.


FreePCB has a pretty versatile footprint 
generator that deals with all the standard sorts 
of features in the standard footprints.  It is 
capable of understanding the files it generates 
so that it can be used to edit these footprints 
as well.  If you have an odd part that has some 
regular features and also odd features, it can 
accommodate that too.  I have never needed to 
hand edit a footprint file when using this 
tool.  Best of all, it is GUI and interactive so 
I can see exactly what I am doing.


A footprint language may be quick for some 
things, but I think a GUI footprint editor with a 
standard, non-programmable file format is a much better general tool.


Rick


At 04:55 AM 9/17/2010, you wrote:

Phil Frost:
...
 XML and YAML are equally capable of being made unreadable. Either can be
 made more readable by defining a reasonable schema and selecting a
 clueful output library.

 Neither sed nor awk can process XML or YAML the right way in all cases
 without reimplementing a libyaml or libxml in sed or awk.

Ack, one can make an file format unreadable, and one can make it
reasonably readable. But that is only one side of the problem.

I am also conserned with how easy it is to write it (e.g. footprint
files).

Currently I'm trying to learn to make footprint files (since I need them).
And it seems that I almost always end up making a script making the
needed files. For me, it means that the file format is not expressive
enough.

***

I would like the file format to be programmable, at least at the
footprint level.

1, A first step could be to allow variables in the files, e.g. to be able
   to write:

  pad_dims = 1.1mm 0.5mm 1.300mm
  Pad [ -1.700mm -0.300mm   -1.700mm 0.300mm  $pad_dims  1 1 square]
  Pad [  1.700mm -0.300mm1.700mm 0.300mm  $pad_dims  1 1 square]

or

  x = 1.7mm
  y = 0.3mm
  pad_dims = 1.1mm 0.5mm 1.300mm
  Pad [ -$x -$y   -$x $y  $pad_dims  1 1 square]
  Pad [  $x -$y$x $y  $pad_dims  1 1 square]

or

  pw = 1.1mm # pad width
  ph = 1.7mm # pad height
  pd = 2.3mm # pad distance
  x = $pd/2 + $pw/2
  y = $ph/2
...

2, Next step could be to allow subroutines in the native format, eg.:

  two_pads(pad_width, pad_heigth, pad_separation, component_width) {
...
  }

  1206_reflow_soldered = two_pads( 0.9mm, 1.7mm, 2.0mm, 1.6mm )
  1206_wave_soldered   = two_pads( 1.1mm, 1.7mm, 2.3mm, 1.6mm )

  clearance = 0.5mm
  soler_mask_clearance = 0.3mm
  1206_my_version  = ...

or (if you don't like positional parameters):

  1206_wave = two_pads( pw=1.1mm, ph=1.7mm, pd=2.3mm, cw=1.6mm )

instead of file 1206_wave.fp:
 # Vishay D../CRCW e3
 # 
http://www1.elfa.se/data1/wwwroot/assets/datasheets/flD-CRCW-e3_data_en.pdf


 Element [ 0 0 -0.7mm -0.8mm 0 100 ]
 (
   Pad [ -1.700mm -0.300mm   -1.700mm 
0.300mm   1.1mm 0.5mm 1.300mm 1 1 square]
   Pad [  1.700mm -0.300mm1.700mm 
0.300mm   1.1mm 0.5mm 1.300mm 2 2 square]


   ElementLine [ -2.510mm  1.110mm2.510mm  1.110mm   0.32mm ]
   ElementLine [  2.510mm  1.110mm2.510mm -1.110mm   0.32mm ]
   ElementLine [  2.510mm -1.110mm   -2.510mm -1.110mm   0.32mm ]
   ElementLine [ -2.510mm -1.110mm   -2.510mm  1.110mm   0.32mm ]
 )

file 1206_reflow.fp:
 etc

3, another possibility would be to use postscript or some other
   language as the file format.

 /mm 72 25.4 div def
 mm mm scale
 0.1 setlinewidth

 /pw 1.1 def
 /ph 1.7 def
 /pd 2.3 def
 /x pd 2 div pw 2 div add def
 /y ph 2 div def
...

***

Would patches for something like this be accepted?

Regards,
/Karl Hammar

-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57




___
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: Functional blocks and PCB format changes


At 11:40 AM 9/13/2010, you wrote:

On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote:
 On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
  XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
  I think that using a Lisp (or Lispy-looking) format would be extensible,
  easy to parse, and make the most people happy.

 Allow me to toss out JSON.  It is about as light weight as using S-EXP,
 but politically it isn't tied down by references to Lisp.  Plus, since
 it has become fairly popular, there are good readers/writers for most
 languages.

 The format is defined at: http://www.json.org/

 Basically you are allowed strings, numbers, arrays, and object, which
 would be called a map, an associative array, a dictionary, or something
 else along those lines anywhere else.


The problem I have with JSON (and to some extent, Lisp) is that it is
not self-documenting. You can't open a JSON document and immediately
see what everything is and what it does; it just looks like gibberish
and brackets.

Also, it doesn't require a consistent newline scheme.



Yes, if you have the file format provide adequate context information 
for humans to read, then you are adding weight and the file becomes 
heavy.  I find that I can actually lift many gigabytes very easily, 
but some others seem to have more concern about this.  I suppose all 
the kayaking I do gives me extra upper body strength. :)


There ain't no free lunch.  Either the file format is easily read by 
humans or it is minimal in size.  You can't have both.  I have never 
heard my computer complain about files being too heavy for it.  I 
will say that I have to use the shoulder strap when I lug it into 
Panera Bread, but I always thought that was because I put so many 
papers in the bag with it.  Maybe it's the files.


Rick



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

Re: gEDA-user: Functional blocks and PCB format changes


At 01:43 PM 9/13/2010, you wrote:

On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:

 On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:

  On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
   XML is far too heavy, agreed, and it's signal-to-noise ratio is
   abysmal.

 Why? I'd much rather handwrite XML than YAML.
 And I'd certainly prefer it to the existing file formats, which I can
 barely edit without looking up the meaning of each position.

 I'm not sure that I see a good reason for the hatred of XML.  I've
 never found the size of Inkscape documents to be absurd, for example,
 and the fact that python and other languages can manipulate it so
 easily is definitely a plus.

Proposing XML without a DTD is like proposing French without any defined
nouns. People hate XML because most DTDs are abysmal. For a reason to
hate XML, I refer you to Apple's plist format.


So the problem is not XML, it's really the DTD?

Rick 




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

Re: gEDA-user: Functional blocks and PCB format changes


At 01:44 PM 9/13/2010, you wrote:

On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:

 Why? I'd much rather handwrite XML than YAML.

Really? It's not the filesize of XML documents that is the concern; it is the
/redundant/ filesize. Even for a single-character tag, you need to 
type a.../a,

which is 7 characters of non-data text.


But that is exactly what others have been saying, they are concerned 
about the file size they think they would get from XML... I want to 
run PCB on my iPad, etc.




To contrast, in YAML you would have

  a: ...

which is 2 characters, plus indentation, and a lot easier both to 
read and to type.



Practically, consider:
  layernamemy-layer/name/layer

Versus:

  layer:
name: my-layer

The latter is lighter, simpler, grep-able-er, and shows a clear distinction
between data and metadata.


Oh?  I don't see how any of the above follow.  For the most part, I 
don't expect to be writing much XML by hand.  But I do expect to need 
to read it sometimes and less often edit it.  That is, the part where 
the name or other property value is typed will need to be 
changed.  Finding that value quickly and easily is what I am 
interested in.  The computer does a great job of dealing with the 
size and format of the file.  I want to use my eyes to quickly find 
the data I'm interested in.




Machine-generated XML almost never uses whitespace, so it's next to impossible
to determine nesting levels or document validity, not to mention grep and awk
being nearly useless.


The only XML I have seen is indented just as I would indent code.  Is 
there something that would make it hard to output whitespace 
formatted XML?  I would think that would be up to the program.  You 
example above uses no indentation for XML, but uses indentation for 
the counter example.  Is whitespace easier to generate by machine for 
formats other than XML?


Rick 




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

Re: gEDA-user: Functional blocks and PCB format changes

Will that mean every time something new is added to the core, each 
set of import/export logic will break?  Or is that part of making 
changes to the core, to update all affected functions?


Rick


At 04:29 PM 9/13/2010, you wrote:


Perhaps we store the internal data in a structure that can be
exported/imported in *any* structured format, and let those who really
want format XYZ to add the import/export logic for it?


___
geda-user mailing list
geda-user@moria.seul.org
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: Functional blocks and PCB format changes


At 04:34 PM 9/13/2010, you wrote:


 But that is exactly what others have been saying, they are concerned
 about the file size they think they would get from XML... I want to
 run PCB on my iPad, etc.

File size just means a bigger file to generate/parse.  Doesn't affect RAM
use significantly, which is the major limit for small devices.

This year's iPad has 16 GB flash, minimum.  Suppose that someone ports PCB
to iOS while they still make a 16 GB model (oh-so-likely) and that it were
allowed in the iTunes app store while containing GPL code (wanna buy a
bridge?).

Further suppose that there's a 10X file-size penalty for using XML.  Let's
call the file size a PITA if it reached (say) 10% of that, 1.6 GB. (Can
you even buy a USB drive that small anymore?)


Yes, on the last board order I made the vendor sent me all my design 
files on a 256 MB Flash drive with a keychain attached.  So they are 
still available and obviously inexpensive.  However, the price of 
Flash and DRAM are dropping again, so we may see the smaller units go 
by the wayside soon and be stuck with 2 GB as the smallest Flash 
drive on the market.




So, the questions: Who here generates PCB files as large as 160 MB on a
regular basis?  And, if you answered me, is this type of design one that
you'd prefer to edit on a small screen?

Seriously.  Does anyone actually think that XML would make a
non-negligible difference one way or another about whether you could run
PCB on any  forthcoming iXYZDroidBerry?  This argument fails the common
sense test.


The only reason why I feel XML is a good idea is that there is 
already a standard XML schema that could be used as a starting 
point.  As Windell says, the arguments against XML seem to be based 
on some sort of bias rather than any real facts against it.  But it 
is pretty clear that there is little interest in making the program 
similar to anything else.  Maybe this is not a good idea at all.  It 
was just a thought.


I will say that when people use words like bloat, large, 
complicated, slow, ugly, etc., they are not discussing 
engineering.  They are using emotion to try to influence the 
process.  I just read another post on this topic that is using these 
sorts of words without any clear basis.  There is no point in 
discussing emotionally charged issues.


Rick 




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

Re: gEDA-user: file formats again (was: next PCB release - 1.99za vs 4.0)


At 04:46 PM 9/11/2010, you wrote:

On Sat, Sep 11, 2010 at 09:28:16PM +0200, kai-martin knaak wrote:
 Peter Clifton wrote:

  Yes, indeed.. magic silk (and other) layers should probably go
  and die.

 Please do. My local list of warts and rooms for improvement contains
 many complaints about things that can't be done with silk. Worst of
 all: You can't selectively print top-silk and bottom-silk like the
 regular layers.


Doing this will almost certainly require changes to the file format,
which I am loath to do unless we switch entirely to a new, more flexible
file format.

Are there any concrete plans in that direction?



Yeah, I think the consensus is to switch to a light weight XML format... ;^)

Rick



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

Re: gEDA-user: next PCB release - 1.99za vs 4.0


At 03:42 PM 9/10/2010, you wrote:


On Sep 10, 2010, at 1:01 PM, DJ Delorie wrote:

 I figure we need each layer to specify:

 * type (copper, silk, mask, anti-copper, keepout, etc)

There are no types, there are only properties.

The conductors may not be copper. I've even worked with a board that 
had two different conductive materials on the same physical layer.


Wouldn't that by definition then be two different physical layers, 
just like the solder mask and silk screen are two physical 
layers.  The fact that they connect without vias doesn't mean to me 
they are the same physical layer.  I've worked with boards that had 
buried resistors.  The resistors were a layer of conductive material 
that had a controlled resistivity in contact with a copper 
layer.  The resistors were considered a separate layer.



The support layers are also not always FR4. The board I noted above 
had different numbers of layers in different places, and the support 
layers weren't all the same material and thickness.


Sounds suspicious.  Are you sure you aren't talking about an assembly 
with boards and a case?  Bolts aren't normally considered vias.  ;^)


Rick 




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

Re: gEDA-user: next PCB release - 1.99za vs 4.0


At 03:45 PM 9/12/2010, you wrote:


Interesting thought - for buried vias, the top and bottom layers
correspond to inner physical layers, yet they need to be treated
differently as the annulus often needs to be bigger on layers where
the trace connects.  So an internal buried via element, before it's
placed, is not like other elements...


Bigger???  Why do you need an annulus on an inner layer that doesn't 
connect to a trace?


Rick 




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

Re: gEDA-user: next PCB release - 1.99za vs 4.0


At 04:06 PM 9/12/2010, you wrote:


 Bigger???  Why do you need an annulus on an inner layer that doesn't
 connect to a trace?

Depending on the fab technique, you may need an annulus just to fill
the gap between fr4 layers so that the electroplating is reliable.
Either that, or you need to keep *other* copper far enough away that
the prepreg can fill the gap.


I guess I'm not following.  Prepreg is the insulator used between 
copper laminate layers.  I know of no requirement to keep copper 
away to allow the prepreg to exist or do its job.


There are always some gaps or cracks in drilled hole walls even 
within insulation layers; the sides of the drill holes are never 
uniform in FR4 because the material is not uniform.  These cracks 
fill up with electroplating quickly because they are very narrow and 
don't cause a problem.  The only issue I am aware from these cracks 
being filled with plating is the need for keeping copper away from 
the holes to prevent shorts.  That is normally dealt with by a hole 
to copper design rule.


I have never been told by a board fab house that vias need to have an 
annulus on every layer to help with any problems.  To allow for 
maximum density of routing, separate design rules are needed for hole 
to trace from via pad to trace and also different between outside 
layers and inner layers.  I don't see that as a reason to use an 
annulus on each layer, to make the design rules work.


Rick 




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

Re: gEDA-user: QFN soldering

There are a number of different QFN package styles.  Some have pads 
only on the bottom, others have pads that wrap around the up the side 
a bit.  These tend to be easier to hand solder since you have a place 
to contact with the solder iron.  Sounds like yours don't have that 
plus they have a thermal pad on the bottom.  If the thermal pad isn't 
required for an electrical connection, and you don't need to use the 
full power capability of the package, you can likely live without 
soldering the thermal pad for a prototype.   But check the data sheet 
carefully.  Sometimes they require you to provide an electrical 
connection.  Is this a power supply devices?  Those are the ones that 
are most demanding I've found.


The assembly houses use a hot air tool.  It heats up the entire part 
and everything in the immediate area such as the board.  The solder 
flows, the part settles down onto the board and all is good.


Rick


At 09:46 PM 9/12/2010, you wrote:

does anyone have experience with this package?  I want to know if they
are hard to work with.  The exposed pad underneath is a problem for hand
soldering - but maybe could be left unsoldered for prototypes.  Maybe
just place some solder paste under there ?  If the pcb pads are long
enough, is it feasible to solder to the edge of the chip instead of
getting it underneath the device?

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: PCB format wishlist

2010-09-06 Thread Rick Collins


At 07:49 PM 9/6/2010, you wrote:

 I like the idea of using geometric shapes at the lowest level, but for
 most PCBs this is *way* too low-level to be efficient.  We need some
 way of arbitrarily grouping shapes, grouping groups, etc, and creating
 some sort of macro/library/callout for those groups, so that we don't
 end up (for example) redefining a pad stack for every one of hundreds
 of pins.


Several times now in this thread I keep thinking that the language Forth is
being described.  'Words' built up on previously defined 'words'...


I have often thought that I would prefer to write an HDL that works 
like Forth.  If used in this way, it becomes a bit Lisp like in that 
the data and program would need to become one and the same.  The 
Forth that describes the design would be executed to create the 
design in memory or to be output as a set of Gerber files.  But to do 
things like DRC, you would need to analyze either the image in memory 
or the design source itself as data.


If I find some time, a lot of time, I may work on that at some 
point.  But there are many other projects on the list ahead of that one.


Rick 




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

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Rick Collins


At 11:49 AM 9/4/2010, you wrote:

On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote:

 Don't hold back, tell us how you really feel!

 The spec is large because it addresses a wide range of design
 aspects, which is one of the great reasons for using it, one file
 for the entire design, schematic, layout, mechanical, etc, even
 board lay up.  So the compatibility issue is moot because any one
 app only needs to deal with the portion that applies to it.  Just
 don't muck with the other parts.

 The heavy issue is a red herring (are you planning on hosting this
 on a cell phone maybe?)  No PCB file format is going to be easy for
 humans to read.  Bandwidth?  Back to the MCU in the cell phone I
 guess.  Ugly, now there is a great technical argument.

 But I suppose it is better to re-invent the wheel.  There is no
 reason to try to foster any sort of compatibility in file formats
 between all the different CAD tools.  There are always conversion
 programs to be written, no?


This is not an emotional argument, but a technical one, and the
choice is not between XML and reinventing the wheel. (Sadly, my
Lisp suggestion has been shot down - by better arguments than
popularity, I might add. ;) There are other formats to consider,
and yes, inventing one might be an option.

How do you know PCB won't ever run on cell phones, or over a
slow network link, or on an embedded device or network PC or
overtaxed virtual machine? How do you know we won't one day
need to work with 1000-layer boards when suddenly it /does/
matter how heavy the file format is?


So are you suggesting that we should, at this time, plan for running 
PCB on a cell phone?  Do you want to design PCB to work on overtaxed 
virtual machines, if so, I expect there will be a lot more important 
things to optimize than the file format which only impacts the 
performance when reading or saving the file.  If we need to work with 
1000 layer boards, I expect we would have computers which would be 
not at all burdened by XML file formats.


I'm trying to be realistic about the requirements.  I think that the 
2x or 3x factor of file size of using something like XML would be 
lost in the noise.  The advantages of working with an industry 
standard file format could be very large.  Of course as you or 
someone pointed out, IPC-2511B is not a well established format.  But 
to my knowledge it is the only one that spans most if not all aspects 
of circuit board manufacturing.  It seems like a great idea to work 
with something this useful and I am pretty sure that concerns with 
using it can be ironed out.




Unless you want feature-parity with other CAD programs, it
is impossible to have file-format-parity. So no matter what,
conversion programs will have to be written. Creating similar
file formats won't help anything, other than to limit our own
format, and potentially cause problems if PCB and another CAD
program are able to open (and corrupt) each other's files.


I don't agree that a common file format has to be restrictive.  If 
the file format is flexible enough, the program won't be 
limited.  Everything doesn't have to be included from the start.  I 
don't know if IPC-2511B is flexible enough for PCB and future ideas 
for PCB, but using XML I expect it can be expanded easily.  I don't 
think anyone here has really looked hard at it.  It may well be 
extensible.  I don't know.  But I would like to at least consider it 
and not toss it away without giving it a chance.


Rick 




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

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Rick Collins

I am currently having a conversation in the FreePCB forum about 
DRC.  I think copper only checking is not adequate.  There are design 
rules regarding solder mask which can not be checked properly just by 
checking copper to copper rules.


Is there any checking done on the solder mask layer?

If you want to read my post regarding this go to http://freepcb.com/ 
and visit the forum, Bug Reports, Design Rule Checking.  The last 
post has a PDF attached.


Rick


At 06:41 PM 9/4/2010, you wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 04.09.2010 01:44, schrieb Andrew Poelstra:



 Hey all,


 I am working on the structuring PCB files in terms of functional blocks,
 and generalizing/extending the DRC rule format. (Things have slowed down
 as summer is ending but I am still working on this.)

 Mostly I am doing GUI work, since that is more-or-less stateless; I can
 spend 20 minutes reading docs or GTK code and not worry about making it
 work with PCB.


 But for the underlying logic:

 Naturally, I want to avoid any breaking changes to the PCB format, both
 to increase the chances of my code being accepted, as well as the obvious
 compatibility reasons.

 So I have a few thoughts:

 1. Initially my plan was to tag every object in the PCB with a functional
block. This would make attaching multiple tags easy, though it might
bloat the file, and would be slow to initially parse and search.


 2. Another idea would be to create functional blocks as recursive PCBs.
This has been mentioned a few times on the list, and creates all sorts
of exciting possibilities - from importing recursive schematics to
reusing layout parts to clearer source control of PCBs.

However, this also brings the ability to edit PCB components 
individually,

which means that some parts could have different layers than others, for
example. And then you have to deal with layer mappings and 
stuff and it's

a huge complicated mess, both for the user and in the code.


 What do you guys think I should do? What would require the fewest changes
 to the PCB format, if any?

 Generalized DRC rules at least could be tacked on anywhere and would be
 quietly ignored by old versions of pcb, right?


 Andrew



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


Andrew,

here are my thoughts about DRC:

There are (at least) 2 contributors to what should be checked by DRC:

1. The obvious one: The capabilities of the manufaturer, e.g. min trace
width = 4 mil, min distance = 4 mil, min drill .
2. The usage pattern: Traces where you expect high current (Vdd, GND,
...) can't use the minimum trace width, while traces that carry high
voltages (and need to meet UL, VDE specs) can't have the minimum distance.

A conclusion of the above is that the DRC rules are on a net base
(potentially on a layer base, if you forece nets with a similiar DRC
requirement to the same layer (sharing the copper with otherlayers).
I see 4 roout styles in the defualt PCB, they could be used to work
around a net specific definition.
- From my point of view, there should be a way of defining net attributes
from geda (see thread wishful UI).

If you want to exetend the DRC capabilites things like handling of
differenatial pairs, comparing netlenghs of busses comes to my mind.

Going slightly off-topic, one goal would be to extract all physical
parameters of a board (RLC for each net segment) and feed that back into
a simulation (spice, gnucap, ...).

- --

Mit freundlichen Gruessen

Dietmar Schmunkamp


PS: I won't have internet access for ht next 2 days, I'll comment
responses on Tuesday.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ
TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk
=Y576
-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: Color silk layers in pcb

2010-09-03 Thread Rick Collins

I can't answer your question, but I have one of my own.  I use 
FreePCB and have requested, along with others, that we be able to 
designate layers as documentation such as assembly info, mechanical 
details, etc.  Is that what you are looking for or do you want these 
layers to be usable to produce the silk screen Gerber files?  I 
suppose once the layers are created, it would not be any extra effort 
to allow them to be used in the Gerber file.  Does PCB have the 
ability to combine multiple layers into a single Gerber file?


Rick


At 12:40 PM 9/3/2010, you wrote:

On Fri, Sep 3, 2010 at 1:51 PM, Stefan Salewski m...@ssalewski.de wrote:
 On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote:
  Dear fellow GEDA-users,
 Can I get pcb to either treat a layer other than the default silk as
 non-metal
 (so it would not short pads and mess up nets),
 Please note, your SUBJECT may be misleading...

 No, currently we have only one silk layer. You may miss-use other
 copper layers for that task -- it may work when that layer is not in
 your real copper layer groups, but unfortunately it still connects to
 vias and can generate shorts. I did that for visual marks, distinct from
 other silk marks, and I copy that layer to silk before gerber
 production. (Some of us hope that sometimes we will have general propose
 layers, so that we can select type and other parameters separate...)

Thanks for your answer Stefan.
I have my visual marks just over vias, and it shorts them together,
so I will look for some other solution.

Is anybody willing to elaborate on how difficult would it be
to modify the pcb source code to color-differentiate three or four
silk layers and be able to selectively hide/show them?

Kind regards,
--
Pawel Kusmierski


___
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: Color silk layers in pcb

2010-09-03 Thread Rick Collins

No, FreePCB is a separate project with no links in any way.  I have 
used it for a couple of projects and like it pretty well, but it is 
hard to get changes made.  The developer was on a hiatus for some 
time, but is back now.  He has a long list of bug fixes and 
suggestions people would like to see implemented.  He also has some 
philosophical difference with me.  I would consider creating my own 
branch of the project, but I don't own the tools to build it with and 
no one has done that yet, so I don't know how well it would be 
received.  I don't want to muddy the waters with different versions, 
even if they are just small UI changes, unless we can find a way to 
make it part of the main branch with perhaps build options or something.


In the meantime I am working on the wiki as my small 
contribution.  Too bad it is down... :^(  I may also help with some 
peripheral tools such as a BOM/xyrs file manager.  The one someone 
else contributed does not fully utilize the info potentially 
available from the schematic.


I know pretty much nothing about PCB so I can't even give you a basic 
comparison of the two.  I am here to try to learn what this is about 
and where it is going.  Maybe I'll want to get on board at some point.


Rick


At 05:40 PM 9/3/2010, you wrote:

On Fri, Sep 3, 2010 at 6:49 PM, Rick Collins gnuarm.2...@arius.com wrote:
 I can't answer your question, but I have one of my own.  I use FreePCB and
 have requested, along with others, that we be able to designate layers as
 documentation such as assembly info, mechanical details, etc.  Is that
 what you are looking for or do you want these layers to be usable 
to produce

 the silk screen Gerber files?  I suppose once the layers are created, it
 would not be any extra effort to allow them to be used in the Gerber file.
  Does PCB have the ability to combine multiple layers into a single Gerber
 file?

That would do the trick.
I just want to have more than two silk layers and be able to tell them
apart by color.
That would make it just so much easier to design a pcb that would fit
into a case,
and know where to cut holes in it at the same time.

By the way, is FreePCB related to gEDA pcb in any way?

Kind regards,
--
Pawel Kusmierski


___
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: Functional blocks and PCB format changes

2010-09-03 Thread Rick Collins


XML?  What's wrong with XML?  Heavy?  How heavy are a few electrons anyway?

There is already a preliminary XML based CAD data spec proposed by 
IPC, you know, the guys who write specs for the PCB assembly industry...


I don't know if it is the best thing ever invented and I expect the 
spec is not complete enough for everyone to make their data files 
100% compatible without a lot of communication, but wouldn't it be a 
great idea to at least start on a path which could result in a common 
data base for CAD packages?  What a concept!  The spec I have seen 
that looks like it would apply is IPC-2511B.  These things don't seem 
to be free, but I found this one somewhere, maybe on the IPC site.


Rick


At 11:00 PM 9/3/2010, you wrote:


Re: functional blocks

If we contemplate changing the PCB file format, it would be nice if we
went with something that was intrinsically extensible.  Knowing that
the 5th element in a list with '[' means clearance is a bad format,
but seeing clearance=5mil in a list of attributes is much better.
We use something suitable as our menu resource, but folks have argued
for XML too.  I don't want to bring in something as heavy and complex
as XML, but maybe a small parser like our resource parser that just
happened to use XML format would buy us some usefulness at low cost.

For performance reasons, it might be useful to have both an ASCII and
a compiled binary format for these, with a converter.  I've done stuff
like this before; parsing a huge ascii file is a CPU hog compared to
something designed to be digested by a program.

Note we already have the ability to store attributes at the layout,
layer, and element level.  Perhaps that would be one place to hold new
DRC rules?  If we tagged the rulesets, we could then assign those tags
to objects on the board, although storing such tags means a file
format change.  Maybe the new format can specify mandatory stuff as
the first few non-tagged values (like line start/end coordinates) and
have everything else be tagged after that (like clearance=1mm) so it's
more free-form?  We'd need some meta-rules for specifying defaults.

Re: DRC

Our DRC engine could use a complete rewrite.  It doesn't get arcs
right, for example.  It would be nice if it told us the *actual*
design rules used (what's the closest cross-net spacing?  Smallest
drill?  Etc) too.

Re: recursive PCBs

I think the first step in this type of change is to tag layers by
type.  I've spec'd this out before, I think, and it's the Upgrade of
layer and design objects in our big statement of work (SOW):

http://www.geda.seul.org/wiki/geda:pcb_funding_sow

Those items are approximately in do-in-this-order order, but the GUI
stuff can go anywhere.  Anyway, layer design tags each layer with a
type, such as top side silk or inner keepout (a combination of a
where and a what, and optional invert).

This is the basis for elements-as-pcbs and nested pcbs.  The tricky
part is not the data structures, but mapping the various layers in
each submodule.  For example, if you imported a two-layer board module
into a four-layer board, what happens?  Or an element description with
keepaway on all inner layers, how does that map to a six-layer
board?  Etc.

Some of that work can be made easier to code if we switch to C++
officially so we can use a real OO language instead of the OO hack we
currently have.  There's a patch in the tracker to make the code
C++-compatible, someone (i.e. me) needs to review it so we can get it
committed and start seeing who'll have problems if we switch to C++.

Then you could have each object know how to draw itself (or part of
itself, usually by layers) just by foo-draw().  I don't think this is
*needed* though.  We just need a new object type that is itself a PCB
(or at least the PCB-Data structure, like a Buffer), a way to nest
all the draw/find/select etc stuff, and a way to tell the GUI which
object(s) you're editing.  That automatically gives you a footprint
editor too :-)

If you'd rather work on the GUI, though, that's also a needed project.
It would be nice if the GTK gui supported all the modern Gnome stuff,
like dockable toolbars and menus-with-icons.  The SOW has an entry for
that also.


___
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: Gerbv Zoom for Measurements

2010-09-01 Thread Rick Collins


At 01:59 AM 9/1/2010, you wrote:

Rick Collins wrote:

 Do all versions of this software have this limitation?  Is this
 something that is going to be addressed?

At the maximum zoom, the canvas is about 95 mil wide in a maximised window
on my 1280x1024 linux screen. Is this more zoom than with your windows
version?


I measure 237 x 149 mil with maximum zoom and the side panel set to 
minimum size on a 1440 x 900 display.  So yes, you are seeing more 
zoom by over 2x I would say.


There are some other issues with the layout window.  I think I 
mentioned before that it doesn't correctly image the rounded 
rectangle pads that FreePCB generates using macros.


Also, when I switch to another window and then back, the part of 
image that is redrawn is offset from what should be drawn 
there.  This varies depending on how I make the focus switch.  Using 
the Alt-Tab key results in a corruption that doesn't go away by 
itself.  If I move the mouse over the Gerbv icon in the task bar the 
layout pane is redrawn correctly.  Clicking on the Gerbv task in the 
task bar I get a visible, but short delay before the window is 
redrawn correctly.


Rick 




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

Re: gEDA-user: kicad/gerbview vs. pcb/gerbv: interpretation of Circular Interpolation

2010-08-31 Thread Rick Collins

That seems to be a rather esoteric bug.  Is there 
any point where it causes a problem?  Even if PCB 
is within spec, if it fails to work with a large 
majority of the software out there, maybe it 
should be changed to conform with common 
usage?  But if there is no complaint that this 
causes a problem, what is the point?


Rick


At 12:08 PM 8/31/2010, you wrote:

in ubuntu bug 611907 (http://bugs.launchpad.net/kicad/+bug/611907) a
kicad guy thinks that pcb's gerber output does not conform to RS274X,
because it always(?) uses Multiquadrant (360°) Circular Interpolation
(G75) even for arcs which can be drawn with a Single Quadrant
Circular Interpolation (G74) command. After reading the ucamco specs i
think pcb is ok, but i want to let you know his opinion...

--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner


___
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: kicad/gerbview vs. pcb/gerbv: interpretation of Circular Interpolation

2010-08-31 Thread Rick Collins


At 01:04 PM 8/31/2010, you wrote:


I'll put together a test gerber, but consider this thought logic...

What's the difference between a 135 degree arc and a 225 degree arc?

Now, what's the difference between a 45 degree arc and a 315 degree arc?


That all depends on what the software says the difference is.  I can 
see those being very different things.  One is an arc that is less 
than half a circle and the other an arc that is more than half a 
circle.  But if the software interprets all of these as being less 
than half a circle, then they are the same.


How long is a piece of string?

Rick 




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

gEDA-user: Gerbv Zoom for Measurements

2010-08-30 Thread Rick Collins

I am using Gerbv 2.4.0 under Vista and the zoom seems limited.  It 
will only zoom in to a certain point which is not really detailed 
enough to  make measurements.  I am trying to verify that the solder 
mask is wide enough that it will be preserved when added to the 
board.  It can be hard to tell the difference between 3 mil and 4 mil 
with any degree of accuracy.


Do all versions of this software have this limitation?  Is this 
something that is going to be addressed?


Rick



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

gEDA-user: Gerbv Auto Reload Gerber Files???

2010-08-30 Thread Rick Collins


I am using Gerbv 2.4.0 under Vista.

I have an existing .gvp file for my design.  If I have the file open 
in Gerbv and update the Gerber files, I have to use the reload 
control to update the layers in the .gvp file.  I can reload them one 
at a time or all at once.  But if I update the Gerber files when I 
don't have the .gvp file open in Gerbv, it seems to reload all the 
Gerber files automatically when I open the .gvp file.  Is this 
intentional or is this a bug?  I don't want Gerbv to reload any 
layers until I ask it to.  Often I want to reload them one at a time 
so that I can visualize the changes.


Rick



___
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: Honey, I shrunk the schematic


At 03:07 PM 8/23/2010, you wrote:
Rick Collins wrote:  Why do you need to use any 
standard sizes on a computer?  Using  Orcad, I 
start with a size that I have chosen as my 
standard and if  I end up needing a bit more 
room for a given page, I just bump up the  
dimensions a nudge while keeping the same aspect 
ratio. In gschem you are not even bound to 
nudges. My default title block is deliberately 
just that -- a title block with no fixed frame. 
http://www.gedasymbols.org/user/kai_martin_knaak/symbols/titleblock/title-block.sym 
If I want a frame for printing, I just draw a 
rectangle that fits the schematic. BTW, this 
title block features predefined attributes for 
the whole schematic. These can be changed from 
within the GUI like any other attribute.  but I 
don't think I've printed a schematic on paper in 
two years. I find printed copies indispensable 
when working with other people. Nothing beats 
the flexibility of good old pencil sketches.   
Can't TinyCAD work with arbitrary page sizes? 
TinyCAD? ---)kaimartin(--- PS: Does this mail 
render fine with your mail client? -- Kai-Martin 
Knaak  tel: 
+49-511-762-2895 UniversitÃ¤t Hannover, Inst. 
fÃ¼r Quantenoptik  fax: 
+49-511-762-2211Welfengarten 1, 30167 
Hannover 
http://www.iqo.uni-hannover.de GPG 
key: 
http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get 
___ 
geda-user mailing list geda-user@moria.seul.org 
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



TinyCAD...   I guess I forgot which list I was 
on.  I use FreePCB and Orcad and am planning to 
switch to a different schematic package 
sometime... maybe.  So I am looking at TinyCAD as 
well as some others.  I'm actually here because I 
am using Gerbv.  It has some display issues, but 
in some draw modes they aren't apparent so I can 
switch to see what are design issues and what are 
viewer issues.  Gerbv is such an easier to use 
tool than GCpreview there is no comparison.  But 
I have to use both to be sure of what I am seeing sometimes.


BTW, to whoever took the time to port Gerbv to 
Windows, thanks a lot!  We non-developer types appreciate it.


No, as you can see above, your reply is all run 
together.  I also have this problem with one 
poster in the ZPU mail list.  He says it is 
Eudora, but I only have the problem with two or 
three posters.  Go figure!  Do computers EVER just WORK???


Rick 




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

Re: gEDA-user: Honey, I shrunk the schematic


At 03:34 PM 8/23/2010, you wrote:

On 8/23/10 3:19 PM, Rick Collins wrote:
 Do computers EVER just WORK???

  Windows users tend to ask this a lot.

-Dave



:)  LOL!



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

Re: gEDA-user: Ricks email client (was: Honey, I shrunk the schematic)


At 09:14 PM 8/23/2010, you wrote:
Richard Barlow wrote:  I suspect this is due to 
Kai-Martin's emails being base64 encoded.  
Viewing the message source in evolution shows 
everyone's emails in plain  text except for 
his, which have the header 
Content-Transfer-Encoding:  base64. I just 
changed the transfer encoding setting in my 
client for posting from allow 8 bit to 7 bit 
(quoted printable). Is there any difference 
with this reply? If so, then something on Ricks 
side is to blame. Transfer encoding base64 has 
been around before the internet hit the streets. 
Ok, this should be enough blurb to see, if the 
setting did anything useful.  I don't know if 
you've already seen this message[1] but it seems 
you're  not the only one experiencing this 
problem.   Richard   [1]  
http://groups.google.com/group/comp.mail.eudora.ms- 
windows/browse_thread/thread/7a4e64bb565870c9 
Does Rick use eudora? ---)kaimartin(--- -- 
Kai-Martin Knaak Ãffentlicher PGP-SchlÃ¼ssel: 
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 
___ 
geda-user mailing list geda-user@moria.seul.org 
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


No change.  It is still all run together.

Rick 




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

Re: gEDA-user: Ricks email client


At 11:23 PM 8/23/2010, you wrote:
Rick Collins 
wrote: windows/browse_thread/thread/7a4e64bb565 
870c9 Does Rick use eudora? 
---)kaimartin(--- -- Kai-Martin Knaak 
ÃÂffentlicher 
PGP-SchlÃÂ¼ssel:^ 
 ^^ looks like your client messes all 
non ascii 
characters http://pgp.mit.edu:11371/pks/lookup? 
op=getamp;search=0x6C0B9F53 __ 
_ geda-user 
mailing list 
geda-user-3olirty5fqqavzljymc...@public.gmane.org 
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user  
  No change.  It is still all run together. 
The header of my posting still 
saidContent-Transfer-Encoding:   base64 
although I had it cnfigured to send quoted 
printable. Maybe my news reader needs to be 
restarted to activate the change. That's what I 
did now. If there still is no change, it must be 
gmane munging header and encoding. 
---)kaimartin(--- -- Kai-Martin Knaak 
Ãffentlicher PGP-SchlÃ¼ssel: 
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 
___ 
geda-user mailing list geda-user@moria.seul.org 
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



Same...

Rick 




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

Re: gEDA-user: Ricks email client (was: Honey, I shrunk the schematic)