gEDA-user: auto-uref increments by twos
As Mithat Konar posted on Sept 6, 2010, I too am now having auto-uref number my components starting with 2 and incrementing by 2. I've just upgraded to 1.6.1.20100214 and it works beautifully (I had been using a significantly older version) but the component numbering issue has me a little baffled. I thought maybe I had two gschemrc's that both had an auto-increment command, but if I disable the gschemrc I wrote in $HOME/.gEDA it doesn't auto-increment at all, just U?. When I enable my personal gschemrc, I go back to getting U2. Any ideas? Thanks John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Fluky Fluky layout printing problem!
Orange means a short circuit. An easier way to update if you're using the importer, is to View->Displayed Element Name->Description and change it, then re-import. It will replace the footprint while retaining all the other information and position. As for the PDF, if you see the right thing in the PDF but it doesn't print right, the problem is between the PDF viewer and the printer. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Fluky Fluky layout printing problem!
I believe I have found my layout printing problem.
My original pad statements for the inductors were:
Pad[-20650 0 -20642 0 11000 1200 1500 "" "1" "square"]
Pad[20642 0 20650 0 11000 1200 1500 "" "2" "square"]
It has been a while since I have created a footprint and I messed up
the clearance. Is it possible that I could see the pads on the etch
pattern in the pdf document but they didn't print out because the
solder mask was covering it? I changed the statements to:
Pad[-20642 0 -20650 0 11000 1200 11200 "" "1" "square"]
Pad[20642 0 20650 0 11000 1200 11200 "" "2" "square"]
I then saved the footprints. Now, following
[1]http://geda.seul.org/wiki/geda:pcb_tips#how_do_i_update_a_footprint_
in_my_layout I tried to update the pad and when I optimize rats
afterwards the pads turn orange. I have tried it many ways, after
loading the footprint in the buffer I hold it over the current
footprint and do shift->left-mouse-click, rotating the buffer twice and
hold it over the current footprint and do shift->left-mouse-click,
delete the current footprint and load the footprint in the buffer and
hold it over the current footprint and do shift->left-mouse-click, and
delete the current footprint rotate the buffer twice and do
shift->left-mouse-click.
Now I'm stuck.
On Fri, Jan 21, 2011 at 4:03 PM, Rob Butts <[2]r.but...@gmail.com>
wrote:
So, I tried printing your pdf file and nothing printed out. I'm
printing this in windows and using Adobe Reader 9.3. I went back and
printed my conversion of test.fp.pdf and again just 1 square printed.
I then downloaded and installed Foxit Reader 4.3 and niether square
printed for both your conversion and mine.
Maybe I'll try retyping the footprint?
On Fri, Jan 21, 2011 at 3:11 PM, Peter Clifton <[3]pc...@cam.ac.uk>
wrote:
On Fri, 2011-01-21 at 14:46 -0500, Rob Butts wrote:
> Peter,
>When I printed it out a BIG smile came on my face because as you
>probably expected only one square printed. Now I suspect you know
what
>the problem is.
>Am I right?
Sadly not, I just removed all but the pads from the ps file. It
displays
file for me..
Having the minimal test-case will help track the issue down though.
What
software did you use to print the resulting PDF?
If anyone cares to see it pasted directly:
72 72 scale 4.13385 5.84645 translate
90 rotate
1 1 scale % calibration
1e-05 dup neg scale
/t { moveto lineto stroke } bind def
11000 setlinewidth
2 setlinecap 2 setlinejoin
6100 19700 6108 19700 t
47392 19700 47400 19700 t
showpage
Just in case the bug is in ps2pdf, I've attached my conversion (also
using ps2pdf)
--
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
[4]geda-user@moria.seul.org
[5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
References
1.
http://geda.seul.org/wiki/geda:pcb_tips#how_do_i_update_a_footprint_in_my_layout
2. mailto:r.but...@gmail.com
3. mailto:pc...@cam.ac.uk
4. mailto:geda-user@moria.seul.org
5. 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: speed of the gschem GUI
- Original message - > A good strategy is always to have a bounding box for each element, and > to draw only elements when their bounding box overlaps with the visible > part on screen. So not rely on cairo's clipping. We already do this. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: speed of the gschem GUI
On Sat, 2011-01-22 at 06:21 +0100, Kai-Martin Knaak wrote: > Hi. > While working on a fairly large schematic I noticed that panning > in gschem is way less snappy than the same circuit rendered as PDF > in evince or kpdf. There is no benchmarking available. The ratio > seems like 10. While my schematic pans in gschem with 3 to 5 FPS, > it is definitely beyond 30 FPS in the PDF renderers. > Since both applications deal with lines and characters, I'd naively > expect similar performance. Or did I miss something? > > Is there any hope to speed up the gschem GUI? > > ---<)kaimartin(>--- Yes, cairo drawing looks fine and is easy to use, but is not very fast. That is why Peter C. used native OpenGL for PCB. Of course there are various strategies for increasing the speed. One is to draw all to a larger buffer and copy only the visible part to the window on the screen, this may make panning/scrolling very fast, but has overhead in used memory consumption, and zooming will be slower. A good strategy is always to have a bounding box for each element, and to draw only elements when their bounding box overlaps with the visible part on screen. So not rely on cairo's clipping. One may consider buffering strategies, i.e. buffer each symbol, buffer part of the visible screen. For me that worked not very fine. You may try to do profiling cairo's drawing, that is what is suggested from cairo developers. I still have to learn how to do that. Or you may consider employing cairo's GL backend. You may look at the cairo list, i.e http://permalink.gmane.org/gmane.comp.lib.cairo/20970 Please let us know if you have first results. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
