Re: gEDA-user: Apply to join the geda-bugs team to triage bugs...
sorry, I see the prios differently: Peter Clifton wrote: Crasher / data loss - High (or perhaps even Critical if it is likely to be hit). depends on type of data loss: high if recent changes disappear, critical if the design vanishes (I know, the later is near impossible with move/write on saves) It also depends if the data loss is immediately evident - if not it's worse. Board output fault this is a catastrophic failure in a production environment or incorrect netlist likely to cause design breakage to my understanding an incorrect net will cause a design break with 100.0% likelihood - critical error UI wart / cosmetics - Low what is a wart ? freezes, hickups of state engine: medium button should be more to the left = cosmetic: low ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Christmas wishlist
Stephan Boettcher wrote: kai-martin knaak k...@familieknaak.de writes: Bob Paddock wrote: This is a DRC issue. The rules should allow any net to connect to no-net copper. No need to restructure the way pcb handles connectivity. If different nets connect to the same no-net copper there is a short between nets. Of course, connectivity needs to be recalculated (automatically) after a net has been connected to a no-net. As a consequence, the no-net copper will have been converted to what ever net it was connected to. Maybe it is important to recognise, that DRC and LVS are completely orthogonal in PCB, and I think that is a good property, that should be kept. DRC (DesignRule Check) does not consider the netlist. This is obviousely wrong, if you layout a copper trace between two net-compatible pads/pins in one go vs. routing to a wrong pin. It checks the connectivity of all copper, and verifies the rules for connected and not-connected copper. The problem is, that all copper patches not connected to a know net are considered to be on different nets - that is a completely arbitrar design choice and in no way supperior to treating them as on the one unknown net. LVS (Layout vs Schematic) checks that the copper connections between pins matches the netlist, without checking for DRC rules. How do you do that, without testing individual line/arc elements for overlap - which is a DRC matter ? Distinguishing between net and no-net copper will break this separation. This should not be done lightly. As far as I can judge, there is no such separation - there's just datastructures, that don't support net-attributes for lines etc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA Wikibook ?
kai-martin knaak wrote: Thank you for describing the available documents so compact. What is missing in this picture? IMHO, it is a manual on how to use the tools in concert. The best approximation so far is the tutorial by Bill Wilson. But as it is a beginners tutorial, it does not attempt to cover more advanced tips and tricks. I envision this as the topic a wikibook: A user manual to the complete suite of tools. I know that a wiki book may have some advantages in the collaboration of making. But why not a real book, that is written in LaTeX? Sending patches for TeX-files or chapters is a very simple process and a pdf-book can be downloaded as a whole and read offline, printed. That's what we try to do now for Varkon Programmers Handbook. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: get-package-attribute sometimes returns ? - ID: 3114991
Stefan Salewski wrote: On Thu, 2010-12-23 at 15:18 +0100, Armin Faltl wrote: I'll provide my symbols and footprints with this features: * symbols are smaller than the standard library Why? There are many request from various people for smaller symbols on this list. When used at normal scale the symbols of std. parts look clumsy to me too, so I didn't complain but made smaler ones. I think, that shrinking by using wrong page frames for printing is a good trick but a bad solution. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: get-package-attribute sometimes returns ? - ID: 3114991
Colin D Bennett wrote: I haven't nailed down what it is that bothers me, but I have recently made my own versions of capacitors, resistor, diodes, and LED symbols that are more _compact_ than the gschem stock library versions. By more compact I don't mean just scaled down, but less wasted space in extra protrusions, etc. They are also a bit smaller in relation to connector and IC pin spacing so that they are easier to place in a real layout with connectors and ICs. exactly, I also prefer 200 spacing on larger parts to 300 and clumsy numbering ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Duplicate messages and mailing list To: address
Colin D Bennett wrote: I'm getting all the replies to Kai-Martin Knaak's messages twice. It looks like it has something to do with K-M's messages having a To: field of geda-u...@seul.org while everyone else's has geda-user@moria.seul.org, causing the replies to have an extra Cc: address of geda-u...@seul.org. Is everyone else getting the duplicates? I also get duplicate mails from DJ Delorie and others recently. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: overlapping via changes
Kai-Martin Knaak wrote: 2. Vias which violate this rule in a *.pcb file are preserved at load time. Thus, PCB will make a modest attempt at preventing users from making vias that might be difficult to manufacture, but if the user finds a way around the restriction, PCB will let them get away with it. Simply moving an existing via is an adequate way around it. Thanks. I'll put this to the wiki. Back then when I used protel we actually had cases where overlapping were holes deliberate. The hole had to be non-round and clad with metal. So regular milling wouldn't do. Can you give a reason? - I can only imagine a mechanical one. When you put it on the Wiki, pleas also explain, that doing this is electrical and thermal nonsens, because the circumference of a hole is proportional to the diameter and 2 holes confined in a given length along the direction connecting the centers have maximum surface, if they are either identically 1 big hole or 2 holes that exactly touch each other. For the partial overlap, the normalized circumference u is given by: U/L = u = 2r * (pi - acos(1/2r - 1)) where r = R/L, L is the diameter of the overlapping holes and R is the drill-bit radius. This function is valid between r = 0.25 where the holes just touch and r = 0.5 where the holes melt to one big circular with R = L/2. It has a minimum at ca. 0.295 Hopefully I didn't foul the math, check it ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: overlapping via changes
kai-martin knaak wrote: There is no evidence for users falsely believing that overlapping metal clad holes are good for thermal or electrical conductivity. So there is no reason to preach to them. By heuristic and gut feeling I thought that the presented result would be true. But I was unsure enough to actually do the math behind it. If you think it's preaching, leave it out. I just thought that others may have the same uncertainty, but not the math education. If you present this as a trick without explanation you suggest it's good for something - what for? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
Kai-Martin Knaak wrote: If the symbol for the subcircuit has refdes X15, and it contains a component with refdes C42, the refdes in the flattened netlist created by gnetlist is X15/C42. Local nets within the subcircuits similarly get pathnames for their netnames. I don't like the slash, because it makes the component names extra long. So I put these lines in a local gnetlistrc: (hierarchy-uref-separator ) (hierarchy-netname-separator ) In addition, I set the refdes of the subsheet symbol to a single digit. That way, the refdeses stand a chance to be readable in in silk with a three layered hierarchy. How about emitting only the basename of a refdes on silk - if you got several instances of a circuit on a board, the component values should be identical anyway. With sloting of subcircuits this may be wrong, but then it would make sense to collaps the pathname of a subcircuit into one instance, that you can place to a group of components. In order to get this right, rat lines from the path to the base-refdeses could be used. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: 200 bugs, warts and feature requests
Kai-Martin Knaak wrote: PS: This is what the last couple of lines look like: /-- • pcb wart: rats don't print in the eps HID :-| • gschem room for improvement: If an autosave backup is found, the dialog should offer to show the diff of the two files. sounds quite difficult to implement - diff as ghost symbols ? • gschem usability improvement: If a symbol contains slots, insert should optionally add all slots at once with slot numbers automatically incremented. :-) • gschem usability: The add text dialog should automatically apply the current text when the mouse leaves the dialog. :-( if you don't need to click for placement, 99% of times the text will be elsewhere it's a funny idea, that you have to move the dialog for placement of the text • gschem usability: The add text dialog should contain widgets to set text attributes like size, color, orientation, :-)) • gschem usability: Accel to increment/decrement text size on [s]/[shift-s] similar to pcb :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: 200 bugs, warts and feature requests
kai-martin knaak wrote: • gschem usability: The add text dialog should automatically apply the current text when the mouse leaves the dialog. :-( if you don't need to click for placement, 99% of times the text will be elsewhere I didn't mean to get rid of the apply-click. Just the click on the ok button. If the mouse leaves the dialog area, this should be treated as ok, I am done. Let me apply the current text Sure, the OK button is superfluous. The close button isn't - this raises the idea, that this dialog could have a semi-modal behaviour: if keyboard focus is left in (or rerouted to) the dialog, you can edit the text while placing with the mouse. Rerouting input from the main drawing window to a dialog requires context based swappable handlers, which is a good idea anyways (imo). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
kai-martin knaak wrote: Armin Faltl wrote: In addition, I set the refdes of the subsheet symbol to a single digit. That way, the refdeses stand a chance to be readable in in silk with a three layered hierarchy. How about emitting only the basename of a refdes on silk Then, I'd have no way to locate which schematic subsheet a particular R1 on the layout would correspond to. forgot to post another idea: in the course of general GUI rework, rightclick on a component could bring up info on it, including the complete refdes, the footprint source, XYRS values, attached nets, some of that even editable, e.g. for precision placement of parts. ___ 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
Bob Paddock wrote:
If you switch to gEDA, will you want a native windows build? Help with that
from anyone who is up on windows is on the wanted list.
I've been poking at 'the perfect windows version' for some time, will
give up on that for now.
I think I just make basic canvas and figure how to to get the basic
HID stuff going.
Is there any step by step guide to get a new HID up and running
(besides trolling the list here for the last few years with grep)?
One thing I don't recall be doing before is that I want to use
wxWindows, so it would have its
own main() loop. Whats the best way to deal with that?
Did you try to build/test all the demos that come with wxWindows - did
you try to
build another app, that uses it? - please report. My personal impression
when I
went for a widget tool kit was, that it's very complicated and broken.
My best advice is, to avoid wxWindows altogether and use FLTK instead.
It may be C++ but the nasty stuff is left out - it's more better C, so
I find it very easy and convenient.
With FLTK this problem looks like
main()
{
// define all GUI stuff here
exitCode = Fl::run();
// release and clean stuff
return exitCode;
}
If you want to replace Fl::run() with an augmented event loop:
copy this from Fl.cxx
...
#define FOREVER 1e20
/**
As long as any windows are displayed this calls Fl::wait()
repeatedly. When all the windows are closed it returns zero
(supposedly it would return non-zero on any errors, but FLTK calls
exit directly for these). A normal program will end main()
with return Fl::run();.
*/
int Fl::run() {
while (Fl_X::first) wait(FOREVER);
return 0;
}
...
and modify to your liking. It's not necessary btw. to do that for new
threads,
idle processing or adding your own check-callbacks.
___
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
Bob Paddock wrote: so I'm well familiar with its warts. All of the commercial apps I've had to develop at work have been based on wx. Then you are in a special situation and I won't argue with you about usability. Can't argue with it being complicated. Start with the above book, and get the 'minimal' sample to build/run then go from there. Can't argue that it could be improved in many places, but what can't stand improvement? What part did you find that was broken, and what version where you using? As this was 2006, probably a very old version. If I remember correct, the minimal sample (using OpenGL?) either didn't compile or segfaulted or just didn't do anything on Windows or Linux (I have no Mac). Is it cross platform for Windows, Unix like, and MACs? I've used some applications based on FLTK but never developed any. Yes - I wouldn't recommend it otherwise. #define FOREVER 1e20 Code full of 'magic numbers' with no comments don't give me the warm fuzzies. It should also have parenthesise around the number, if this is truly C and not something special to FLTK. Parentheses around a constant are nonsense - there is nothing a plain number could evaluate to in the preprocessor than itself (unless you #define 1e20 (foo * i++)), so it has the highest precedence by itself. (couldn't you even #define (1e20) foo*i++ ?;-) I personally found, that the comment just below the definition is totally satisfactory. ___ 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
Bob Paddock wrote:
Parentheses around a constant are nonsense - there is nothing a plain number
could evaluate to in the preprocessor than itself (unless you #define 1e20 (foo *
i++)),
so it has the highest precedence by itself. (couldn't you even #define (1e20)
foo*i++ ?;-)
Not knowing how the #define could be used in all cases it is better to
put parentheses around such usages to have the compiler generate an
error, rather than silently give the wrong value in corner cases where
operators like multiplication and division are passed as parameters to
an other macro.
http://gimpel-online.com/MsgRef.html Look up #665.
MISRA2004 19.4 and 19.10 apply in some circumstances as well.
This reference says the same, as I would have answered without reading
it now:
It is sensible, to put parentheses around parameters in a macro
definition like
#define MY_MULT(a, b) do {(a) * (b)} while (0)
because someone could call it like MY_MULT(x+y, u+v), that would evaluate
to x + y*u +v otherwise. But a constant definition like
#define FOREVER 1e20
doesn't have any macro parameters. Therefore defining it like
#define FOREVER (1e20)
is pointless. The parentheses just get ignored by the compiler, so they
don't hurt either. They just show that the programmer doesn't know
in this case, why he is doing what. Not to be confused with
#define FOO_BIT 0x0001
#define BAR_BIT (FOO_BIT 1)
#define BUZ_BIT (BAR_BIT 1)
where a computation is involved, that could get broken by context.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Text in PCB elements
Kai-Martin Knaak wrote: There is a difference: The rendering happens on footprint creation time. It is irreversible, meaning, the text cannot be edited after the fact. I think I got you now: you want to place one footprint per character or generate a footprint, that displays your text - before I thought you want to have a way, that char-footprints can somehow be referenced in another footprint. Still I believe, that extension of the footprint format to contain text is the way to go. Text can be rendered in pcb, so the routines must be there. Truetype fonts etc. discussed lately are a completely different issue ofcourse - but I can live with fonts as is. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Text in PCB elements
John Coppens wrote: I'm somewhat confused about the workings of PCB in this aspect - I suspect this has something to do with the complexity of rotation etc. Polygons are (usualy) defined by their corner points. Rotations of points are most often done by multiplying with a rotation matrix - so there is nothing special about general polygons and rotation compared to rectangles or triangles. (90° rotations of points can be done by coordinate flipping, but again nothing special) Just my 2 cents ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Text in PCB elements
kai-martin knaak wrote: John Coppens wrote: Suggestions? Or maybe an estimate on how difficult it'd be for an average programmer to add? If the text in footprints should behave like any other text, I'd say pretty hard. You'd have to adapt many places where footprints get rendered. If the font is the 'monoline' type generally used in pcb, the redition can be taken from there and is sort of a 10-liner in OpenGL anyway. I addition, the footprint file format would have to be expanded accordingly. And the format change would have to be accepted by the devs. sure The GUI might look up letters as footprints in the library and arrange them to yield human readable text. This sounds like recursive call of footprints to me - what is the advantage to proper text rendering by the routines that do it for silk refdes? It has the same implications to footprint file format as any other rendering method. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: comments on gcode generation
Markus Hitter wrote: Am 01.12.2010 um 21:47 schrieb Bert Timmerman: * no voronoi mode: all the other tools (see below) support a mode where they fill the unused area of the board with the closest net. this cuts the machining time down to less than 50%. Yes, this would be a very welcome addition. Is there a pure C library with this stuff available somewhere? Java or C++ isn't an option for inclusion with gEDA. http://www.qhull.org There happens to live a git repo here: git://gitorious.org/qhull/qhull.git Thanks for the link, Bert. I fear this is a bit too complex for me to justify putting it in the next few days. You might have a look at triangle.c from Jonathan Richard Shewchuk. I used it to compute triangulations in astro-images and it's not complex at all - but very fast ;-) ___ 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
Anthony Blake wrote:
On Mon, Dec 6, 2010 at 4:18 AM, Armin Faltl armin.fa...@aon.at wrote:
Anthony Blake wrote:
Yes, if you were having difficulty with the END_LOOP macro, I can
understand why you didn't venture any deeper into the code.
I had no difficulty finding or understanding the macro, but I have a huge
problem
to work on code, where others deliberately introduce stuff, that is a
maintenance
nightmare. There is a reason, the compiler disallows unmacht '{' in one
file.
Relax, the macros aren't part of an elaborate plan to *deliberately*
obfuscate the code. That file is over 15 years old.
Yes, theses macros make the code look like FORTRAN
I don't think a few 'maintenance nightmares' or matching '{' problems
are good reasons for giving up and just doing nothing instead. You
don't have to like the macros and so on to fix bugs, and IMO just
nutting up and dealing with the matching '{' issues etc is worth it to
nail a bug that may have been bothering you.
Before I can nail a bug, I have to understand the code. If I have to
look at 2 files
to understand something as simple as '}}' this gets disgusting. I don't
have the time
to learn all the peculiarities of the code to be sure of what I'm doing.
Replacing these macros can be seen as a point-fix - nothing is changed
in the logic.
That's why I would have volunteered to do that (and similiar things),
but everyone working on a branch has to apply the delta - and they don't
like to.
Its better than doing
nothing or writing large parts of PCB from scratch.
No, I believe, that if I have no thorough understanding of what I'm really
doing, I better leave the code alone or write a part between clean
interfaces
from scratch. That's because to me this app is not a toy.
When I first saw the 'productivity' of a recent contributor I was
standing in awe.
I thought - incredible, he must have an IQ of 300+ or something. Since his
handling of drilling tool path optimization and the remark on math and
simulation,
it's clear to me, how he achieves this staggering speed. By the oh - I
don't understand
it, let's ignore or rip it out-attitude.
Markus, did you realize by now, that drill file optimization is actually
the NP-hard 'traveling salesman problem'? Tons of literature and
algorithms exist for it ;-)
___
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
Stefan Salewski wrote: On Thu, 2010-12-02 at 16:13 -0500, Bob Paddock wrote: Peter, while all of this sounds great, could we fix the collective problems that we have now first? To many of us PCB is used to ship products, preferably today. Fixing problems is not always fun, especially if one is not really suffering from these problems oneself. So if we can not fix it ourself, we may consider paying other people to do that, in particular if we ship boards and earn money with it. There are blackboards for freelance engineers, to make a defined feature in opensource software. This seems a good model of payment to me. The problem to me in our case is atm: - the writer of a certain feature is not required to understand enough of the app, to avoid new bugs in other parts - the writer is not required to run extensive regression tests after the change and provide tests for his feature as well - there is noone fully coordinating the work of contributors and saveguarding the internal interfaces Since we do not have the documentation Bob requests, it's practically impossible, to meet above standards and without above quality measure in place I'm unwilling to pay any money. Btw., fixing bugs in a well designed, well documented, cleanly written application is a lot more fun than in insert_decription_of_choice and orders of magnitude faster. That's why I suggested to personally throw out BS like '#define END_LOOP }}' and all it entails. Since this was not welcomed, I decided to not try and dive into the code any further. Armin ___ 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
Anthony Blake wrote:
Yes, if you were having difficulty with the END_LOOP macro, I can
understand why you didn't venture any deeper into the code.
I had no difficulty finding or understanding the macro, but I have a
huge problem
to work on code, where others deliberately introduce stuff, that is a
maintenance
nightmare. There is a reason, the compiler disallows unmacht '{' in one
file.
___
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
Bob Paddock wrote: Rick, I got line breaks. . On Thu, Dec 2, 2010 at 3:02 PM, Peter Clifton pc...@cam.ac.uk wrote: 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. Peter, while all of this sounds great, could we fix the collective problems that we have now first? To many of us PCB is used to ship products, preferably today. The Creeping Feature Creacher is a powerful task master. +1 What we really need is good documentation for the Meta Data that contains what a pcb really is. Once MD is documented and abstracted then it should become easy to add any kind of new GUI, Router, Scripting, or just scrap the whole thing and start over. +1 PCB design is a real hybrid of art, precision engineering and black magic. It is only magic for those without documentation, or initiation. +1 Scrap straight line rats in favour of using the topological auto-router? Appology in advance - Peter, so far I thought you are bright ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
Hi, I compiled the latest version of FreeCAD and OpenCASCADE on my machine (with NVidia 8600 195.36.15, Debian 5.0.6). The compile worked reasonable and FreeCAD starts, but when I try to model something, e.g. cut a sphere out of a cube or chamfer and fillet the cube the screen-output is rubbish. Otherwise your general path appears reasonable to me. As it's only free as in beer, I don't fully suggest it, but gCAD3D seems to produce stable results - How about forging the script in a way to have the 3D-CAD program select the model it likes and really emit only XYRS, the footprint and ev. provide a table that correlates the footprint with a (choice of) 3D-model(s)? BTW. gCAD3D can read/write IGES, STEP and it's own documented ascii-format. Matthew Wilkins wrote: If it was me, I think I'd make a script for some 3D modelling package like FreeCAD to generate a 3D model using PCB's XY place file output. The process would be: 1. make FreeCAD 3D models for each of the components 2. generate an XY place file, board outline file and drill file in PCB 3. run a python script in FreeCAD that generates a model of the board based on the outline gerber file. Make holes using data from the drill file. 4. Run a script that makes an assembly by placing components based on the XY place file. At this point you should have a 3D model of the board, right in a 3D CAD program that can be used to model enclosures and other parts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: If you also think the PCB lower-case letter 's' is ugly, here's a replacement
As fonts are required from all CAD systems, here a posting from Varkon list ;-) Hi. I created free ISO 3098 compatible ttf font for use in free CAD programs. The project page is http://code.google.com/p/osifont/, you can check it out and eventually included in your CAD project. hikikomori82 at gmail dot com mailto:hikikomor...@gmail.com This font is required for drawings by certain institutions. Ineiev wrote: On 11/22/10, Mark Rages markra...@gmail.com wrote: On Mon, Nov 22, 2010 at 1:29 PM, Colin D Bennett co...@gibibit.com wrote: How hard would it be to make use of the freetype library to handle all vector-based fonts? I imagine the font outlines could be converted to line elements fairly easily... ? pcb's fonts are special: they are a single line wide. When you need the smallest letters that a given silk process can print legibly, you want those single-line fonts. For larger fonts, freetype would be great, and save us the machinations of creating the text in inkscape or something and importing it with pstoedit. Discuss also using QCAD fonts, please. Cheers, Ineiev ___ 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: STEP Format? [WAS: Re: PCB+GL+3D Packages??]
Peter Clifton wrote: I'm coming round to the idea that 3D is more than just eye candy if we do it nicely. It helps visualise component placement and layout issues far more readily than just looking at flat layers can do. Your brain may spot issues it wouldn't otherwise. One of the things I thought of, is stretching the board in z-direction (make it thicker). I believe that can help see, whether blind and burried vias are really ending at the intended layers, if they are rendered as (transparent) pipes. To help save computing time, the layers in 3D can be just flat (in a mode) - no point in seeing the sidewalls of traces for many uses, e.g. the above one. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
kai-martin knaak wrote: I am playing with writing a VRML importer - which should be able to read files exported by Wings32 (like KiCad), but I can't for the life of me figure out how to drive Wings32 to create a new model! I'd strongly prefer to do 3D models with a full fledged 3D CAD application. Preferably with the CAD app I use for the rest of my construction work. That's the benefit if pcb would communicate the full information of the layout to a free 3D CAD app. This app would shoulder the tedious import/export to the complex formats of the real 3D CAD world -- IGES, STEP, DWG, ... Did I mention, that mesh formats are a one way road, when it comes to construction? +1 (Please tell me, that I don't need to make that point over and over again ;-) I knew that ;-) - no need to convice me. Still if pcb is to display 3D models with OpenGL, a tessellation of the scene is required. Personally, I'd prefer something like the winged-edge data structure of BRL-CAD (not it's UI) to handle intersections of BREPs. Many years ago I started to define something like that myself, but never got enough motivation to to complete it - still, I can help you (and my own demo ;-) with that. You might have a look at http://gts.sourceforge.net/ . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: a different approach to 3D modeling
Patrick Doyle wrote: On Thu, Nov 18, 2010 at 10:01 PM, kai-martin knaak k...@familieknaak.de wrote: Looks like there is no open 3D exchange format that fits the need of pcb: a) render a beautiful image of a populated board b) integrate pcb in a 3D work-flow to fit the board into some tight space. The existing formats are either limited to surfaces rather than objects (STL, VRML). This prevents efficient processing of the 3D geometry. Or they lack attributes for eye candy (IGES). Or they are overly complex and geared to completely different use cases (STEP) Not knowing anything of which I speak (write?), would COLLADA (https://collada.org/mediawiki/index.php/COLLADA_-_Digital_Asset_and_FX_Exchange_Schema) fit the bill? Reading https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_is_COLLADA.3F I believe COLLADA is a format mainly concerned about DCC (digital content creation). It's probably very good at meshes, textures and some freeform surfaces, but I didn't see anything about geometric primitives like spheres, cylinders dimensions and layers. Don't confuse rigid body with solid geometry. Maybe my view is to pessimistic, but one needs to read the spec to prove. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: STEP Format? [WAS: Re: PCB+GL+3D Packages??]
Peter Clifton wrote: That is basically how PCB+GL renders the board. Z isn't very expanded, but you can make out the detail. Some work would be needed if you wanted to reliably look through a section of board in a particular place though.. possibly some adjustment of layer transparency would be in order. The cheapest trick to remove disturbing stuff in front of what you want to see is moving the camera facing bounding plane of the view frustum towards the model - at least in OpenGL. Maybe not what makes you happy though.. And there is a risk, that many users need a very clear explanation of this feature. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: a different approach to 3D modeling
Armin Faltl wrote: Reading https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_is_COLLADA.3F I believe COLLADA is a format mainly concerned about DCC (digital content creation). It's probably very good at meshes, textures and some freeform surfaces, but I didn't see anything about geometric primitives like spheres, cylinders dimensions and layers. Don't confuse rigid body with solid geometry. Maybe my view is to pessimistic, but one needs to read the spec to prove. So I downloaded and skimmed through collada-spec 1.5; In chapter 9 the geometry primitives are described and they include cubes, spheres and such. But I never saw any layers or dimensions mentioned. The intro of the spec mentions CAD though - probably as a transfer format DCC - CAD, not sure about CAD - CAD. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: STEP Format? [WAS: Re: PCB+GL+3D Packages??]
Peter Clifton wrote: On Mon, 2010-11-15 at 10:09 -0600, John Griessen wrote: On 11/14/2010 08:37 PM, Peter Clifton wrote: 3. What format would people like to make models in? STEP, so I can load it in HeeksCAD and use HeeksCNC to carve enclosures. Step looks obscenely complicated, and I'm not really sure what subset we can support. If we need only a hand full of primitives to describe our parts, IGES is probably much easier and does the job. It's understood by practically all systems that understand STEP, and some, that don't understand STEP. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL+3D Packages??
Peter Clifton wrote: An actual rendering from PCB+GL with some code I've been playing with... http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d_packages_mockup.png very nice 2. Will anyone bother to make 3D models for packages? if it's easy enough I'll probably do it for the footprints I create 3. What format would people like to make models in? I'm considering to adopt the format of OpenSCAD for my own CAD-Demo. In principle it looks nice to me, but I need to check details. Then I would use my own demo, to make the 3D-models. I'm thinking VRML (perhaps as output by Wings32) might be a good choice, as I believe this is what KiCad uses. Same, need to check details, e.g. if dimensions and layers are supported. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ANNOUNCE: New gEDA Scheme extension API
Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: copying scheme files cp: target `./gnetlist.scm' is not a directory Seems like a simple usage problem of the cp program... maybe it goes away the second time through? This looks as if a variable that defines the target directory is undefined or empty. If this were the case, cp would complain about missing 2nd argument. The message really looks like cp sees 3 or more non-option arguments, suggesting the target must be a directory. Either the variable defining the source is wrong (contains 2 or more entities) or it could be a quoting problem combined with whitespace in a filename. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hm, does this mean you can implement a library, but you mustn't use material from the standard to document it? DJ Delorie wrote: STEP is an ISO standard, which likely means you have to buy the standard itself, but you can implement it freely: http://en.wikipedia.org/wiki/ISO_10303 ___ 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
Kai-Martin Knaak wrote:
Andrew Poelstra wrote:
The problem I have with JSON (and to some extent, Lisp) is that it is
not self-documenting. You can't open a JSON document and immediately
see what everything is and what it does; it just looks like gibberish
and brackets.
+1
Whatever format is going to be chosen, it should be friendly to human users.
In the days of TB hard disks, GB RAM and GHz processor clocks there is no
need to compromise readability to save some bits.
emote_mode_please_skip_if_offended
Because of progress in hardware, I can lift terrabytes easily. To all,
that think
what_not_pointless_name_which_is_very_verboseC5\what_not_pointless_name_which_is_very_verbose
is friendly to humans, I wish they have to wade through this up to
their nose for ages.
Who needs whitespace? I mean, if the parser can do without it, why waste
some thought on pretty printing. MS don't pay their OSS compatibiltiy
guys for that.
I've been programming HTML for years - it's ok, but not my favourite choice.
+1 to JSON or YAML ;-) and a very concise choice of names. We don't have
extremely
complicated structures, so 3 brackets are managable.
\emote_mode_please_skip_if_offended
Would this have been comprehensible as:
{
emote_mode_please_skip_if_offended:
Because of progress in hardware,...
}
? At least it's machine-convertible to XML. Does XML have a notion of
orderd lists?
___
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
DJ Delorie 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? +=3, just repeat my self twice ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: coordinate systems [was: pcb crooked traces]
Phillip Jones wrote: I disagree. There are situations I can think of in which manually entering coordinates would be simpler than using a GUI method. I definitely think we sould flip the coordinate grid, but what would that do to exiting files? Version the file format. Introduce a new PCB_FILE_VERSION. If this is defined in the file then call the appropriate read function, if it is not defined then use the old function. The file format of pcb-boards is versioned, the footprints aren't. Both use the Y+ is down cs now, but clearly that's the only solution for both ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: coordinate systems [was: pcb crooked traces]
Andrew Poelstra wrote: On Tue, Oct 12, 2010 at 10:12:41PM +0200, Armin Faltl wrote: Btw. while being a different topic, how about getting rid of the lefthanded coordinate system, when all numeric computations have to be checked anyway? This should make the cs consistent with trigonometric functions. What does lefthanded coordinate system mean? It means, that positive coordinate axes can be generated as follows: looking from Z+ to the center X+ moves into Y+ by a clockwise rotation (for lefthand). Z+ is your extended thumb, then form your fingers to a hook; the finger tips point into the direction of rotation around the thumb. With cyclic permutation look along: Z+: X - Y X+: Y - Z Y+: Z - X A lefthanded coordnate system is the mirror image of a righthanded one, the later being the norm for mathematical formulations, esp. vector notation of rotation. E.g. in polar coordinates P = P(r, phi) the angle phi has to be measured counterclockwise from the X-axis to make the transformation to cartesian coordinates look like: P = P(x, y) = P(r*cos(phi), r*sin(phi)) with X+ pointing right an Y+ pointing up (and Z+ pointing out of screen). This is a convention. One can argue, to define the the sense of rotation clockwise and have Y+ look downward, but this is against the mathematical standard and pcb is the only CAD program I know of, that does like this. It's incompatible with any CAM file format, plotter language, OpenGL etc. Many raster devices and -image formats are lefthanded, probably the reason, why pcb is. Sorry for (partly) repeating myself. ___ 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
Andrew Poelstra wrote:
Well, the C standard says that long must be ``at least'' 32 bits,
maybe more. To the best of my knowledge, gcc uses a 32-bit long
even on 64-bit systems, to maintain compatibility with old code.
This was true last I checked, a year or two ago.
Tested 5 minutes ago:
[ a...@ajf5 ~]
uname -a
Linux ajf5 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010
x86_64 GNU/Linux
[ a...@ajf5 ~]
cat long.c
#include limits.h
#include stdio.h
int main()
{
int i;
long int l;
long long int L;
i = INT_MAX;
printf(i = %d\n, i);
l = LONG_MAX;
printf(l = %ld\n, l);
L = LLONG_MAX;
printf(L = %lld\n, L);
}
[ a...@ajf5 ~]
./long
i = 2147483647
l = 9223372036854775807
L = 9223372036854775807
[ a...@ajf5 ~]
exit
long long is ``at least'' 64 bits, which is why gcc does its emulation.
And yes, it might be better to use long long even on 32-bit machines,
if the performance hit is not too great. But we'll have to do testing
to see.
Andrew
___
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
DJ Delorie wrote: On Mon, 2010-10-11 at 15:25 -0700, Andrew Poelstra wrote: I think we want to allow negative locations. It would be nice to set parts outside of the pcb boundary, for example when initially placing everything. We limit ourselves to half so that *distances* can fit in a signed same-size value. The range of computable distances on a board will always be twice the range of coordinates. More if you do 2-D distance, but we can use floating point there (we'd be doing a sqrt() anyway) When using signed integers for coordinates and offsets (vectors), by restricting to the positive quadrant, allowing a 2x2m board will still yield a 32-bit overflow, if you try to place a large footprint at the right edge of the board. So I think forbidding negative board coordinates doesn't guard against anything. If one wants to enforce range-savety, the boards and footprints better be +-1m maximum. Personally I favour 32-bit integers on 32-bit machines, because I think that 64-bit emulation must be at least 3x slower than native ops. Enable 64-bit coords on 32-bit machines with a configure flag. On 64-bit machines of course 64-bit, since 32 is probably slower. s ___ 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
Andrew Poelstra wrote: When using signed integers for coordinates and offsets (vectors), by restricting to the positive quadrant, allowing a 2x2m board will still yield a 32-bit overflow, if you try to place a large footprint at the right edge of the board. So I think forbidding negative board coordinates doesn't guard against anything. If one wants to enforce range-savety, the boards and footprints better be +-1m maximum 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. 1m to the edge of the board, 1m from the center of the footprint (positioned at the edge of the board) outwards. If you don't adhere to that, the outer pins of the footprint will turn up at the opposite side of the board (because of overflow). Having said that, I still want negative coordinates. So do we need to limit things to 1m? Yuck. It's still possible to design a 2x2m board when the coordinate center is in the middle of the board. It is also possible, to do some offset on IO and show only positive numbers to the user. And one can limit footprint sizes more and add that to board dimesions. If you use unsigned ints for coordinates and signed for offsets, you have to make sure, no negative number results from subtracting, meaning you might shift the valid range of center-coordinate for footprints to 1/4*UINT_MAX to 3/4*UINT_MAX internally. Then again, this is clumsy, so stick to signed int and [1/2*INT_MIN .. 1/2*INT_MAX]. ___ 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
Steven Michalske wrote: Internally the origin of the grid should go to the middle of the board, but have the board translate the coords to physical of the upper left, or even lower left. Make some folks happy about their y decreasing or somthing or another. Occasionally someone is changing the size of the board while placing/routing. While it's possible, to move the contents on resize, just leaving the coordinate center where it is - preferably where the designer wanted it to be, e.g. at a certain fiducial - makes more sense to me. Btw. while being a different topic, how about getting rid of the lefthanded coordinate system, when all numeric computations have to be checked anyway? This should make the cs consistent with trigonometric functions. ___ 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
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
Re: gEDA-user: pcb crooked traces
Replying personally, because this is getting nowhere: Rick Collins wrote: 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. Wrong: the input data of a footprint is listed pin by pin. If a generator tool, that can handle metric and say uses double numbers, is used to create the footprint it will: a) compute the true positions of all pins to double accuracy b) then convert this value to some fractional mil-number, pin by pin c) round that position to 1/100th mil to make pcb happy, pin by pin The footprint file format as I said lists all the pin/pads and gets read sequentially by pcb - pcb doesn't have the slightest idea, what spacing the pins are - they could be at random positions. Double is probably more than sufficient to get 100 increments of 0.8mm right to 1/100-mil, but if it weren't, use a Sparc with Quad-precision floats to generate the footprint. Say the true increment in 1/100th mil were 548.6-periodic. Then a good generator will produce the following differences in the footprint file: 549, 549, 548, 549, 549, 548, 549,549, 548,... If pcb itself is used as a generator by e.g. using a 0.1mm pitch grid and manually painting the pins, it's up to the implementation, to round values of a foreign grid to the correct internal number - I can't answer this for pcb. In principle it is possible, to precompute a sequence for every metric pitch offered, that will convert the N'th construction grid position to the correct 1/100th mil. What pcb really does in this respect you must ask the developers. All I want to say is, that a 100-pin footprint not necessarily has anything to do with adding up a single-pitch roundoff error 100x and that pcb by it's structure does not have the notion of arrays and multipliers in a geometrical sense. It treats all pin positions as where they are according to footprint one by one. If you found this useful, you may post it ;-) ___ 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
Ooops... Armin Faltl wrote: Replying personally, because this is getting nowhere: ___ 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
Hi timecop, your first message I just deleted which is a rare exception on this list. Since DJ did, I'll waste some seconds and joules on you: a) 2010 - 16 = 1994 b) http://en.wikipedia.org/wiki/Ext2 - Jan 1993, 1 file max 2TB c) the first versions of NTFS had limits completly different than now Please stay under your rock. timecop wrote: Whaat. Please keep your off-topic bullshit *off* this list. I was pointing out that NTFS, created ~16 years ago, had support for 64bit filesizes etc way before lunix even knew what a file 4GB is. *AND* that I can use *ANY* windows app and have it properly work with large filesizes WITHOUT having to recompile it or otherwise waste my time. Having to rebuild something with ./configure --enable-shit-that-should-be-on-by-default is freaking ridiculous. P.s. who the fuck is john lennon? On Sat, Oct 9, 2010 at 11:14 AM, John Griessen j...@ecosensory.com wrote: On 10/08/2010 07:32 PM, timecop wrote: Ah, this is where opensource way of thinking fails it. http://www.google.com/search?q=John+Lennonct=lennon10-hpoi=ddle John Lennon Advanced search About 47,600,000 results (0.15 seconds) http://www.google.com/#hl=enexpIds=17259,18168,25567,26614,26644,26997,27006,27015sugexp=ldymlsxhr=tq=timecopcp=6pf=psclient=psyaq=faqi=g5aql=oq=timecogs_rfai=pbx=1fp=54a191137d571141A About 2,540,000 results (0.24 seconds) and timecop seems to be Time warner cable for the first 60 pages of google results, and includes http://www.travelgrove.com/community/users/timecop/ Is that you, timecop? If it was it would probably be 1 hit worth out of 47,600,000. Probably not, you won't come out from under your rock. Not for anything that matters. JG ___ 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: Database on symbols, footprints and other (was Re: gattrib)
Edward Hennessy wrote: On Apr 29, 2010, at 2:14 AM, Armin Faltl wrote: To express the many-to-many relation between parts and symbols it uses a table called device. This is fed by the infamous device attribute in the symbol libraries. There's nothing wrong in the theory of DB-design with it, but the indiscriminate use of this attribute in the symbol-libs waters the use of this design down to uselessness. I'm investigating another mechanism to create a part 'class' with some existing data in the part library. Using the device attribute for this causes problems. I am pondering the first portion of the symbol filename. So, 'resistor-1.sym' is part of the 'resistor' class. Any other suggestions? Thank you for still working on this hard topic at all. Do I understand you correct: you want to limit the range of symbols, that are possible to connect to a given part, based on a part classification? I don't recall all the details of the DB layout, but i fear, the only solution is to manually enter meaningful device values in the symbol libraries. I'm not aware, that the device attribute is used for anything in the current workflow, thus the quality of the entries. If one sets out to map devices to a part classification, I'd suggest ':'-notation like diode:schottky or transistor:power:igbt. Therefore it is questionable, to completely preset this value in the symbol library at all - maybe just the 1st element. This would require a strict rule: something that does not have the same symbol mustn't have the same top category: MOSFET != transistor or the top categories would need to be 'transistor:mosfet' and 'transistor:bipolar' - I'm getting confused... ___ 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
timecop wrote: Is this seriously turning into a pissing match you name it, you get it: it's no longer about technical arguments, it's about the amount of shit one can produce: you won!!! ___ 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
Andrew Poelstra wrote: I think we should also test sin and cos -- and since for integers, there will be casts involved on either side, I suspect there will be a performance hit. Also sqrt and pow. (In Lisp, isqrt beats sqrt, but I just tested in C (gcc -O3 -lm), and sqrt wins by a factor of 10!) Perhaps I simply have a crappy isqrt implementation, but this seems like an argument in favor of floating-point. How common are these ops in pcb? How common would they be if we had a decent DRC? sin, cos, sqrt and other heavy functions are most likely avoided, even for design rule checks and don't (frequently) occur for placement operations, since normally rotation matrices are used, that are set up once and then used for all coordinates of the relevant object (e.g. an oblique footprint). For DRC distances on would compare the square of distance to the square of the limit, giving the same truth value. ___ 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
Kevin Vermeer wrote: 2. Necessary Software If the hardware requires software, embedded or otherwise, to operate properly and fulfill its essential functions, then the documentation requirement must also include at least one of the following: The necessary software, released under an OSI-approved open source license, or other sufficient documentation such that it could reasonably be considered straightforward to write open source software that allows the device to operate properly and fulfill its essential functions. This is about the software that runs on the hardware, not about how the HW was created. IMO, a high resolution raster image of the layers and pdf of the schematic would qualify as open HW without problems. Kudos to Jeffrey for adhering to true open-source design! +1 ___ 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
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 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 ___ 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
Andrew Poelstra wrote: As for board limitations, I think that if you are designing boards bigger than 2m (and cannot make a small board then scale the gerbers after-the-fact), chances are you've got a 64-bit system. Of course, then we need to worry about file-format compatibility between 32- and 64- bit systems... The files are ASCII text, so the numbers are not in binary anyway. The only potential problem would arise, if you try to read a 64-bit generated file with a board bigger than 2m into the 32-bit-app. 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. Sounds good for me as a transition path. As stated by others, no factor or just old version number in the file means x254, then nothing and new version could mean 1x, any other value means what it says. The scale factor and a version number of interpretation would be very practial in new-lib footprint definitions as well: Just say unit = 1000[nm] and write everything in micrometers, saving the numerous ums. ___ 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
Rick Collins wrote: 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. Looking at the output is a precondition to verifying anything. You tell me, that I shouldn't look at the input. But it's one of the iron rules of computation: garbage in - garbage out Having to verify the output on each and every design is rediculous. It's like a marksman determining his hold-off on every target by trial. This is not very common nowadays because the bear wins. 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) ... When you find out what PCB does, a through e, what will that tell you? It will tell me, whether what PCB does, conforms to the standard or has a chance to conform to the standard with correct libraries. If you don't know what the standard is, how will you know if your design is correct? If there is a standard and I don't know it, it's my fault - and of course I will never know until the assembly house told me, that I screwed up. Maybe for the series you do, the cost is negligible. At my present state of business €250 for the setup compared to €950 for assembling 30 boards is a considerable cost factor. If I can get rid of this or reduce it to €50 because the assemblers knows they can trust my data, this is a huge competitive advantage. Maybe the savings generated by this discussion here never hit my wallet. But I'm not writing for me alone, as I use others work for free. ___ 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
Rick Collins wrote: 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. I know that and was on the verge of replying the same. All I want is to make sure that I'll provide a correct description of the geometry. And now it's time for more reading and less writing. Thanks again for sending me the standard. ___ 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
Karl Hammar wrote: +1 for nc since ICs have pins that are labeled that way. Would the DRC just ignore it, or would the DRC complain if it was connected to anything? +1 ... 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. 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple monitors
John Griessen wrote: That's a nice idea. I'd also like a feature where besides just panning, you could define views that stay around. They'd show as zones on the whole design view, and selecting them would open the pcb work view window on that area of interest. A way to do a UI for that might be to pan when you click outside one of the defined views, zoom to a defined view when you click inside it, and mov ethe defined view when you click and drag on it. My mechanical cad demo has a similiar feature: 5 buttons that will store views: - middle click on one of them stores your current view - left click makes the stored view active You have to remember what was where, but a thumbnail of the whole board with a red frame in it can be realized. I implemented this, because mechanical constructions sometimes have 2 small areas of interest with long parallel lines connecting them - but I find it generally handy. ___ 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
Steven Michalske 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. Thank you - finding out this information is what I meant with I'll have to read, how the footprint coordinates and placement in the board influence the actual values. It would be interesting, whether a mark statement in the footprint is ignored as well and how the rotation is computed - can you hint me to the relevant source files please? ___ 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
Rick Collins 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. Again, yes and no: in our present state of standardization probably. But at least the designer didn't screw up alone: the guy who did much more is the library builder. That one is the person, responsible for conformance to standards in the first place. And that's our subject in the thread: new footprint guidelines - what is considered trusted fact in construction involving cooperation must be based on standards - and they evolve. There was a time, metric screws or Whitworth screws etc. didn't exist. Every supplier defined screw gages as he pleased and a designer, who didn't check, that the nuts fitted on the bolts, screwed it 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. 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. Oh, I almost forgot, NEVER ask a PhD anything to design PCBs. What the heck are you thinking??? As I may go the route to PhD if I find the time and a worthwhile subject, I'm glad we are talking about this now, before I have started ;-) Btw. to achieve standard conformance, the gschem symbols of polar devices have to be checked/reworked as well. The best solution probably is, to explicitly attribute conformat libs and keep them under their own section on gedasymbols.org. ___ 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
Kai-Martin Knaak wrote: I think registration marks help a lot. Attached you find my favourite mark, that regrettably can't be converted into a footprint, because it contains polygons. I converted it to a footprint anyway ;-) Nice work, thanks ___ 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
Rick Collins wrote: 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. This (planar, linear rigid body) transformation is just one word for translation plus rotation. Sorry, if this was PhD talk - I'm too used to it. ___ 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
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) ... 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. Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
DJ Delorie wrote: Time to plug-in a graphics card? Almost any nvidia model would do. I have a pair of Nvidia 9800 GT cards in my box, and yet the plain X Lesstif HID still blows everything else away. The cards alone are only part of the pipeline. Do you have an explanation for this? I thought that X is pure 2D and thus only primitive operations have to be computed for each span of a shape. On the other hand, a full GL-engine will do the 2D/3D transformations and span computations in hardware, so all the CPU has to supply is untransformed vertices. What may slow down the GL version is transparency. One big factor may be the R-tree acceleration built into the X implementation. This will be difficult to emulate, if one wants to use display lists in GL. Otoh a sensible GL implementation will do frustum culling - so why? ___ 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
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... 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? 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. 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. 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. 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 munched into the XYRS file. I use 0,0 as the lower left corner of the board and my fab drawing gives coordinates of the fiducial marks on the board along with major drill holes (like mounting points). So all coordinates on the board are positive. Why would you want it different? I don't know what a .fp file is. I don't want it different for the board (which would require reversing Y-orientation in pcb), but for a loaded footprint definition. BTW, all part coordinates should be wrt the centroid of the part, not pin 1. Some CAD packages used to use pin 1, but it is standard practice to use the package centroid now. Centroid always appeared natural to me - it's the best position for physical rotation axis as well . What sort of checking of the footprints do you want to do? You should use a Gerber viewer to verify the Gerber files. Nothing inside the CAD system matters if the Gerber files aren't right. What would be great is a viewer that understands the part shapes and positions the parts according to the XYRS file on top of the Gerber file images so you can verify alignment and orientation. Since the assembly house won't have/use my footprint definitions and I don't want to make a drawing of each and every part, if a standard clearly states, how it looks, I have to check, whether the CAD-internal definitions conform to the standard. If no standard existed at all and I really have to make drawings with whatever tool, I still have to confirm the CAD-internal definition is identical to the drawings.
Re: gEDA-user: new footprint guidelines
Steven Michalske wrote: Would registration marks help with this? Three points forming approximately a 90 degree corner. Would give the ability to detect +x,+y I know our smt lines heavily depend on these marks. Steve I think registration marks help a lot. Attached you find my favourite mark, that regrettably can't be converted into a footprint, because it contains polygons. It's very good for machine vision, gives sub-pixel accuracy. Since they allow to measure board manufacturing distortions, I'd eventually place 3-4 marks along each side. Using different marks to indicate axes. regmark.pcb Description: application/pcb-layout ___ 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
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. 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 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 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 like.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: improved footprint for MSOP10
Currently this may be too much of an honor - I have about no time to maintain that space. Furthermore I'm satisfied with my name as author, if a footprint makes it into the general library. Kai-Martin Knaak wrote: Armin Faltl wrote: since the library version footprint MSOP10.fp seems to be very unprecise, I made my own, which is included below. How about an Armin_Faltl section in http://www.gedasymbols.org/ ? ---)kaimartin(--- ___ 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
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... ___ 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
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
Re: gEDA-user: new footprint guidelines
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
Re: gEDA-user: foreign graphics overlay
Bob Paddock wrote: What is the benefit of plug-ins for this kind of infrastructure? IMHO, support of different image formats should be part of the main distribution. Someone, some place, in the future will want to support something that none of us have ever heard of today. If there is a easy, well documented, Plug-In system, then they can implement what they need without having to figure out the internals of PCB. Also Plug-Ins make it harder for various sections of code to interact, by design, to give a better separation of concerns. Yes, that's the idea behind it. I said plugin, but the more trivial version is just a method hook: a template-ish function [renderForeign()], that gets called if a flag is set, saying there is some foreign graphics to display. All the function gets handed is a display transformation, a general transformation that maps the pcb-space to foreign-graphics space and a filename(list). Whether renderForeign() contains just some format specific rendering calls or really uses dynamic linking to call something unknown to pcb is up to the implementer. The actually implementation can be a bit more complicated to allow for preprocessing and setup, but the idea is just this. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: improved footprint for MSOP10
Hi, since the library version footprint MSOP10.fp seems to be very unprecise, I made my own, which is included below. The major difference is in the spacing of pads. Regards, Armin MSOP10_ajf.fp Description: application/pcb-footprint ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: improved footprint for MSOP10
Stefan Salewski wrote: Please try to give more detailed error reports -- if that one is really wrong, we should remove it. The spacing of pads in the library footprint, checked visually and in the editor is very uneven. The centers of the pads are off the theoretical 0.5mm pitch by 0.1mm or so, which I find completely unacceptable. The footprint itself is from the 1-mil-time, not in 1/100-mil. Considering that the pad width is 0.3mm, the library version should really be replaced. Once agreement on my (modified) version is reached, I'll add the license. To yours: Do you really think that it is a good idea to have the text overlapping the pads by default position? At least *I* like it more than somewhere outside - I normally move the refdes anyway to enable tight packing of parts. If you want, you can put it at the top left corner. Well, iirc, this may be a bug with pcb, that wont handle a text position well in um-mode... The silk is close to the pads on the left and right side, at least distance is not symmetric on all four sides. I took great care to make the part symmetric, so it is. If you mean left and right margins are not equal to top and bottom, true. The reason is, that I kept the dimensions of the libary silk screen and made the pads longer for better hand soldering. Make the silk wider, if you like. Please note, it is a good idea to specify source of layout data and license for distribution. PCB footprints can have attributes for that. The source is probably a datasheet from Linear Technology. I realized that I left out a license after sending out... Hexadecimal flags may be OK, but textual ones seems to be preferred in these days. Is is really useful to have these thin soldermask areas between pads, or should we prefer a gang solder mask? With my manufacturer it is useful. I got the impression, that a gang solder mask will ruin your day. I do route on the inside of such a chip and wide solder mask gaps can lead to unnoticed shorts on the inside of legs. This is a question, I am not sure, but I think there is no real advantage for these stripes, but manufactures can have problems with it -- ok I think they remove it anyway. Piu-Printex doesn't remove the mask - if need be, they fab even smaller. But then again, they appear to be at the top end in Europe. 'multipcb' didn't complain either. ___ 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
DJ Delorie wrote: [snip] 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. During modifying library footprints, I found comments about placement lines, requesting additional non-fabrication layers like placement and outline. As there is currently no distinction on which layer an ElementLine[] would be, I suggest two mechanisms to achieve this: a) make the layername a text attribute in the flags. If no layer is named, silk is assumed. If there is no flag or layer of that name, again silk or autoinstantiate the layer. b) have an optional layer attribute behind the flags Option b) is more flexible I think. In that way, it would be quite nice to have some pure drawing layers besides a layer for part outlines to make center lines, rulers, dimensions and the like as in mechanical 2D cad. Actually I stumbled over this with placement of potentiometers, that have to be behind a hole drilled in the cover, LEDs etc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: foreign graphics overlay
Dreaming about mechanical cad features in pcb and how one best works to mechanical constrains on a pcb, knowing the latest and greates pcb use OpenGL and transparency anyway, how about providing a plugin-mechanism, that allows to render DXF, SVG,..., bitmaps of common types and such on a non-functional translucent foreign layer? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Message
Hi Östen, to create a symbol you might start with an empty *.sym file instead of with an empty sheet, that by default will contain a frame. Like all entities, the reference to the frame in the .sym file has a flags section, containing the flag unselectable which is set in the case of the fram. By setting the flags to 0x00 or on the frame it gets selectable and can be deleted. Selection I think also works, if you select everything with a mouse-rectangle and then unselect the parts you want to keep before deletion. Regards, Armin Östen Einarsson wrote: Message to gEDA-forum ___ 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: Portable gEDA for Windows
DJ Delorie wrote: If you can figure out a secure legally binding DATED way to make that offer online, and not get screwed by someone who edited the file to change the date ten years down the line, and have it all hold up in court, go for it appart from the problems of millions of people taking the offer, would a file with an officialy registered signature (by Digital Signature Act) be appropriate? How does FSF themselves handle this? And why include a clause in a license, that no one can legally fulfil maybe? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How do write an autorouter?
Writing an autorouter is a very demanding task. I'd estimate it in the range of 10.000's of lines of code since a good working router will contain many heuristics to try and achieve optimal results in many situations. Lots of cases that are mathematically difficult to understand have to be handled. The datastructures and algorithms have to handle geometry and topology and performe transformations on bundles of traces. Have a look at the mathematics describing knots, nonlinear optimisation,... Maybe to negative, but you have been warned - if someone knows tricks to get past this, correct me ;-) Oliver King-Smith wrote: So I want to auto route a design for my ASIC, and magic is being a little flakey (It seems it connects some nets together that don't belong and fail to connect nets that do belong). I was wondering if anyone has any references on how auto routers get written. I know some stuff about my design. For example I want the router to avoid certain regions (rectangles that represent cells). I know the net list, and the connection points on the edge of cells. If this is 1000's of lines of code, well that is not practical in my time frame. But if folks have designed these things and the principle is straight forward, I should at least consider writing one. So what is the principle behind the routers and how hard have they been to implemented in the past? Oliver ___ 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: the uber-scope (was: wishful UI)
Stefan Salewski wrote: Indeed I was hoping for some support during the last two years, but there was not much interest, some people with very limited skills in electronics area contacted me, hoping for a very cheap device. But of course I can not build large quantities, so costs can not be smaller than similar commercial tools from china, so people are disappointed. I do understand that. I'm well aware (by now ;-) that building something from scratch is not the cheapo route in many cases. No, currently I do not need help, I have done schematics and layout very carefully, learned VHDL, started design of a GTK GUI. I'd help you if you used FLTK instead (and C++), actually I already got something called 'flscope' - it would need to be dual license though - well I can actually give you some code without mentioning it's from me or whatever - or BSD. That application uses 2 threads: one for the GUI and device control, the other to read and store the data stream. Connection to a particular device is designed modular. My personal interest in a homemade one would be something like a mainframe scope: slot cards of potentially different type that communicate with the controller and memory board via a highspeed bus, basically supplying a steady stream of time coded samples. The master board sends a clock signal to all signal converters and info like settings and start/stop. For very fast signals, one could of course include local memory on a slot and transfer data in bursts. This should all be no problem with a bus like PXI (PCI eXtension for Instrumentation), but I wouldn't use copper - I'd like to have a fiber bus for electrical insulation and floating channels, so the power supply alone determines rated voltage (5kV - 20kV ?) Should I really manage to burn a slot, 500-1000€ evaporate and not 1. (an analog fiber connection from an active probe to the digitizer slot would be cool as well) And I wrote my own USB firmware some years ago. Currently I am doing some final checking of schematics and layout, with minimal modifications. I indent to order parts and two PCB prototype boards in harvest and intend soldering the first prototype before end of this year. If that prototype works, than there may be again room for support, for example for optimizing the VHDL code, board firmware and communication with the PC, and finally optimizing the user interface. VHDL - thats specs for a silicon compiler, right? - so you are using ASICs in hobby-project? I will tell on my homepage and on this list when there is the first working prototype -- hopefully before the end of this year. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
DJ Delorie wrote: Sure, and the big EDA code based on LISP/Guile also uses syntax for names so a wire with such a name attrib seems to be all that's necessary to define a bus. Putting the syntax netname[0:7] into form netname[0], netname[1], for the backends is fine. Seems to me the common code would still need to be aware of bus nets. I published my paper mostly to get a discussion going on what busses *mean* though, not the implementation details. For example, what does it mean when three busses with different names are connected? D[15:0] ==** D[15:0] || \\ A[1:16] The problems I see with this are: * 2 names for the same bus are probably confusing for a user * if busses of different name are allowed to connect, they should have the same wire layout * if they really shall look like above, the number of wires must be equal and the obvious mapping mechanism must be in place If all this is not for you, would it be possible to make a bus-mapper/connector symbol? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
DJ Delorie wrote: And I want to understand the implications of pins that reflect multiple signals, too - mapping names and numbers, etc. I can only envision 2 cases for a multipurpose pin: a) the generic interface shall be preserved - don't care what the pin means, just pass a wire b) the pin is actually used for something hardwired in the board - it's no longer multipurpose ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: 1) Assign unique refdes value to all netlistable logical symbols in the schematic. If the logical symbol is one of several in a PHYSICAL_package, then assgined refdes to each logical symbol such as Uxx_yy; where yy is the value to identify a particular LOGICAL_SYMBOL among several within a PCB_PACKAGE; and xx value is the ID to differentiate among all PCB_PACKAGE for your design. Uxx is what you want to see in your PCB netlist. maybe I misunderstand something here, but if you want to say '_' in Uxx_yy is actually a separator you should come up with a positive definition of what a standard refdes can be made of. The sloopy way chars get assigned special meanings with all sorts of identifiers in geda really annoys me - and imho bites everyone in the long run. The above example would make another step to: you may not use ':' in blah, unless foo is set to 5, and '-' can bit you in some circumstances. I can assure you that '_' is valid in refdes, unless it's used for a bus in which case... Depending on the phase of the moon, '/' in an identifier can mean either:... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: experience with import-schematics
kai-martin knaak wrote: Look at make_footprint_hash() in src/buffer.c Maybe we need to read the menus in reverse order? ^ paths? I'd say, the last path should receive highest priority. This is how the PATH environment variable of the shell is parsed. you mean the first directory has highest priority, same in linker paths ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: In your work flow, English words convey duties to hired layout persons. In my example, I only hire the autorouter. Sounds very useful. Especially for open hardware projects and hobbyists, and bottom line oriented business folk. Sounds like you suggest the autorouter as suplement to propper understanding of layout - I've been struggling and reading for weeks now with this subject. One of the primers I found states: ... The autorouter is a tool to speed up the work of specialists and should be avoided by beginners. It is no replacement for understanding the implications of your layout... My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Specification of Rotations for Auto Assembly
Rick Collins wrote: This seems like a pretty sharp group. One of the problems I consistently have is generating an XYRS file for auto assembly of my boards. The X and Y require a specified origin and orientation of the board, which is done in the fab drawing. The side is pretty clear as well. But I always have trouble with the rotations. There are two sides and even if you pick a convention for the angle of origin and the direction of rotation, you still have to decide if the bottom side is viewed from the top or the bottom. When I have asked assembly houses about what they assume as convention, I never get an answer. They just tell me that they need the X and Y data along with the side. They basically figure out or at least verify the rotation data for themselves. Is that what you find? It just seems very odd that there is no accepted and widely used convention for rotations. I found info from IPC that says pin 1 in upper left corner is 0 degrees for ICs. But I've seen nothing that addresses how to spec the bottom side components. A FreePCB companion program. FpcPlace assumes all rotations are CCW and viewed from the top. But the footprint generator makes the footprint with pin 1 in the lower left which screws everything up, or so the FpcPlace developer says. It looks to me like the FpcPlace program is not correct. One of the things I dislike about pcb is the coordinate system: it's lefthanded, or z+ is going into the screen instead of pointing out. The right hand rule says: if you spread your first 3 fingers (starting with thumb) orthogonal to each other, thumb = X, point = Y, middle = Z ( or if you hook your fingers to indicate a rotation that will move X into Y, spreaded thumb poins to Z+). This is the basis for all math definition on vector operations in 2D and 3D, it defines the mathematically positive sense of rotation (CCW from above). All mechanical CAD systems and robotics controls adhere to this. So to define a rotation consistent with production, the first thing one must do is set up a proper 3D coordinate system. As a SCARA robot can only access one side of the board at a time, it's now a matter of convention, whether your designer procomputed rotation fixes the base coordinate system to the board (that gets flipped, so Z+ points up or down) or to the robot base. If I were to come up with a convention, I'd fix it to the board, since the actual placement of the board in the robot system (position and rotation) is unknow to the designer anyways. Next convention would be X is longer side, Y is short for rectangles. To define the complete position, one has to carry out 2 rotations (I know they can be combined to one oblique) for the backside: flip the board, then somehow rotate the chip. As the rotations can be combined, they can't be independent: you could flip the board around it's X-axis (makes most sense to designer) or it's Y-axis or around robot-X (what they fabs probably do) or around any other axis in the XY-plane, yielding completely different angles for the chip rotation. That's what the fabs actually tell you: if you believe the XY-plane to be in the center of the laminate, indicate which side is Z+. HTH, Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Actually, I don't think that's true: Suppose I have a trace whose clearance is set to 2.5mm - if I lay any component too close while the real-time DRC is running, how can it know that it's breaking a rule without re-checking the clearance for every object on the PCB? By checking exactly the object you are currently trying to place against the traces in vicinity, that can be found by bounding-box intersection. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: discussion on what busses *mean*
DJ Delorie wrote: I can't think of a good reason to do this, but I suppose you could connect to a bus pin (aka pin with multiple signals) and name the *bus* while leaving the individual *nets* unnamed, and carry that bus name on to a second schematic page, still without naming the nets, and connect it to another bus pin with the same number of signals, and hope it all works out :-) If a bus-pin (or bus-port?) is required to have an internal representation of the pin connections and the two bus-things ;-) are required to have identical layout it should work - it's like a cable with colored wires. If the bus definition exists independently of the ports (ie. the list of wire colors aka signals, irrespective of any plug type), one has the freedom to pick any subset of the signals and define a port for it on a part. I hope this wasn't to trivial to mention. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: On Sat, 2010-08-07 at 12:58 -0700, Andrew Poelstra wrote: I agree, but on a high level a net /is/ a relation between two pads/pins. (Well, a net can have many pads/pins. A subnet would be restricted to two, by definition.) No. A subnet, in my mind, is not restricted to two nodes (pin/pad). The +5V net with netname five_volt_positive can contain a high current subnet including DC-DC converter, big capacitor, fuse, high current devices. Just to make this clear. Just to make it known, a subnet is a point to point connection within a net was the one and only DEFINITION of what a sub net is I found and understood. All other ways I can conceive are generalizations of that, ie. a subnet is a list of 2 or more pins within a net. For lists of 3 or more pins attributes like length or impedance don't make any sense, so this appears to me a bit like sound and smoke. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Andrew Poelstra wrote: There are two problems with this: 1. I would have to create bounding boxes for every object on the screen, because you never know if some weird part 10 inches away has a 10-inch clearance requirement. If pcb-objects don't have bounding boxes as of now, there's something severly wrong anyway 2. Small parts, like vias, are able to be completely contained within the bounding box - so checking for intersections won't help me A bounding box test as I should have named it consists of several checks, one of which can be intersection. Since traces have finite width in reality one will perform 2 coordinate sorting tests (x and y), then find the closest point on the center line of a trace segment for all 4 corners to see if a corner gets touched and then intersections of the box lines with the centers. The fully included small part will be found by the fact that it's extents (another bbox) are fully included in both coordinate sorting tests, so no further treatment of the bboxes is required but the rigorous geometry intersection is required. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Stefan Salewski wrote: On Mon, 2010-08-16 at 06:12 -0700, Andrew Poelstra wrote: 1. I would have to create bounding boxes for every object on the screen, because you never know if some weird part 10 inches away has a 10-inch clearance requirement. Guess: Make bounding boxes which includes the clearance for each, so all not overlapping boxes fulfill desired clearance? for this subtest, exactly ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Andrew Poelstra wrote: This problem prompted me to suggest redoing the layer selector entirely to clean up the code, which in turn spawned the workspace/functional block discussion. Since you want to do away with the radio buttons left of the layers for activating I suppose you want use left-click for activate (like Kai-Martin every 10th attempt I inadvertently do this anyway). A means to switch visibility must be found: once a right-click popup is assigned to the layer buttons, this would just be one of the properties, until then, how about using right-click or middle-click? Thinking of a way to display the extent of vias (for burried vias) a bar left of the layers showing a bronze color strip connecting the start and end layer makes sense to me. It's similiar to a scrollbar but in reality could consist of simple boxes with changing background color. The active layer could be shown with the corresponding button depressed. Cycling through visibility states can change the button background color: normal ... visible, full saturation darkish grey + bright text . greyed out very dark + bright text .. invisible Getting caught by a fixed start and end layer for vias while routing on a different layer not in that range, it's probably practical to have a setting 'via starts at current layer' - using it may be a tradeoff between manufacturing cost and ease of routing. ( what happens if I want via_1 from layer 2-4 and via_2 from layer 3-5? ok, via_1 probably starts as blind while glueing layer 2,3,4 , 1st metalization, then glueing layer 5 makes via_1 burried, 2nd metalization connects layer 5 with layer 3,4 on via_2 - with multiple drilling, sounds expensive ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Andrew Poelstra wrote: I wanted to copy the GIMP: show icons for visibility/locking as part of the list item, that can be toggled independently of visibility. Right- clicking should pop up a full context menu for creating/editing/deleting layers, geometric transforms, duplicating, etc. As for buried vias, I don't think they should be related to the layer selector at all. I don't like the layer menu of GIMP - it's detached, so I always have to fetch it from below 5 other things before I can use it. If you don't detach it, it's still very wide. I just don't like it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. JG, in my opinion Rick has a point, that without 100% clear definitions from and for all of those talking here using subnet, the whole discussion has a high chance of getting nowhere and some of the usecases brought in for support of the idea seem to come from Wolkenkuckusheim [1] for him. He's never been insulting and I value the practical view of his writing. As he's less writing, he's probably more routing than me - a reproach I'm making to myself - I just write here, to keep the future tool useful to me and found it hard to follow all the discussion. [1] the term is german and some of the ideas look like from there for me (too) e.g. I make my traces as broad as I see fit or have space in the area, so all the cool design auto blahblah means nothing to me, but a minimum clearance based on voltage is a good feature. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Andrew Poelstra wrote: I like this. Since many features on a PCB are traces, which are long and thin, I wonder if we could achieve an even-greater speedup by using bounding ellipses rather than circles. With rounded-up sine tables I think we can do the check nearly as fast as we could with simple circles (will have to check my calc book), and we'd eliminate a -lot- more components in the initial scan. Bounding spheres and -circles are quite common. As DJ indicated pcb already has r-trees implemented (http://en.wikipedia.org/wiki/R-tree). Sorting bounding boxes by their edges and storing the result in 4 or 6 (3D) B+trees is another option. In that case you don't even have to look at most of the objects (O(log n)). An other option is quad trees (oct trees in 3D) that devide the space into non-overlapping segments and allow an object to be part of several nodes. Finding the smallest bounding box that is *not* axis-aligned is a hard problem in general (trivial for a set of 2 circles) with lots of approaches and literature. Finding the smallest ellipse, say with minimum area I think isn't trivial, even for 2 circles. Checking the intersection of circles is fast only, because it can be reduced to the distance of their centers. The best way I can immediately write to check ellipses will involve solving a quadratic equation - requires taking a square root. I'm not quite sure atm but for circles the distance can be squared and the root avoided. For just testing whether the solutions are complex, no actual root taking with quadratic equations is required either. Problem remains to find out when an ellipse is fully inside the other... Spheres have no natural easy way to compute the bounding sphere of aggregates from the spheres of components, therefore they are sometimes used with one of the trees above. This is not to discourage you, just meant as hints. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stephan Boettcher wrote: Stefan Salewski m...@ssalewski.de writes: On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. Using blocks in mechanical CAD has some issues with this. In principle there are 2 ways to use a block: a) copy and paste b) reference Naturally the edit one modify all can only work with referencing. Sometimes in a single construction this is not desired, so when duplicating one has the choice between reference and copy. With mechanical constructions this goes as far as changing the appearance of a referenced block, when when an external block is changed independently. This can be useful, if the interface of the block is well understood. With pcb-layouts I strongly advise against this procedure: if a block gets inserted in a layout, a local copy has to be made (that is positioned nowhere) and references to this comprise the physical instances. Any attempt to modify a block with backpropagation to external data that is used in other boards will almost certainly break those layouts. When modifying a reference/instance of the (local) block one must get asked if opening the block is meant to change all instances or copy on write shall be used. About refdes-usage in this scenario: I find it hard to see an application of a block without using a corresponding sub-schematic. I would btw. like to be able to see only the basename of a refdes on the silk layer if it is made like schematic_name/schematic_local_identifier. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Specification of Rotations for Auto Assembly
Bert Timmerman wrote: The right hand rule says: if you spread your first 3 fingers (starting with thumb) orthogonal to each other, thumb = X, point = Y, middle = Z ( or if you hook your fingers to indicate a rotation that will move X into Y, spreaded thumb poins to Z+). This is the basis for all math definition on vector operations in 2D and 3D, it defines the mathematically positive sense of rotation (CCW from above). All mechanical CAD systems and robotics controls adhere to this. I gave this explanation, why I don't like the CS. It's clear to me that changing it while simple in principle would make files not backwards compatible and is error prone. So to define a rotation consistent with production, the first thing one must do is set up a proper 3D coordinate system. As long as the internal coordinate system of pcb is consistent within the code base, and the proper coordinate system is used for the exporter for each purpose, then why change and have the risk of implementing (new) errors. When it works, don't fix it. Defining a proper 3D coorinate system is sufficient for export filters in conjunction with rotation. It wasn't necessarily meant to change the internal CS of pcb. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Paul Tan wrote: Hi All, We can all agree that the current gEDA(Gschem/Gnetlist) need to accomodate more than just the netname attribute attached to a net. In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. And that Gnetlist front end will present similar functions to the backend Scheme procedures, so that different backends (Verilog, VHDL, Spice, GnuCap, SystemC, PCB, etc) Scheme procedures can decipher net attributes particular to that backend. Note that I stress the ANY word above, because one of the most powerful features of gEDA is its architectural capabilities of supporting ANY attributes as ANY backend dictates. How the symbol and net attributes are handled should be up to the particular backend's Scheme procedure. I am familiar with the gEDA codes (both the C and Scheme). I can see that it is not too difficult to add the ANY net attributes feature., since it fits similar pattern as processing of symbol's ANY attributes. It is on my list of TO DO for gEDA, but we just don't have the time to do it yet. I am hoping someone will beat me to it. Best Regards, Paul Tan agree 100% ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Free software and the GPL
Peter TB Brett wrote: Um, sorry? Are you trying to argue that people who develop libraries and release them under the GPL are trying to have their cake and eat it? I don't see it -- I think you need to explain further. I don't recall anyone holding a gun to your head and forcing you to use GPL libraries. If you don't intend to comply with the license, don't use the code. You have the choice. Are you trying to persuade me that *I* shouldn't release *my* code under the GPL? If so, your arguments are really not having the desired effect. Care to try again? No. I just reserve the right to licese a library that I write with LGPL or BSD and use it in support of software I choose not the licese freely at all. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Commercial CAD, land pattern generators report
al davis wrote: On Saturday 14 August 2010, Armin Faltl wrote: I think I have the following options then: a) fix the bug myself and reinvent your convenience function which is questionable b) re-release my library under LGPL and ask you to resubmit the patch with same license c) open source or shred my application d) contact the author of the patch and ask if it is ok for you to use in your proprietary version. you mean give me a written and signed permission, i.e. a different license, and that for everyone that may contribute something in the future? Licenses is all about lawyers and suing - never ever ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Well, as you suggest below, Groups are essentially a way of tagging different parts, so they would be completely independent of the physical layers - and the connectivity checker. ** Confusingly, PCB already has layer groups, which consist of multiple layers. A layer group is what ends up physically as a plane of copper in your produced board. Your terminology reverses the meaning, with a layer group consisting of logically grouped parts spanning multiple physical layers. I presume you intend to get rid of PCB's existing layer group functionality (good riddance IMO), however it would be less confusing to pick a new name. Perhaps logical group. Yes, absolutely! But I cannot think of a good name :) logical group is too long and ambiguous. Right now I am using Group, but that's even less useful. First I thought functional group would be good, but what you describe - a construct of functional interdependence spread on several layers in mechanical CAD is in many cases called a block or module. The concepts of layers + layer groups (hierarchical layers in mech-CAD) is orthogonal to blocks. E.g. you can turn visibility on and off for each independently. For the sake of visual collision detection in the case of EDA 3 levels of visibilty as suggested may be in order: coloured/saturated, greyed out and invisible. Esp. useful I envision the possibility to grey out blocks one does not work on while they stay visible. Being able to reuse a block independently of the layout it was created it, like in mechanical CAD would be very welcome here as well (did I miss something?) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Doty wrote: On Aug 8, 2010, at 4:51 PM, kai-martin knaak wrote: No it is not. Even simple things like footprint names have a pretty rigid syntax to adhere to. The workflow breaks in cryptic ways if they are not obeyed. This is a pure pcb limitation, not a gEDA limitation in general. Isn't a chain as strong as it's weakest link ? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
