Re: gEDA-user: GPLv3 question
On 10/7/10, DJ Delorie d...@delorie.com wrote: Cross-compiler is not a component of the operating system on which the executable runs. Nearly every embedded OS comes *with* a cross compiler. It just doesn't happen to run *on* the embedded OS. One could argue that such a cross compiler is a component of the embedded OS. Most probably, yes, when somebody supplies the toolchain; do you think one also could argue when nobody does? Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
Most probably, yes, when somebody supplies the toolchain; do you think one also could argue when nobody does? It wouldn't be a major component of the operating system then. For gcc, though, the FSF themselves supply many embedded toolchains... ___ 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
On Thu, Oct 07, 2010 at 04:23:34PM -0700, Andrew Poelstra wrote: On Fri, Oct 08, 2010 at 01:00:50AM +0200, kai-martin knaak wrote: I prefer 1 mm, sometimes 0.5 mm :-) (Are there any plans to make inside pcb metric?) I would vote for this. +1 Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. Besides that, the vast majority of the packages I use are defined in metric dimensions (1mm BGA, 0.65mm TSSOP, 0.5mm QFN). There are some still defined in inch but they have too few pins (=8) to matter. (But no, not that I've heard.) Neither. Gabriel ___ 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
On Thu, Oct 07, 2010 at 04:48:37PM -0700, Andrew Poelstra wrote: On Thu, Oct 07, 2010 at 05:37:48PM -0600, John Doty wrote: On Oct 7, 2010, at 5:00 PM, kai-martin knaak wrote: (Are there any plans to make inside pcb metric?) A couple of years ago I suggested making the fundamental units nanometers, since that would make decimal fractions of inches exactly representable as integers down to 0.01 mil. 0.01 mil = 254 nm by definition. Even on a 32-bit system, this would allow 4-meter boards, unless I'm going crazy. So if anyone has the tenacity to actually switch the units, this seems like a better idea than millimeters. Besides that 64 bit have become commonplace now. You really need signed integers in some places, and there boards which are larger than 2 meters (for some antennas AFAIK). I think that it should have done when switching from mil to finer units. 0.01 mil is 254nm, and using 2nm (exactly 127 times finer) as an unit does not sound right. On the other hand, 1mil was 25.4µm so 100nm would have worked. Unless you wanted to design chips with PCB (you don't want, use the right tool for the job). Gabriel ___ 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
On Fri, Oct 8, 2010 at 5:46 PM, Armin Faltl armin.fa...@aon.at wrote: Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range I don't know, if pcb really uses fix-point arithmetics, but even if not a reasonable internal unit has some importance. AFAIK with floating point, the average internal number should be around 1. HTH, Armin No floating point, all integer to avoid rounding errors. DJ, are the pcb units still wrapped in the accessor macros for converting between internal representation and real world values? If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Now for conversion errors, are you really seeing errors in your metric PCBs? As far as I am concirned the internal unit is meaningless provided it is fine enough. I know no fab house that is going to have a tolerance as good as 254nm or .01mil So as far as it matters in the real world, getting other things done in pcb is much more important, than a conversion to metric base units. meaning proposing that we make PCB 64 bit and nanometers is redicolus. We will double our ram usage and not gain ANY benifits. And to think this started out cause I suggested to use a really corse grid to start layouts, and keep things pretty. Use metric if your primarally using metric parts and use mils if your using inch defined parts. Chances are that people arn't placing their parts by snapping to pin one to move it on grid when placing anyhow. BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. Steve ___ 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
On Fri, 2010-10-08 at 18:31 +0800, Steven Michalske wrote: Now for conversion errors, are you really seeing errors in your metric PCBs? Sure -- there was a long discussion started by me two years ago. With mm grid we sometimes get 0.01mil garbage segments when we do diagonal lines. There was an explanation by DJ, it may be due to the fact that length of the diagonal is not ... Sorry, will stop before writing nonsense. See http://archives.seul.org/geda/user/Nov-2008/msg00425.html That 0.01mil garbage segments is for me an indication for not really good design/programming -- if I had seen that during first testing of PCB, maybe I never started using 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
At 06:31 AM 10/8/2010, you wrote: On Fri, Oct 8, 2010 at 5:46 PM, Armin Faltl armin.fa...@aon.at wrote: Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range The point is that using 1 nm allows both metric and inch coordinates to be represented without introducing errors. Working in units of 0.01 mil does not allow metric to be expressed without rounding error. This error may show up in most designs, but if a consideration is to allow boards larger than 2 meters across, I would think that the possibility of rounding error for metric measurements accumulating to a significant error could be a problem. I don't know, if pcb really uses fix-point arithmetics, but even if not a reasonable internal unit has some importance. AFAIK with floating point, the average internal number should be around 1. HTH, Armin No floating point, all integer to avoid rounding errors. DJ, are the pcb units still wrapped in the accessor macros for converting between internal representation and real world values? If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Now for conversion errors, are you really seeing errors in your metric PCBs? As far as I am concirned the internal unit is meaningless provided it is fine enough. I know no fab house that is going to have a tolerance as good as 254nm or .01mil That is not the concern. The problem is that on input a metric value will have a rounding error. When that error is compounded by the arithmetic (for example accumulative error in a large connector or chip pin spacing) the final error can become significant. So as far as it matters in the real world, getting other things done in pcb is much more important, than a conversion to metric base units. meaning proposing that we make PCB 64 bit and nanometers is redicolus. We will double our ram usage and not gain ANY benifits. Going to 64 bits buys you nothing if you don't increase the resolution of your internal units... other than allowing you to design PCBs nearly the size of the solar system. And to think this started out cause I suggested to use a really corse grid to start layouts, and keep things pretty. Use metric if your primarally using metric parts and use mils if your using inch defined parts. Chances are that people arn't placing their parts by snapping to pin one to move it on grid when placing anyhow. Why not? That is exactly what I do. I put my parts on grid and where practical, set the grid to match my parts. That keeps my traces from having jaggies. BTW, in the program I use, I can turn on snap to grid and route orthogonal and 45 degrees only. This allows me to route from pins to the grid without having any trace segments that are not on a 45 degree angle. Does PCB also support this? BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. I'm not sure what that even means. Are you suggesting that the internal representation be adjusted by the user? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range 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 I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. 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... 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. Andrew ___ 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
On Fri, Oct 08, 2010 at 06:31:33PM +0800, Steven Michalske wrote: If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Then we have file-format compatibility to deal with, and I'm sure there are weird cases that implicitly depend on the base unit (which should be rooted out at some point anyway, I know). For file-format compatibility, setting the scale-factor to 254 if none is specified, should do the trick. Now for conversion errors, are you really seeing errors in your metric PCBs? Maybe not, but we -do- see the cursor position given as 8., 7. instead of whole numbers, and these long strings overlap the GUI sometimes (I put a patch on the tracker about this when I first got here.) Hard to read, and irritating. As far as I am concirned the internal unit is meaningless provided it is fine enough. Yes, but millimeters cannot be expressed as a whole number of mils. Mils, however, can be expressed as a whole number of nanometers. So there's an important distinction. ... BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. +1 Andrew ___ 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
On Fri, Oct 08, 2010 at 08:41:06AM -0400, Rick Collins wrote: At 06:31 AM 10/8/2010, you wrote: BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. I'm not sure what that even means. Are you suggesting that the internal representation be adjusted by the user? Not quite. The ``internal resolution'' would be the same, but the visible units (on the gui and in the exports) would be scaled by the scale factor, on a per-.pcb basis. Andrew ___ 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: On Fri, Oct 08, 2010 at 06:31:33PM +0800, Steven Michalske wrote: If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Then we have file-format compatibility to deal with, and I'm sure there are weird cases that implicitly depend on the base unit (which should be rooted out at some point anyway, I know). I don't think it would be a 2 hour patch: 100., .01, 10. and so on are used in many places to convert from PCB units to mils or inches; there is no couple of macros used consistently for this purpose. Now for conversion errors, are you really seeing errors in your metric PCBs? Maybe not, but we -do- see the cursor position given as 8., 7. instead of whole numbers, and these long strings overlap the GUI sometimes (I put a patch on the tracker about this when I first got here.) Hard to read, and irritating. I deal with it without changing PCB units: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/ineiev-annoyingdecimals.squashed (and BTW the Lesstif HID provides another way to avoid that tail of nines). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 10:01 AM 10/8/2010, you wrote: On Fri, Oct 08, 2010 at 08:41:06AM -0400, Rick Collins wrote: At 06:31 AM 10/8/2010, you wrote: BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. I'm not sure what that even means. Are you suggesting that the internal representation be adjusted by the user? Not quite. The ``internal resolution'' would be the same, but the visible units (on the gui and in the exports) would be scaled by the scale factor, on a per-.pcb basis. If I understand correctly, this would not solve the problem. The problem results from working with data in metric format which can not be represented exactly using an inch based internal integer. If the internal representation is metric, then inches can be represented exactly. Are you suggesting that 32 bit integers representing nm could be used and the 2/4 meter limitation could be resolved by using a scale factor? Am I up to speed now? Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 08 Oct 2010 10:31:10 -0400 Rick Collins gnuarm.2...@arius.com wrote: Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? I ended up designing my kitchen layout using PCB. I started with QCAD, gave a try for SweetHome (for java), and IKEA's tool. I realised that PCB was good for the job. Levente ___ 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
gEDA-user: pcb for kitchens (was: Re: pcb crooked traces)
On Oct 8, 2010, at 8:57 AM, Levente Kovacs wrote: On Fri, 08 Oct 2010 10:31:10 -0400 Rick Collins gnuarm.2...@arius.com wrote: Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? I ended up designing my kitchen layout using PCB. I started with QCAD, gave a try for SweetHome (for java), and IKEA's tool. I realised that PCB was good for the job. ?? Wow. I use QCad a lot, so I've climbed the considerable learning curve, but designing a kitchen is something where I would definitely choose QCad over pcb. pcb is great for... pcbs... who'da thunk it? But if I'm doing something that is going to be fab'ed in my wood shop on a CNC tool, QCad is a better fit. I admit that QCad's UI takes some work to learn, but fundamentally it is very well done and once you learn a few tricks you can really fly with it. All that said, QCad is a 2D tool, and for architectural design a 3D tool is going to be better, assuming it is complete enough. -dave Levente ___ 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
On Oct 8, 2010, at 8:57 AM, Levente Kovacs wrote: On Fri, 08 Oct 2010 10:31:10 -0400 Rick Collins gnuarm.2...@arius.com wrote: Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? FYI -- the largest dimension I ever did on a board was 54 inches. The board was 54 x 5 inches. It was a specialized back-plane board. As I recall (this was in the 1980's) the 54 limit was determined by the maximum panel size of our vendor. The actual raw pcb panel was a little larger, but 54 inches allowed appropriate margins. Even as it was, the board was odd-ball enough that we had to hunt for a vendor that actually wanted the business (of course, it was a controlled-impedance board also, so it had some other unusual specification in addition). I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. Of course, that could grow over time, but somehow I don't think a 4m x 4m board is likely even in the long term. IMHO, pcb design decisions should be based around making pcb a good tool for designing pcb's... if people find other uses or it, OK fine, but don't drive design decisions around odd-ball uses. There are other tools for mechanical CAD, architectural, etc. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Working on a tiny schematics editor
On 10/07/2010 09:36 PM, Steve Morss wrote: Go for it! I think your idea is really neat. I'm a hard core Ruby programmer and have had similar experiences - you can say a lot in a little bit of space, the code is very readable, and coding goes quickly. On 10/7/10 1:31 PM, Stefan Salewski wrote: Some weeks ago I started working on a very basic schematics editor, compatible with current gschem file format. I am writing it in Ruby, using GTK/Cairo. . . . So chances are not too bade that I will continue working on it in the next months -- it is really easy and fun. A basic GUI and export of PCB netlist should be not too difficult. I am not sure if I will ever support hierachical design and other netlist formats -- that may be really complicated? A copy of the Ruby source text, and the png output is here. http://www.ssalewski.de/tmp/pet.rb http://www.ssalewski.de/tmp/out.png To use it with a web server/web browser does sound like a great tool for collaboration. It goes right around any install difficulties on odd platforms the full gschem has. John Griessen ___ 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
On Fri, Oct 08, 2010 at 10:31:10AM -0400, Rick Collins wrote: At 10:01 AM 10/8/2010, you wrote: Not quite. The ``internal resolution'' would be the same, but the visible units (on the gui and in the exports) would be scaled by the scale factor, on a per-.pcb basis. If I understand correctly, this would not solve the problem. The problem results from working with data in metric format which can not be represented exactly using an inch based internal integer. If the internal representation is metric, then inches can be represented exactly. Are you suggesting that 32 bit integers representing nm could be used and the 2/4 meter limitation could be resolved by using a scale factor? Yes. Set the scale-factor to 1000, and now your base-unit is um, in that the smallest PCB object you can make will be scaled to a micrometer, and you can have 2km boards if you want. Am I up to speed now? Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? Andrew ___ 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, are the pcb units still wrapped in the accessor macros for converting between internal representation and real world values? They're supposed to be, but likely they're not. We'd need to extend the file format to specify a global default unit (defaults to 0.01 mil for backwards compatibility) and teach the save function to be smart about auto-detecting what the units probably are (mm vs mil vs raw) and putting the right units on them to (1) save space, (2) make the files more robust vs change, and (3) make them more readable. ___ 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
Of course, then we need to worry about file-format compatibility between 32- and 64- bit systems... Files are text, no problem there. The routines that *read* files need to parse them as 64-bit integers always, but we can complain if (1) they don't fit in 32-bit and (2) PCB is built for 32-bit. Thus, people who need more than 2 meter boards can just rebuild pcb and get past the errors, but people who don't won't have subtle errors. ___ 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
FYI -- the largest dimension I ever did on a board was 54 inches. The largest board I've done in PCB was a quarter mile... I had a my house element. It was tiny. But I was only testing pcb's limits at the time... I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 02:10 PM 10/8/2010, you wrote: FYI -- the largest dimension I ever did on a board was 54 inches. The largest board I've done in PCB was a quarter mile... I had a my house element. It was tiny. But I was only testing pcb's limits at the time... I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... To find out would probably require a few calls to some of the larger PCB fab houses. If the drill machine were the ultimate limit, I would think that would only limit one dimension. Even if the table doesn't travel enough to cover the whole board, it can be repositioned after the first pass. But you can't drill further into the board than the machine will reach. I guess it may not be the same as CNC work, but I've done this with my drill press a number of times. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 8 Oct 2010 14:10:39 -0400 DJ Delorie d...@delorie.com wrote: I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... A couple of days ago, checked Eurocircuits (.com). They have a max of 425 x 425 mm (410 x 410 in tech pool). John ___ 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
All the drilling machines I've seen are limited in both directions. The board stack needs to be firmly pinned in place to ensure accuracy. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. A, What is an integer plus a scaling factor? -- it is a floating point value. B, If you implement it as an integer (value) and an integer (scale), you could just as well do the scaling thing in some postprocessing step, outside of the pcb program. That is basically how gschem handles dimensions, it doesn't care. C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? Someone once asked about doing a road bill-board sized sign. ___ 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
Ok, I dont really think that PCB has to have the ablity to handle a house, or kitchen in terms of length. Yes. Set the scale-factor to 1000, and now your base-unit is um, in that the smallest PCB object you can make will be scaled to a micrometer, and you can have 2km boards if you want. Basically, I like this idea, but something tells me to stick to some unit. Let's say 10nm, which is OK for inch and mm; and you have 20m total board size, wich is more then enough. Even for a small kitchen. :-) Personally I'm okay with 2m as limitation. (my kitchen is ready, and I have a 64bit system :-)) Levente ___ 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
On Fri, 8 Oct 2010 14:08:12 -0400 DJ Delorie d...@delorie.com wrote: Files are text, no problem there. The routines that *read* files need to parse them as 64-bit integers always, but we can complain if (1) they don't fit in 32-bit and (2) PCB is built for 32-bit. Thus, people who need more than 2 meter boards can just rebuild pcb and get past the errors, but people who don't won't have subtle errors. Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? I defined 32bit integers on a 8bit system with no problem. (atmel AVRs) Levente ___ 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
Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? Yes, but there's a loss of performance if you do that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
And a board can be secured easily from two sides. It is the alignment that requires some effort, but it can be done. At 02:28 PM 10/8/2010, you wrote: All the drilling machines I've seen are limited in both directions. The board stack needs to be firmly pinned in place to ensure accuracy. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 02:55 PM 10/8/2010, you wrote: Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? Yes, but there's a loss of performance if you do that. Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? The laptop I am typing this on is a 64 bit, dual core 2 year old bargain basement priced machine I bought in a hurry for $550. It would have been a $400 machine, but I wanted the 17... er, 430 mm display. But then I forget about the people who want to design kitchens on their iPads... ;^) As someone pointed out, couldn't that be a build option? If someone needs to design boards larger than 2 meters, would it be a hard thing to do to build a 64 bit version? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? Yes, it is about tolerance... and error. How much error will be introduced into a design if the system rounds all metric measurements to 0.01 mils? How much tolerance is acceptable? When you can answer these two questions for all designs and all users you can't expect anyone to believe this is nonsense! If you have a connector, for example, with 100 pins spaced on metric centers, the accumulated error can approach a half mil or 0.0127 mm. That may be a significant fraction of the pin spacing and likely not a good idea. Larger connectors would have more accumulated error. I think your response above shows you don't actually understand the issue. Of course the issue is one that would not be of concern to most users, most of the time for most designs, by far. But it started with an issue of traces that were showing up as multiple jagged traces where a straight one was expected because... a metric grid was selected and the round off error was making grid points off center. There are other possible issues. When a metric input value is rounded off and then replicated, as someone said, for large connectors or mechanical attachments, the accumulated error can become significant and parts not fit. ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. A, What is an integer plus a scaling factor? -- it is a floating point value. No, it is a block floating point value. In this case the scale factor is not applied to the entire design until you display values or produce output. The internal calcs are still all integer. B, If you implement it as an integer (value) and an integer (scale), you could just as well do the scaling thing in some postprocessing step, outside of the pcb program. That is basically how gschem handles dimensions, it doesn't care. Or you can do it inside of PCB so that the user doesn't have to remember that all the displayed units are off by a factor of 10 or 2 or 5. C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
FYI -- the largest dimension I ever did on a board was 54 inches. The largest board I've done in PCB was a quarter mile... I had a my house element. It was tiny. But I was only testing pcb's limits at the time... I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... To find out would probably require a few calls to some of the larger PCB fab houses. If the drill machine were the ultimate limit, I would think that would only limit one dimension. Even if the table doesn't travel enough to cover the whole board, it can be repositioned after the first pass. But you can't drill further into the board than the machine will reach. I guess it may not be the same as CNC work, but I've done this with my drill press a number of times. For flexible PCBs which are made on roll to roll machinery, the laser drills can make the required holes in a section, and then advance the web (roll) align to the previous holes, and continue. If they use a laser imager the same could be done on that step. All of the wet process steps are done roll to roll, so in reality you could make a continuous PCB thousands* of feet long. The main restriction is if their equipment could handle a gerber file that would need to be sectioned into hundreds or thousands of process steps (instead of their normal step and repeat). *The biggest constraint on roll length is how thick the rolls of material are when wound up, since the winding/unwinding machines have a diameter and weight limit. Andrew Miner ___ 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
Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. We can have the default unit be whatever the native long size is, 32-bit on 32-bit, 64-bit on 64-bit, so you always get the biggest fastest size. But we can still detect when your fastest size isn't big enough for some odd HUGE layout file. As someone pointed out, couldn't that be a build option? If someone needs to design boards larger than 2 meters, would it be a hard thing to do to build a 64 bit version? Of course it can. ___ 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
On Oct 8, 2010, at 12:42 PM, Andrew Miner wrote: For flexible PCBs which are made on roll to roll machinery, Good point, I forgot that a few months ago I saw some of these at a show. The vendor said you could do printed circuits 8 inches wide by arbitrarily long. Nice flex boards, too. -dave ___ 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
On Oct 8, 2010, at 10:27 AM, Dave N6NZ wrote: I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. FWIW, A quick poll of my friends indicates that 18x24 inches seems to be a standard panel size, but 48 x 22 inch boards used to be common in telecom, fabbed on 48 x 48 inch panels. A friend at Cisco says they regularly do 16x26 inch backplanes now. (and 14x21 inch 14 layer (!) boards that's a lot of layers in 21 inches. When I was at Amdahl, we did boards with 50 signal layers (and 12 or so power layers) but that was a smaller board, and we weren't trying to build thousands of them) Max size seems to vary a lot depending on the fab's equipment. I think the fab house that did my 54 inch board in the 1980's used panels around 60 inches long. So... if pcb were to be limited to a 2 meter by 2 meter board, would it actually be a painful limitation to anyone? Now that I think of it, my 54 inch board had to be done in two pieces because of the CAD software... but it was easy to line up the pieces because it was all transmission lines crossing the middle, and so vendor somehow got his photoplotter to paint left and right half files on the film with good registration. I also had an adventurous tech working for me who enjoyed challenges...) -dave ___ 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: At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? Yes, it is about tolerance... and error. How much error will be introduced into a design if the system rounds all metric measurements to 0.01 mils? How much tolerance is acceptable? When you can ... Please, I was commenting about the misunderstandings about floating-point, not about mils and mm's. With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? There are other possible issues. When a metric input value is rounded off and then replicated, as someone said, for large connectors or mechanical attachments, the accumulated error can become significant and parts not fit. ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. ... C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Ack. I know that using a basic unit of mm's or part thereof will solve the mil/mm problem. My point was that this does not have anything with integer vs. floating points. And I also hinted the reader that he/she could swap the 32bit ints for doubles and you would get the exactly the same results (unless you divide of cause, then doubles comes out better). Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
So... if pcb were to be limited to a 2 meter by 2 meter board, would it actually be a painful limitation to anyone? MAXINT nm is 84.5 inches (just over 7 feet). Anyone who needs more than 84x84 inch boards can re-compile PCB with 64-bit units. ___ 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
On Fri, Oct 08, 2010 at 11:04:59PM +0200, Karl Hammar wrote: Please, I was commenting about the misunderstandings about floating-point, not about mils and mm's. With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? The concern is with /binary/ floating point, not floating point in general. In binary floating point, your scale is always a power of 2, so some numbers cannot be represented - particularly, some numbers cannot be represented that /can/ be represented in decimal (like 0.3), so we will introduce an error when somebody types .3 into pcb. With integers, anything the user can type, can be represented. Importantly, 1/254 = 1/2 * 1/127 cannot be represented in binary floating point, which brings us back to the mm/mil problem. This is the crucial difference between our scaling idea (fundamental units + an arbitrary multiplier) and binary floating point. Andrew ___ 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
On Fri, 2010-10-08 at 15:42 -0400, DJ Delorie wrote: Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. I'm not certain that is true.. or are you compiling with CFLAGS for a non 64-bit CPU? I thought the 32/64 bit OS issue was mostly to do with address pointers, rather than aritmetic. I was fairly sure one could execute 64bit native CPU arithmetic instructions under a 32-bit OS, just that the executable would not be portable to machines which didn't support those instructions. -- 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 crooked traces
On Oct 8, 2010, at 3:04 PM, Karl Hammar wrote: So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? The problem is that in engineering documentation, dimensions are generally given as decimal fractions of inches or meters. Cumulative roundoff error can be avoided if the numeric encoding can exactly represent such numbers. Scaled integers or scaled floating point may be used, but scaled integers are a bit easier to use and understand, and are usually more efficient. Unscaled binary floating point is troublesome because it cannot exactly represent most decimal fractions, so it is prone to cumulative error. 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
gEDA-user: Locating the system-gafrc at Build Time
All, The part manager needs to know the location of system-gafrc file. When installing from a Debian package on Ubuntu 10.04 LTS, the file is located in /etc/gEDA/system-gafrc. This prefix does not match any of the build directory variables in the part manager or match anything returned from g_get_system_config_dirs(). Using 'dpkg -S system-gafrc' will locate the file properly. I'm looking for a reliable mechanism to locate this file at build time. Would adding additional variables to gaf's pkg-config and building these paths into the part manager application be a good solution? Right now, I could add additional paths to a list and the application can poke around the filesystem for it. This mechanism does not seem like a valid solution. I also have an environment variable, but I do not want to require the user to set this variable in the normal case. Cheers, Ed ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 03:42 PM 10/8/2010, you wrote: Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. We can have the default unit be whatever the native long size is, 32-bit on 32-bit, 64-bit on 64-bit, so you always get the biggest fastest size. But we can still detect when your fastest size isn't big enough for some odd HUGE layout file. I am asking how much of a performance hit. Has anyone actually done anything to calibrate this? Unless we have some idea of how much the performance hit would be, there is not much point in discussing it. A 1% slowdown is not worth talking about. A 1000% slowdown would be an issue. Numbers in between would be worth discussing. Performance issues fall into three categories in terms of impacting the user. A delay up to 0.3 seconds is not really noticeable as a delay to the user. From there up to 3 seconds is noticeable, but not enough to lose focus on your task. About 3 seconds to 30 seconds delay you lose focus on your task which significantly impacts your productivity and is very irritating. Beyond about 30 seconds and the user is inclined to leave the work station. Do you think the 64/32 bit performance issue would push any of the current operational delays across any of these thresholds? As someone pointed out, couldn't that be a build option? If someone needs to design boards larger than 2 meters, would it be a hard thing to do to build a 64 bit version? Of course it can. Then why should we worry about the remote possibility that a user will want a PCB larger than 2 meters? Their problem could be solved by creating a 64 bit version. I just saw your later post that clearly states your position so I guess I have my answer. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 05:04 PM 10/8/2010, you wrote: Rick Collins: At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? Yes, it is about tolerance... and error. How much error will be introduced into a design if the system rounds all metric measurements to 0.01 mils? How much tolerance is acceptable? When you can ... Please, I was commenting about the misunderstandings about floating-point, not about mils and mm's. With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. That is what you aren't getting. The problem is not aliasing in any way I understand aliasing. It is that you can't represent an exact metric value in an inch system. When you multiply an arbitrary number of few digits by 2.54 (convert inches to metric) you get two or three more digits than you started with. Try dividing the same by 2.54 (convert metric to inches) and you get a lot more digits than you started with, maybe infinite, I'm not sure. So in an inch based system you will never be able to represent metric numbers exactly. The opposite is not true, a metric based system can represent an inch value exactly. So you will not get a round off error of an input value. All points you need to calculate will be exact and the jaggies won't happen. This is not the same a finite resolution of a display or other bit mapped output. We aren't talking about the pixels lighting up on a CRT... er, LCD. We are talking about the end point of a trace not being in the right position so that a 45 degree trace can not connect them... exactly. That is what produces the jagged traces the OP complained about, if I understand the discussion correctly. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? Floats aren't any worse if they have the resolution... but they aren't any better either! There are other possible issues. When a metric input value is rounded off and then replicated, as someone said, for large connectors or mechanical attachments, the accumulated error can become significant and parts not fit. ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. ... C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Ack. I know that using a basic unit of mm's or part thereof will solve the mil/mm problem. My point was that this does not have anything with integer vs. floating points. Ok, I agree. I guess all this was about nothing. And I also hinted the reader that he/she could swap the 32bit ints for doubles and you would get the exactly the same results (unless you divide of cause, then doubles comes out better). Now I'm lost again... maybe. If you stick with inches, no, using doubles buys nothing. The point about using doubles is that to use metric, it seems like going with a unit of nm is appropriate. Then you are limited to 2 or 4 meter max value with 32 bit ints. Going to double resolves that problem by giving you another factor of 4 billion in your range. I guess we are talking past each other while agreeing... yes? Rick ___ geda-user
Re: gEDA-user: pcb crooked traces
At 05:07 PM 10/8/2010, you wrote: So... if pcb were to be limited to a 2 meter by 2 meter board, would it actually be a painful limitation to anyone? MAXINT nm is 84.5 inches (just over 7 feet). Anyone who needs more than 84x84 inch boards can re-compile PCB with 64-bit units. To be perfectly correct, anyone who needs more than 84x84 inch boards will need to recompile PCB with 64-bit units. If it is me, I have no idea how to, so I can not. But I don't plan to. If I need boards larger than 84x84 inches, I will hire one of you to either layout the board for me or to recompile the tools. :^) Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was Re: gattrib)
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? Cheers, Ed ___ 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
Then why should we worry about the remote possibility that a user will want a PCB larger than 2 meters? Their problem could be solved by creating a 64 bit version. I just saw your later post that clearly states your position so I guess I have my answer. Ah, this is where opensource way of thinking fails it. You don't go and create a 64bit version. You engineer it so that stuff works out of the box and requires minimal user interaction. I still rage each time I install a modern lunix distro in 2010 and find out apache can't serve files 4GiB lol. Microsoft got it right with NTFS over 15 years ago... ___ 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
A delay up to 0.3 seconds is not really noticeable as a delay to the user. An 0.3 second delay updating the screen while moving a part is *very* slow. My refresh rate is already annoying, I don't need it to be more annoying. Then why should we worry about the remote possibility that a user will want a PCB larger than 2 meters? I'm not worried, as you note. I just wanted to put a check in for the rare case when it happens. It's good practice to check for overflow when converting a text string into an integer. ___ 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
The root cause of the problem is that the grid setting is a floating point number. It has to be to reduce cumulative error in metric grid points, but it cannot convert metric grids to our mil-based grid exactly. Example: A metric grid might have a grid setting of 100.11. A particular trace between two grid points that *would* have been a perfect 45, and up being (made-up example) between 100,400 (100.11,400.44) and 200,501 (200.22,500.55) because of conversion rounding. The off-by-one error is due to the inexact representation of our grid settings as well as rounding artifacts when converting to integer units. Solution: The solution - in this case - is to switch to a small metric-based core unit. Then, at least, our normal grid settings will always be a whole number of core units, instead of being some unrepresentable fraction. ___ 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
To be perfectly correct, anyone who needs more than 84x84 inch boards will need to recompile PCB with 64-bit units. If it is me, I have no idea how to, so I can not. But I don't plan to. If I need boards larger than 84x84 inches, I will hire one of you to either layout the board for me or to recompile the tools. :^) If we do it right, it's as simple as: ./configure --enable-huge-boards make ___ 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
I still rage each time I install a modern lunix distro in 2010 and find out apache can't serve files 4GiB lol. You must be doing something wrong, as apache has no problem with such files, nor does Linux. Modern distros handle files up to petabytes. Maybe this fictitious lunix distro is to blame. The rest of us use Linux. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 08:32 PM 10/8/2010, you wrote: A delay up to 0.3 seconds is not really noticeable as a delay to the user. An 0.3 second delay updating the screen while moving a part is *very* slow. My refresh rate is already annoying, I don't need it to be more annoying. My point is that as a qualitative statement this may sound reasonable. But unless you find a way to make a quantitative measurement, you really don't know that it will be more annoying because you don't know that it will be noticeable. Many years ago I paid a premium price for a 486 based computer partly because of talk of the built in floating point being so much faster than software based floating point. Only later did I find that in the end it made little difference in the apps I was running because most of the processor time was spent in the control portion of the apps. I find that a lot of times things get optimized even if no one knows for sure they are a problem. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 08:44 PM 10/8/2010, you wrote: To be perfectly correct, anyone who needs more than 84x84 inch boards will need to recompile PCB with 64-bit units. If it is me, I have no idea how to, so I can not. But I don't plan to. If I need boards larger than 84x84 inches, I will hire one of you to either layout the board for me or to recompile the tools. :^) If we do it right, it's as simple as: ./configure --enable-huge-boards make After about a couple of hundred other steps... Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Location of system-gafrc
All, The part manager needs to know the location of system-gafrc file. When installing from a Debian package on Ubuntu 10.04 LTS, the file is located in /etc/gEDA/system-gafrc. This prefix does not match any of the build directory variables in the part manager or match anything returned from g_get_system_config_dirs(). Using 'dpkg -S system-gafrc' will locate the file properly. I'm looking for a reliable mechanism to locate this file at build time. Would adding additional variables to gaf's pkg-config and building these paths into the part manager application be a good solution? Right now, I could add additional paths to a list and the application can poke around the filesystem for it. This mechanism does not seem like a valid solution. I also have an environment variable, but I do not want to require the user to set this variable in the normal case. Cheers, Ed ___ 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
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
Re: gEDA-user: pcb crooked traces
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
Re: gEDA-user: Database on symbols, footprints and other (was Re: gattrib)
On Mon, May 3, 2010 at 1:41 PM, Britton Kerin britton.ke...@gmail.com wrote: What about SQLite? I've *glanced* at its home page a couple times in the past (really no more than that), and in really less than 10 minute just now I was able to download it, build it, create a database in a file, query it, and dump its generative code (probably a good format for grep-happy people like you :). What I've been thinking of lately is a sort of heavy symbol wiki that people could add to as they create their own project parts like you do. You could build parts in chroots with a few things (Pcb_9.pm tragesym etc.) available. I'm not sure how useful a DB would be in an application like this but I wouldn't rule it out just based on bad experiences with servers databases. Britton SQLite for the win, it is easy, simple and relitivly fast. built into Python. built into Mac OSX When needed you can switch your database code over to a heaver database. ___ 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)
OMG! what is the core temperature of earth?? did it drop a few degrees? :-) On Tue, May 4, 2010 at 9:26 PM, Kai-Martin Knaak k...@familieknaak.de wrote: On Mon, 03 May 2010 08:45:29 -0600, John Doty wrote: Yep. And then if you do that, and update regularly, trivial search commands like: locate .sym | grep -i max921 Hey-ho! Finally a topic I totally agree with John D.! ;-) ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ 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)
Yikes folks, sorry for brining this old thread back to life, somehow it got pulled to the top of my gmail in a thread and i starded re reading it. and commenting.. Sorry for bringing it all back up. ___ 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
P.s. who the fuck is john lennon? http://tinyurl.com/chvu8a ___ 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: ) and putting the right units on them to (1) save space, (2) make the files more robust vs change, and (3) make them more readable. +1 I am all in favor of readability. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: GNUduino - Arduino made with gEDA
Hello all, I have designed a board named GNUduino (www.jeffrey.co.in/projects/gnuduino) Long before I had posted in the same mailing list about this board. On that day only the designs were ready. Now I have successfully fabricated the board. Please have a look at it. Design files are available from http://github.com/jeffreyantony/GNUduino GNUduino snapshots http://jeffrey.co.in/blog/2010/10/gnuduino-arduino-made-with-geda/ http://jeffrey.co.in/blog/2010/10/cooking-gnuduino/ Queries 1) I have some problems with the PCB files in this design. I am not able to move component descriptors. At present many of the component descriptors are overlapped (eg: R4 and LED14). Please let me know how to move these. In gschem moving the component descriptors are easy to move. 2) If possible can anyone go through the design files and give a reply about the board? 3) I want to write a plug-in for PCB. Are there any links which can help me in writing the plug-ins ? -- Thanks and Best Regards Jeffrey || JAY FREE W: http://jeffrey.co.in/ M: +918148490036 ___ 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
1) I have some problems with the PCB files in this design. I am not able to move component descriptors. At present many of the component descriptors are overlapped (eg: R4 and LED14). Please let me know how to move these. In gschem moving the component descriptors are easy to move. Make sure lock names setting is not set. 3) I want to write a plug-in for PCB. Are there any links which can help me in writing the plug-ins ? No links, just examples. Basically, you write a source file as if it were going to be linked in, just don't link it in. I have a bunch of plugins here: http://www.delorie.com/pcb/ ___ 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
On Sat, 9 Oct 2010 11:22:54 +0900 timecop time...@gmail.com wrote: Whaat. Please keep your off-topic bullshit *off* this list. At the risk of being labeled a hypocrite myself for pursuing this thread: To most everyone else on this list, your posts fall into the off topic category more often than not, as well as being inflammatory much of the time. That aside... 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. First, let me spell it out clearly for you. The word is L - i - n - u - x. The i comes before the u. Second and more importantly for this already grossly off-topic thread, the problem you're talking about with file size limits has little to do with the underlying filesystem, and more to do with the capabilities of the applications handling those files. Those problems existed on the Windows platform as well, and took forever to resolve, but that is not the issue under discussion here either. Rather, this discussion is about the size of a few variables used within PCB's code (4 bytes apiece now versus the proposed 8 bytes apiece), and the amount of memory the resultant data file would take up, provided it would end up increasing by a significant amount. For the record, the standard-issue Linux ext2 filesystem came out in January 1993, with a 2 TB file size limit. This is what virtually everyone who ran Linux would have been using initially. NTFS was released in July 1993 - six months later. It currently has a size limit of 16 TB, and appears to have had a limit of around 4 TB when first introduced (hard to find solid info on this). XFS came out in 1994 for IRIX systems, and has a file size limit of 8 EXAbytes. The specification was released to the public in May 2000, and Linux picked native support for it in 2001. Note that back in the days when these filesystems were created, even the biggest hard drives weren't even 10 GB, and most common ones were closer to 2 GB, and I doubt most users have more than 250 GB in their machines these days. Our biggest drives today *that are reliable* are just getting into the 2 TB range. In other words, the maximum file size complaint, legit or not, is a moot point. *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. That would be because someone else already made that decision for you and supplied you with a binary executable. Whether it is tuned to your exact needs is up to you to decide. Having to rebuild something with ./configure --enable-. We keep this kind of standard for one simple reason: By the look of it, this could BREAK COMPATIBILITY with older versions of PCB or existing board files. Portability of a board file from one user to another is one of the keys to maintaining the openness of the project, not just the code that makes it run. Besides that, some people might want to turn certain features off, for whatever reason. I, for example, have no use for the documentation that comes with PCB, so I turn it off at compile time so I don't have to futz with installing the various support libraries that are needed to build those files. I'm sure others here can come up with other examples. If you want the feature turned on, then turn it on when you compile the program - it seems logical to me that when you compile a program, you should periodically add --help to check what switches are supported by a program's configure script. It takes all of 10 or 20 seconds to skim the list for items you might want to add. It isn't like you're going to be compiling the program several times a day. P.s. who the fuck is john lennon? He was a member of The Beatles, the most popular rock band of their time (roughly 1960 to 1970). His signature was the round spectacles he wore. Murdered on Dec 8, 1980. See also: http://en.wikipedia.org/wiki/John_Lennon -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
