gEDA-user: gschem auto-uref.scm increment behavior
>> Noobie alert << I have just installed from source geda-gaf-1.6.1 on Ubuntu Karmic (using checkinstall). I am having a bit of difficulty getting auto-uref.scm to behave as expected: * When placing parts, refdes values start at 2 and go up by even numbers. * The refdes for copy/pasted parts also take on even values--whether the existing part being copied has an odd or even refdes. My gschemrc is as follows: (log-window "later") ; ;(define default-titleblock "cvstitleblock-1.sym") (define default-titleblock "title-bordered-A3.sym") ; (load (build-path geda-rc-path "gschem-colormap-lightbg")) ; (sort-component-library "enabled") ; (load (build-path geda-rc-path "/scheme/auto-uref.scm")) (add-hook! add-component-hook auto-uref) (add-hook! copy-component-hook auto-uref) Am I doing something stupid or is this normal behavior for auto-uref.scm? -M ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sep 5, 2010, at 6:29 PM, timecop wrote: > On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra wrote: >> On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote: >>> But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. >>> >>> Compression. Either gzip the text file, or use an alternate binary >>> file (smaller *and* faster). >>> >> >> Between the two of those, I think compression is the better option. >> That way there's nothing to keep in sync, external tools and scripts >> simply need to stick a gzip filter on each end, and it's fast. >> >> But I think it should be optional, since if we zip the .pcb files, >> we no longer have simple diffs, which to a lot of people would be >> more important than small files. > > Did you know? > I can name a few modern formats that are .zip and have no problems. > examples: > Office 2010 .docx/xlsx/etc > OpenOffice files > Android apk > Java .jar > A number of closed-source windows games > etc. > > wahh wahh, i cant zip shit wa wahh,, make it a clickable options > in preferences and those who "diff" their PCB designs are welcome to > keep them uncompressed First grow up, you are the one crying And here is the solution for making the version control with git understand a zipped pcb file. http://the-gay-bar.com/2010/06/23/managing-zip-based-file-formats-in-git/ In summary you tell git that to diff the file it needs to me unzipped first. Steve > >> >> >> 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra wrote: > On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote: >> >> > But when each parameter in the file has a name, than file size may >> > become really large, e.g. for files generated with the topological >> > router, with lot of arcs. >> >> Compression. Either gzip the text file, or use an alternate binary >> file (smaller *and* faster). >> > > Between the two of those, I think compression is the better option. > That way there's nothing to keep in sync, external tools and scripts > simply need to stick a gzip filter on each end, and it's fast. > > But I think it should be optional, since if we zip the .pcb files, > we no longer have simple diffs, which to a lot of people would be > more important than small files. Did you know? I can name a few modern formats that are .zip and have no problems. examples: Office 2010 .docx/xlsx/etc OpenOffice files Android apk Java .jar A number of closed-source windows games etc. wahh wahh, i cant zip shit wa wahh,, make it a clickable options in preferences and those who "diff" their PCB designs are welcome to keep them uncompressed > > > 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 format wishlist
On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote: > > > But when each parameter in the file has a name, than file size may > > become really large, e.g. for files generated with the topological > > router, with lot of arcs. > > Compression. Either gzip the text file, or use an alternate binary > file (smaller *and* faster). > Between the two of those, I think compression is the better option. That way there's nothing to keep in sync, external tools and scripts simply need to stick a gzip filter on each end, and it's fast. But I think it should be optional, since if we zip the .pcb files, we no longer have simple diffs, which to a lot of people would be more important than small files. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sun, Sep 5, 2010 at 2:19 PM, Peter Clifton <[1]pc...@cam.ac.uk> wrote: On Sun, 2010-09-05 at 00:18 +0200, Levente Kovacs wrote: > On Sat, 4 Sep 2010 11:24:38 + > Ineiev <[2]ine...@gmail.com> wrote: > > > Probably this patch may be used as a workaround. > > Why don't we just push this patch to HEAD? This works just great. One minor nit.. I'd keep the "non-copper" / "skip-drc" ideas separate. We might (at some point) have DRC rules for non-copper layers (not that I can think of them at the moment, perhaps apart from silk layer(s)). Otherwise, seems good. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user If PCB had the concept of a part/element body outline layer (separate from the silk), it could be used as a guide for part placement, not interfere with pads like the silk would, and could be checked with the DRC. Another vote for general, non-copper layers I guess. Joe T. References 1. mailto:pc...@cam.ac.uk 2. mailto:ine...@gmail.com 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
> But when each parameter in the file has a name, than file size may > become really large, e.g. for files generated with the topological > router, with lot of arcs. Compression. Either gzip the text file, or use an alternate binary file (smaller *and* faster). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
> > We are NOT going with another position-determines-meaning file format.
>
> Why?
Consider the parser for the PIN object:
Pin [rX rY Thickness Clearance Mask Drill "Name" "Number" SFlags]
Pin (rX rY Thickness Clearance Mask Drill "Name" "Number" NFlags)
Pin (aX aY Thickness Drill "Name" "Number" NFlags)
Pin (aX aY Thickness Drill "Name" NFlags)
Pin (aX aY Thickness "Name" NFlags)
The parser only sees the syntax, not the semantics:
pin_hi_format
: T_PIN '[' NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER STRING
STRING flags ']'
pin_1.7_format
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER STRING STRING NUMBER ')'
pin_1.6.3_format
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER STRING NUMBER ')'
pin_newformat
: T_PIN '(' NUMBER NUMBER NUMBER STRING NUMBER ')'
pin_oldformat
: T_PIN '(' NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER STRING
STRING NUMBER ')'
What happens if I want to add another parameter?
___
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
On Sat, Sep 04, 2010 at 12:17:15PM -0400, DJ Delorie wrote: > > > But suppose the user creates a rule like, "all traces on Layer 3 must > > be at least 5mm apart", and then saves the file and reloads it. Now the > > information about what traces are affected is lost, except that all the > > traces on Layer 3 are coincedentally tagged with the rule. > > > > What if the user then decides he wants the rule to apply to Layer 4 > > instead? > > In that specific case, we could apply rules to layers as well as > objects, but I see your point. > > Unfortunately, the math behind DRC is expensive, so generalizing the > rules needs to mesh well with doing the math only once. > I'm not sure that storing DRC rules as filters (rather than tagging data) would slow things down significantly. Internally, we could still maintain a tag structure. We would need to keep it in sync when adding or removing components or rules, of course, and when loading .pcb files. But when running the DRC, there would be no cost to storing the rules this way. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
Peter Clifton wrote: > What is useful is that the "outline" / "route" titled layers don't > get pads flashed on them when exporting gerbers. All other (copper) > layers get the pads on them, which would be a problem for an > outline plot. Apparently not for my preferred fab. When asked, they told me that pads on the outline are no problem to them. They cut the pcb at places where the gerber asks for copper. For some projects I needed copper at the very edge of the PCB. So I had to ignore the corresponding DRC errors. Conclusion: I'd like to have the outline layer ignored by DRC, too. ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sat, 2010-09-04 at 22:56 +0200, Pawel Kusmierski wrote: > On Sat, Sep 4, 2010 at 1:11 PM, Peter Clifton wrote: > > As a kludge, call your layer by one of the magic names "outline" or > > "route" and it will be ignored by the DRC, and treated as non-copper. > > > > Peter, thanks for the tip. > I may be doing something wrong, but even following the tips at > http://www.geda.seul.org/wiki/geda:pcb_tips#how_do_i_make_a_board_outline_to_go_with_my_gerbers_to_the_board_maker > the outline layer still connects my vias together. Hmm, so it does.. sorry, it appears the DRC check isn't disabled for the "outline" layer. What is useful is that the "outline" / "route" titled layers don't get pads flashed on them when exporting gerbers. All other (copper) layers get the pads on them, which would be a problem for an outline plot. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sun, 2010-09-05 at 00:18 +0200, Levente Kovacs wrote: > On Sat, 4 Sep 2010 11:24:38 + > Ineiev wrote: > > > Probably this patch may be used as a workaround. > > Why don't we just push this patch to HEAD? This works just great. One minor nit.. I'd keep the "non-copper" / "skip-drc" ideas separate. We might (at some point) have DRC rules for non-copper layers (not that I can think of them at the moment, perhaps apart from silk layer(s)). Otherwise, seems good. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, Sep 05, 2010 at 10:01:47PM +0200, Stefan Salewski wrote: > > But when each parameter in the file has a name, than file size may > become really large, e.g. for files generated with the topological > router, with lot of arcs. > If every parameter had a name like 'x', 'y', 'w', 'h', 'r', it will be clear what they mean, but still not take up too much room. Certainly compared to the space wasted storing every number to 8 decimal places (or whatever we do), the bloat is worth it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 21:56 +0200, kai-martin knaak wrote: > Stefan Salewski wrote: > > > One disadvantage of that format may be: > > We have lines starting with a letter followed by up to 16 decimal > > numbers -- hand editing such lines may be difficult. Not a problem for > > me, I do not intend hand editing. > > More precisely: Positional parameters are bad. > Mapping position to meaning makes it hard to add additional parameters > anywhere but at the end. Structured data does not easily fit easily. It is > next to impossible to throw meaningful errors if values are in the wrong > order. Instead, the error likely goes unnoticed on read and can produce > havoc at unsuspected places further down the flow. > > This is not a matter of style, but a major flaw. > It is the very reason why a completely new format for pcb might be worth the > effort. > Yes, I agree. But when each parameter in the file has a name, than file size may become really large, e.g. for files generated with the topological router, with lot of arcs. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Stefan Salewski wrote: > One disadvantage of that format may be: > We have lines starting with a letter followed by up to 16 decimal > numbers -- hand editing such lines may be difficult. Not a problem for > me, I do not intend hand editing. More precisely: Positional parameters are bad. Mapping position to meaning makes it hard to add additional parameters anywhere but at the end. Structured data does not easily fit easily. It is next to impossible to throw meaningful errors if values are in the wrong order. Instead, the error likely goes unnoticed on read and can produce havoc at unsuspected places further down the flow. This is not a matter of style, but a major flaw. It is the very reason why a completely new format for pcb might be worth the effort. ---<)kaiamrtin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, Sep 05, 2010 at 07:22:14PM +0200, Stefan Salewski wrote: > On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote: > > > We have lines starting with a letter followed by up to 16 decimal > > > numbers > > > > We are NOT going with another position-determines-meaning file format. > > > > > > Why? > > Is manually editing the only reason? > I guess data in most files on our computer hard disc is position > dependent. Will PCB program still work fine if we insert or delete a few > bytes in the executable? > It's because it's inflexible and unintuitive. True, most data on the hard disk is position dependent, but between the hard disk, the kernel and the filesystem driver, we never need to think about it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Sun, Sep 5, 2010 at 6:42 AM, Ineiev wrote: > On 9/4/10, DJ Delorie wrote: >>> Ineiev, thanks for the patch, it applied fine. However, I'm unable to find >>> the >>> (Edit->Edit attributes of->Current Layer). Is it placed somewhere else, >>> or can I manually edit the .pcb file for the same result? >>> I'm using pcb source tree from git, version 1.99z. >> >> Do you have a local ~/.pcb/gpcb-menu.res or something? Nope, I even removed ~/.pcb to be sure it's not interfering. >> The .pcb file format is documented in the doc/pcb.pdf generated file, >> including the Attributes() syntax. Thanks DJ, this proved helpful. > In case your gpcb-menu.res lacks this item, > you can issue the action through (Window->Command entry), > the command is 'Attributes(Layer)'. > > Hope that helps Ineiev, that's a real life saver! It does exactly what I wanted. Thanks a million. Any chance it will make it's way to "production" in some place like File->Preferences->Layers? Kind regards, -- Paweł Kuśmierski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote: > > We have lines starting with a letter followed by up to 16 decimal > > numbers > > We are NOT going with another position-determines-meaning file format. > > Why? Is manually editing the only reason? I guess data in most files on our computer hard disc is position dependent. Will PCB program still work fine if we insert or delete a few bytes in the executable? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote: > > We have lines starting with a letter followed by up to 16 decimal > > numbers > > We are NOT going with another position-determines-meaning file format. May I suggest that while deciding on a file format and choosing how it will work it would be good to consider the diffs that will be generated when managing a projecting using an SCM. I have thought about this a little bit and it does seem like it'll never be possible to make it amazing but I'm sure improvements over the current format can be made. It would be great to be able to look at a diff and instantly see that a component was moved or that a few traces were moved from one layer to another. At the moment even the smallest of changes creates large and complicated diffs, sometimes with lots of unrelated changes. An example of this can be seen at [1] where a single footprint was moved from one side of the board to the other. The commit message is fine for saying what has changed but it's important to be able to review changes made before committing. Thanks, Richard [1] https://www.studentrobotics.org/cgit/boards/power-hw.git/commit/?id=70118c54cf0ffe6ec6a1e98ff2d8207675d95645 ___ 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
On Sat, Sep 04, 2010 at 07:49:06PM -0700, Steven Michalske wrote: > > This is why I use yaml to store data. It was designed to be human > readable. It holds most high level data structures. And is very > low bloat. You can tag the yam code to say that this is a particular > data structure, like a footprint or via > > It allows for references. So all vias of a type could point to the > same data and then we only would have to change one data structure > to change all of the vias with the same tag. > > There is a c library libyaml. > > And many other languages have libraries, perl python ruby and many > more. Although I did not see an official lisp library. > I've glanced through the YAML wikipedia page and it looks pretty good. I'd vote for it, anyway. > But before we pick a file format we need to decide what we want to > store. And then choosing how we want to store it. > I'm not sure this is true. We know what we need to store in a vague sense - traces and components, footprints and layers, DRC rules and netlists. Any decently-extensible language should let us add things as needed. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
> We have lines starting with a letter followed by up to 16 decimal > numbers We are NOT going with another position-determines-meaning file format. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Stefan Salewski writes: > On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote: >> All of this discussion of formats misses the shining example that's >> already in gEDA: the schematic format. > > Yes. Recently I begun studying that format and started writing a parser > in Ruby -- really easy. > > One disadvantage of that format may be: > We have lines starting with a letter followed by up to 16 decimal > numbers -- hand editing such lines may be difficult. Not a problem for > me, I do not intend hand editing. Yes, the gschem file format is much less accessible for hand/awk/sed-editing than the pcb file format. I would not like that to change - on the pcb side. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, Sep 05, 2010 at 05:47:12PM +0200, Stefan Salewski wrote: > > One disadvantage of that format may be: > We have lines starting with a letter followed by up to 16 decimal > numbers -- hand editing such lines may be difficult. Not a problem for > me, I do not intend hand editing. > Sounds like a job for awk. Andrew ___ 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
Hi Bob, > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Bob Paddock > Sent: Sunday, September 05, 2010 1:24 PM > To: gEDA user mailing list > Subject: Re: gEDA-user: Functional blocks and PCB format changes > > IMHO, the "problem" with XML lies not in the bloat, even > a factor 10 larger > would be acceptable, it's the <$TAGS> that have to be > identical across all > applications to have a "truly" exchangeable XML file. > > > http://www.ibm.com/developerworks/xml/ XML can be easy or > hard, big or small, depending on the task at hand. > > Specifically related to this discussion is this: > > "Create a maintainable extensible XML format Reduce change > when you design XML formats agile enough to incorporate new > requirements" > > http://www.ibm.com/developerworks/library/x-extensxml.html > > The problems described there are not specific to XML formats. > > XML gives us the ability to interact with other tools. JSON > gives smaller file format, with Lots of Irritating Silly > Parentheses. YAML gives flexibility, with small file size. > SVG lets us layout boards in our browser (I've actually > wanted to do that due to restrictive IT policies on what > software can be installed and used). The 'What' of a > requirement document is more important than the 'How'. No > reason at all that there can not be multiple file formats, > *if* things are specified well. > > We all have many wishes, with a fixed amount of time to > allocate to our lives, unless we make time to code things > we'll be spending time on wishes and still be where we > started in the end. "The Devil's weapon of choice today, is > distraction from our goals in life." > I think we are (hopefully) on the same page. Let's keep what we already have: pcb's internal engine, maybe some day to be metrified and an extended and improved file format to be fit for the future. To me XML would be an intermediate file, used to exchange data, the same purpose an IDF file would have. Reinventing the XML wheel would take more effort for us and other parties, someone would have to think-up a XSD schema. The IDF format is well defined, version 4.0 so the big issues should be solved, some mechanical 3D CAD vendors (mainstream) have picked up the format as hae some big EDA players. The "worst" thing that could happen is someone writing a plug-in or an exporter for either XML or IDF ;-) The same goes for a IPC-356 compliant test point data exporter, a DXF import plug-in, a DXF exporter and the list goes on and on. Too much ideas and sparse free time. Just my EUR 0.02 Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote: > All of this discussion of formats misses the shining example that's > already in gEDA: the schematic format. Yes. Recently I begun studying that format and started writing a parser in Ruby -- really easy. One disadvantage of that format may be: We have lines starting with a letter followed by up to 16 decimal numbers -- hand editing such lines may be difficult. Not a problem for me, I do not intend hand editing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
All of this discussion of formats misses the shining example that's already in gEDA: the schematic format. Now *there's* a work of genius. 1. The format is based on a small, well-chosen set of elementary objects. 2. Elementary objects are represented by one-line tagged records of fixed format (identified by the tag). Almost any tool you might want to use can easily process a file of this sort without the need of any special library. 3. A set of objects can be attached to any abject. This can be in principle extended to unlimited depth. 4. Multi-line text objects are supported. There are few restrictions on the content of a text object. (1) and (2) make the format easy to process with simple tools. (3) and (4) constitute an infinitely flexible escape hatch, although we're not using it to its full capability (but a single level of attached attributes is pretty good). A good file format for this sort of thing avoids definitions for high level concepts. It provides mechanisms to compose high level objects from low level primitives. So, the question here starts with "what are the primitives that one constructs printed circuit board descriptions from?" John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
Hi,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Ethan Swint
> Sent: Sunday, September 05, 2010 4:06 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: PCB format wishlist
>
> On 09/04/2010 10:19 PM, Andrew Poelstra wrote:
> > I have one more suggestion: the facility to create recursive PCBs.
> > What this will look like in the file format, I dunno. But we should
> > keep it in mind.
> >
> Recursive PCBs could work the same way as the footprint
> re-use: a node could contain a reference to a parent node;
> the parent node could be a single element or itself a
> reference to a collection of elements.
>
>
+1
I can think of a "group" of {traces, vias, elements, silk text or lines} to
be linked in from an external file or to be embedded.
The analogy of embedded/unembedded symbols in gschem comes to mind.
I never have applied symbols recursively though (symbols within symbols
within symbols), other than in the form of hierarchical multisheet
schematics (symbols pointing to schematics containing symbols, pointing to
schematics containing symbols, etc.
Kind regards,
Bert Timmerman.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/04/2010 10:19 PM, Andrew Poelstra wrote: I have one more suggestion: the facility to create recursive PCBs. What this will look like in the file format, I dunno. But we should keep it in mind. Recursive PCBs could work the same way as the footprint re-use: a node could contain a reference to a parent node; the parent node could be a single element or itself a reference to a collection of elements. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB format wishlist
On 09/04/2010 10:04 PM, Andrew Poelstra wrote: 3) Connectivity information: include the connection information between line segments, similar to (but not necessarily exactly!) SVG format, where multiple points and arcs can be included in one line. I'm not sure what you're getting at here. I think the rule of least surprise dictates that line segments be line segments, since that is how they are manipulated. If you are familiar with mechanical CAD packages, they would be called 'polylines': connected line segments/arcs which otherwise have the same characteristics. I often find myself editing the PCB file in a text editor and it's a real pain to find connected traces, as they are scattered over the entire file. 5) Ability to lock any portion of the location coordinate, either in absolute or relative to another entity (line segment locked to pin/pad, components locked to the same Y coordinate, etc) - rather than just specifying an absolute coordinate. More generally, we should support creating "groups" of components that can be transformed and manipulated as a collection. However, I'm not sure how much functionality this would give on top of the functional-block proposal. This idea encompasses a component group: the XYRS data of each of these components would be locked to a 'base' component. When the base component is moved, all of the components are moved. ___ 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
IMHO, the "problem" with XML lies not in the bloat, even a factor 10 larger would be acceptable, it's the <$TAGS> that have to be identical across all applications to have a "truly" exchangeable XML file. [1]http://www.ibm.com/developerworks/xml/ XML can be easy or hard, big or small, depending on the task at hand. Specifically related to this discussion is this: "Create a maintainable extensible XML format Reduce change when you design XML formats agile enough to incorporate new requirements" [2]http://www.ibm.com/developerworks/library/x-extensxml.html The problems described there are not specific to XML formats. XML gives us the ability to interact with other tools. JSON gives smaller file format, with Lots of Irritating Silly Parentheses. YAML gives flexibility, with small file size. SVG lets us layout boards in our browser (I've actually wanted to do that due to restrictive IT policies on what software can be installed and used). The 'What' of a requirement document is more important than the 'How'. No reason at all that there can not be multiple file formats, *if* things are specified well. We all have many wishes, with a fixed amount of time to allocate to our lives, unless we make time to code things we'll be spending time on wishes and still be where we started in the end. "The Devil's weapon of choice today, is distraction from our goals in life." Here is my Wish List of sorts: Anyone ever consider the heretical idea of tossing it all and start over fresh? Lets us get things like hard-metric options as the first thing that came to mind. There are many external libraries today, for examples many from the Boost and wxWdigets domains, that make that idea easier than in the past, see below for the easy stuff. The hard part is the domain specific stuff, that few of us understand berried in 20+ years of accumulated poorly commented cruft. DJ is there any hope of creating a library of the domain specific stuff? For the easy stuff, as long as we don't have a "Not Invented Here" complex or "external dependencies make it hard to build" [3]et.al. problems (reinventing the wheel just takes valuable development time to make a lot of incompatible wheels): Polygon library: Booleans/clipping, resizing/offsetting and more for planar polygons with integral coordinates. [4]http://www.boost.org/doc/libs/1_44_0/libs/polygon/doc/index.htm Interprocess: handling to Schematics for real time interaction. [5]http://www.boost.org/doc/libs/release/doc/html/interprocess.html Quaternion Math: Gets around accumulating errors when rotating objects in six-degrees-of-freedom (See Stewart Platforms), when we go 3D someday. [6]http://www.boost.org/doc/libs/release/libs/math/doc/quaternion/html/ index.html MPI: Message Passing Interface library, for use in distributed-memory parallel application programming, for that 1000 layer board (that no one could ever build, lets be realistic in requirements). [7]http://www.boost.org/doc/libs/release/doc/html/mpi.html Parameter Library: Write functions that accept arguments by name. [8]http://www.boost.org/doc/libs/release/libs/parameter/doc/html/index. html Program Options: The program_options library allows program developers to obtain program options, that is (name, value) pairs from the user, via conventional methods such as command line and config file, environment variables. [9]http://www.boost.org/doc/libs/release/doc/html/program_options.html Property Tree: A tree data structure especially suited to storing configuration data. [10]http://www.boost.org/doc/libs/release/libs/property_tree/index.html Pyton (for scripting): The Boost Python Library is a framework for interfacing Python and C++. It allows you to quickly and seamlessly expose C++ classes functions and objects to Python, and vice-versa, using no special tools -- just your C++ compiler. I'd do something with Lua myself actually, see below. [11]http://www.boost.org/doc/libs/release/libs/python/doc/index.html Signals2: Managed signals and slots callback implementation (thread-safe version 2), for plug-in implementations. [12]http://www.boost.org/doc/libs/release/libs/signals2/ System: Operating system support, including the diagnostics support that will be part of the C++0x standard library. [13]http://www.boost.org/doc/libs/release/libs/system/doc/index.html Boost also has several Smart Pointers, several Parsers, Exception handling, Threads and other techniques to make robust code. See the whole list here: [14]http://www.boost.org/doc/libs/ For the GUI I'd use wxWidgets [15]http://www.wxwidgets.org/ which in time will run on your iWhatsit, and does run on PC, Mac, Unix [16]et.al, today. Use OpenGL for the machines with the power to use it where 'expen
Re: gEDA-user: Functional blocks and PCB format changes
Hi, There happens to be a newer version (1998) of the IDF specification: http://www.simplifiedsolutionsinc.com/images/idf_v40_spec.pdf Kind regards, Bert Timmerman > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Bert Timmerman > Sent: Sunday, September 05, 2010 11:13 AM > To: 'gEDA user mailing list' > Subject: Re: gEDA-user: Functional blocks and PCB format changes > > Hi Rick, > > > -Original Message- > > From: geda-user-boun...@moria.seul.org > > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins > > Sent: Sunday, September 05, 2010 12:38 AM > > To: gEDA user mailing list > > Subject: Re: gEDA-user: Functional blocks and PCB format changes > > > > At 11:49 AM 9/4/2010, you wrote: > > >On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: > > > > > > > > Don't hold back, tell us how you really feel! > > > > > > > > The spec is large because it addresses a wide range of design > > > > aspects, which is one of the great reasons for using > it, one file > > > > for the entire design, schematic, layout, mechanical, etc, even > > > > board lay up. So the compatibility issue is moot > because any one > > > > app only needs to deal with the portion that applies to > it. Just > > > > don't muck with the other parts. > > > > > > > > The "heavy" issue is a red herring (are you planning on > > hosting this > > > > on a cell phone maybe?) No PCB file format is going to > > be easy for > > > > humans to read. Bandwidth? Back to the MCU in the > cell phone I > > > > guess. "Ugly", now there is a great technical argument. > > > > > > > > But I suppose it is better to re-invent the wheel. There is no > > > > reason to try to foster any sort of compatibility in > file formats > > > > between all the different CAD tools. There are always > conversion > > > > programs to be written, no? > > > > > > > > > >This is not an emotional argument, but a technical one, and > > the choice > > >is not between XML and reinventing the wheel. (Sadly, my Lisp > > >suggestion has been shot down - by better arguments than > > popularity, I > > >might add. ;) There are other formats to consider, and yes, > > inventing > > >one might be an option. > > > > > >How do you know PCB won't ever run on cell phones, or over a slow > > >network link, or on an embedded device or network PC or overtaxed > > >virtual machine? How do you know we won't one day need to > work with > > >1000-layer boards when suddenly it /does/ matter how heavy > the file > > >format is? > > > > So are you suggesting that we should, at this time, plan > for running > > PCB on a cell phone? Do you want to design PCB to work on > overtaxed > > virtual machines, if so, I expect there will be a lot more > important > > things to optimize than the file format which only impacts the > > performance when reading or saving the file. If we need to > work with > > 1000 layer boards, I expect we would have computers which > would be not > > at all burdened by XML file formats. > > > > I'm trying to be realistic about the requirements. I think > that the > > 2x or 3x factor of file size of using something like XML > would be lost > > in the noise. The advantages of working with an industry standard > > file format could be very large. > > Of course as you or someone pointed out, IPC-2511B is not a well > > established format. But to my knowledge it is the only one > that spans > > most if not all aspects of circuit board manufacturing. It > seems like > > a great idea to work with something this useful and I am > pretty sure > > that concerns with using it can be ironed out. > > > > > > >Unless you want feature-parity with other CAD programs, it is > > >impossible to have file-format-parity. So no matter what, > conversion > > >programs will have to be written. Creating similar file > > formats won't > > >help anything, other than to limit our own format, and potentially > > >cause problems if PCB and another CAD program are able to open (and > > >corrupt) each other's files. > > > > I don't agree that a common file format has to be > restrictive. If the > > file format is flexible enough, the program won't be limited. > > Everything doesn't have to be included from the start. I > don't know > > if IPC-2511B is flexible enough for PCB and future ideas > for PCB, but > > using XML I expect it can be expanded easily. I don't think anyone > > here has really looked hard at it. It may well be extensible. I > > don't know. But I would like to at least consider it and > not toss it > > away without giving it a chance. > > > > Rick > > > > > > IMHO, the "problem" with XML lies not in the bloat, even a > factor 10 larger would be acceptable, it's the <$TAGS> that > have to be identical across all applications to have a > "truly" exchangable XML file. > > I think that for an excha
Re: gEDA-user: Functional blocks and PCB format changes
Hi Rick, > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins > Sent: Sunday, September 05, 2010 12:38 AM > To: gEDA user mailing list > Subject: Re: gEDA-user: Functional blocks and PCB format changes > > At 11:49 AM 9/4/2010, you wrote: > >On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: > > > > > > Don't hold back, tell us how you really feel! > > > > > > The spec is large because it addresses a wide range of design > > > aspects, which is one of the great reasons for using it, one file > > > for the entire design, schematic, layout, mechanical, etc, even > > > board lay up. So the compatibility issue is moot because any one > > > app only needs to deal with the portion that applies to it. Just > > > don't muck with the other parts. > > > > > > The "heavy" issue is a red herring (are you planning on > hosting this > > > on a cell phone maybe?) No PCB file format is going to > be easy for > > > humans to read. Bandwidth? Back to the MCU in the cell phone I > > > guess. "Ugly", now there is a great technical argument. > > > > > > But I suppose it is better to re-invent the wheel. There is no > > > reason to try to foster any sort of compatibility in file formats > > > between all the different CAD tools. There are always conversion > > > programs to be written, no? > > > > > > >This is not an emotional argument, but a technical one, and > the choice > >is not between XML and reinventing the wheel. (Sadly, my Lisp > >suggestion has been shot down - by better arguments than > popularity, I > >might add. ;) There are other formats to consider, and yes, > inventing > >one might be an option. > > > >How do you know PCB won't ever run on cell phones, or over a slow > >network link, or on an embedded device or network PC or overtaxed > >virtual machine? How do you know we won't one day need to work with > >1000-layer boards when suddenly it /does/ matter how heavy the file > >format is? > > So are you suggesting that we should, at this time, plan for > running PCB on a cell phone? Do you want to design PCB to > work on overtaxed virtual machines, if so, I expect there > will be a lot more important things to optimize than the file > format which only impacts the performance when reading or > saving the file. If we need to work with 1000 layer boards, > I expect we would have computers which would be not at all > burdened by XML file formats. > > I'm trying to be realistic about the requirements. I think > that the 2x or 3x factor of file size of using something like > XML would be lost in the noise. The advantages of working > with an industry standard file format could be very large. > Of course as you or someone pointed out, IPC-2511B is not a > well established format. But to my knowledge it is the only > one that spans most if not all aspects of circuit board > manufacturing. It seems like a great idea to work with > something this useful and I am pretty sure that concerns with > using it can be ironed out. > > > >Unless you want feature-parity with other CAD programs, it is > >impossible to have file-format-parity. So no matter what, conversion > >programs will have to be written. Creating similar file > formats won't > >help anything, other than to limit our own format, and potentially > >cause problems if PCB and another CAD program are able to open (and > >corrupt) each other's files. > > I don't agree that a common file format has to be > restrictive. If the file format is flexible enough, the > program won't be limited. Everything doesn't have to be > included from the start. I don't know if IPC-2511B is > flexible enough for PCB and future ideas for PCB, but using > XML I expect it can be expanded easily. I don't think anyone > here has really looked hard at it. It may well be > extensible. I don't know. But I would like to at least > consider it and not toss it away without giving it a chance. > > Rick > > IMHO, the "problem" with XML lies not in the bloat, even a factor 10 larger would be acceptable, it's the <$TAGS> that have to be identical across all applications to have a "truly" exchangable XML file. I think that for an exchangable format for schematic capture, pcb layout __and__ 3D mechanical CAD stuff the "problem" is waaay to big to grasp in a forthnight and DIY. And there happens to be a standard of sorts which does just that, named IDF, some of the large commercial CAD vendors play this game already. In this playfield design files with 1MB < size < 10MB is not that uncommon these days. Welcome in "Utopia" mate ;-) Have a look at: http://www.simplifiedsolutionsinc.com/images/idf_v40_overview.pdf http://www.protel.com/files/training/Module%2020%20-%203D%20Mechanical%20CAD .pdf http://www.simplifiedsolutionsinc.com/images/idf_v30_spec.pdf Happy reading ;-) Kind regards, Bert Timmerman __
Re: gEDA-user: PCB DRC arcs (was: Functional blocks...)
On 9/4/10, Windell H. Oskay wrote:
>>
>> On Sep 4, 2010, at 4:30 AM, Ineiev wrote:
>>
>>> Hello, DJ;
>>>
>>> On 9/4/10, DJ Delorie wrote:
Our DRC engine could use a complete rewrite. It doesn't get arcs
right, for example.
>>>
>>> Could you elaborate on the arcs, please? what it doesn't do?
>>
>> I've been running into trouble with the DRC and arcs, myself. I
>> discovered it when doing some simple tests of the toporouter-- certain
>> arcs produce DRC errors when there clearly is none-- says that there isn't
>> 10 mils of clearance when there obviously is much more than that.
>
> Doh! Bad link. Correct one is:
> http://evilmadscientist.com/source/temp/topo_puzzle.pcb
Thank you! arguably it is not the arc, it's the squared pin.
Cheers,
Ineiev
diff --git a/src/find.c b/src/find.c
index 593be70..f340962 100644
--- a/src/find.c
+++ b/src/find.c
@@ -149,8 +149,8 @@ RCSID ("$Id$");
#define IS_PV_ON_ARC(PV, Arc) \
(TEST_FLAG(SQUAREFLAG, (PV)) ? \
IsArcInRectangle( \
- (PV)->X -MAX(((PV)->Thickness+1)/2 +Bloat,0), (PV)->Y -MAX(((PV)->Thickness+1)/2 +Bloat,0), \
- (PV)->X +MAX(((PV)->Thickness+1)/2 +Bloat,0), (PV)->Y +MAX(((PV)->Thickness+1)/2 +Bloat,0), \
+ (PV)->X -MAX(((PV)->Thickness+1)/2,0), (PV)->Y -MAX(((PV)->Thickness+1)/2,0), \
+ (PV)->X +MAX(((PV)->Thickness+1)/2,0), (PV)->Y +MAX(((PV)->Thickness+1)/2,0), \
(Arc)) : \
IsPointOnArc((PV)->X,(PV)->Y,MAX((PV)->Thickness/2.0 + fBloat,0.0), (Arc)))
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
