Re: gEDA-user: gschem saving symbols
On Thu, 16 Jun 2011 22:17:40 -0700 (PDT) Josh Jordan outerspacema...@yahoo.com wrote: The position of all the objects in the symbol are big numbers for the position they had in the schematic. Is there a reason to make these numbers small near the origin like in the original symbol file? That's a good question... as is often the case in the gschem documentation, the symbol creation guide says you should always translate the symbol to the origin, *but* it does not explain why this is required. “Translating the symbol to the origin is a required step.” - http://www.geda.seul.org/wiki/geda:gschem_symbol_creation Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: help needed; asymmetric load after rectifier seems to disrupt its working.
Yeap, it should be a very low power power supply. Vx is not important Vcc and Vss are. Vin can be anything from 15Khz to 28Khz so a transformer is not the most desired option. I have designed two SMPS for Vcc and Vss but there load to the rectifier are not the same, with the described result. I will try the options suggested in this list today. Robert. On 17/06/11 04:13, gene glick wrote: On 06/16/2011 02:30 PM, myken wrote: Hello all, I would appreciate some expert advice. Are you trying to make a low current power supply? I agree with DJ - the unequal loading on + and - cycle will average to something other than zero (unequal capacitors, unequal diodes, etc) If Vx must always be average zero - you'll need to do something else. If you can handle a little voltage drop, don't care what happens to Vx, and don't mind adding a few parts, make a cheapo regulator with a zener and BJT? (Or maybe use TL31 instead of zener) What about a small transformer, one winding on primary, center tapped on secondary. Add a diode and a cap for each leg - and there you go! Anyway, there's lots of ways to do this. If regulated output is what you want, a little more work is required. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in PCB's Gerber generation?
On Thu, Jun 16, 2011 at 08:44:13PM +0200, Gabriel Paubert wrote: Hi Andrew, I just pulled PCB from git head and I have trouble with arcs in Gerber output. I strongly suspect the latest commit: layers which do not have arcs appear fine in gerbv, but automatic zooming layers which contain arcs zoom out and give coordinates in the range of several meters (with the screen staying lack). Also my outline has a single arc in one corner and this is precisely this segment which is missing. I can not prepare a test case right now but will tomorrow (it's almost 9 pm here), if you've not beat me to fix it before. For some reason Andrew replied priavtely, but I want to thank him for having fixed the bug in git head, and having added a testcase for arcs. Now it is the drill file (I did not come around to checking it yesterday, sorry) which is incorrect: too targe blobs and in the wrong place :-( Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: help needed; asymmetric load after rectifier seems to disrupt its working.
Simply reproducing the filter twice, one for each polarity of rectifier will not work. If you can float the load or the source then splitting the circuit into two and using a bridge rectifier in each will work OK. The attached shows what I mean. Cheers, Andy. www.signality.co.uk On 16 June 2011 23:05, myken my...@iae.nl wrote: Thanks DJ, I had the same thought that Vx was floating somewhere unwanted, that's why I added the resistor (which didn't work). Gazing at this problem for a couple of days make me miss the obvious, just split the filter. Brilliant. I'll give it a try. Robert. On 16/06/11 20:48, DJ Delorie wrote: When you put two capacitors in series, there's no way to know what the voltage between them will be. You have three with a common central connection Vx. V1 acts to charge the node, the loads act to discharge it, so an unequal load means unequal discharging and thus nonzero average node voltage. Since D1 and D2 may have different average currents through them, Vx will adjust until the average current through R2 is the same as the net current throuth the two diodes. Can you split the filter into two filters, one for each load? or at least move C1 to the Vx side of the filter, and split it into two capacitors? ___ 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 rects_01.pdf Description: Adobe PDF document ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in PCB's Gerber generation?
On Fri, Jun 17, 2011 at 10:49:34AM +0200, Gabriel Paubert wrote: On Thu, Jun 16, 2011 at 08:44:13PM +0200, Gabriel Paubert wrote: Hi Andrew, I just pulled PCB from git head and I have trouble with arcs in Gerber output. I strongly suspect the latest commit: layers which do not have arcs appear fine in gerbv, but automatic zooming layers which contain arcs zoom out and give coordinates in the range of several meters (with the screen staying lack). Also my outline has a single arc in one corner and this is precisely this segment which is missing. I can not prepare a test case right now but will tomorrow (it's almost 9 pm here), if you've not beat me to fix it before. For some reason Andrew replied priavtely, but I want to thank him for having fixed the bug in git head, and having added a testcase for arcs. Now it is the drill file (I did not come around to checking it yesterday, sorry) which is incorrect: too targe blobs and in the wrong place :-( Correction: only the coordinates are wrong, the sizes look correct. Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in PCB's Gerber generation?
On Fri, Jun 17, 2011 at 11:41:22AM +0200, Gabriel Paubert wrote: On Fri, Jun 17, 2011 at 10:49:34AM +0200, Gabriel Paubert wrote: On Thu, Jun 16, 2011 at 08:44:13PM +0200, Gabriel Paubert wrote: Hi Andrew, I just pulled PCB from git head and I have trouble with arcs in Gerber output. I strongly suspect the latest commit: layers which do not have arcs appear fine in gerbv, but automatic zooming layers which contain arcs zoom out and give coordinates in the range of several meters (with the screen staying lack). Also my outline has a single arc in one corner and this is precisely this segment which is missing. I can not prepare a test case right now but will tomorrow (it's almost 9 pm here), if you've not beat me to fix it before. For some reason Andrew replied priavtely, but I want to thank him for having fixed the bug in git head, and having added a testcase for arcs. Now it is the drill file (I did not come around to checking it yesterday, sorry) which is incorrect: too targe blobs and in the wrong place :-( Correction: only the coordinates are wrong, the sizes look correct. And it turned out to be relatively easy once you understand the %m conversion: mixing imperial and metric can easily veer you off course, you don't need to be close to Mars. diff --git a/src/hid/gerber/gerber.c b/src/hid/gerber/gerber.c index 5e0b7b6..f949d42 100644 --- a/src/hid/gerber/gerber.c +++ b/src/hid/gerber/gerber.c @@ -646,7 +646,7 @@ gerber_set_layer (const char *name, int group, int empty) Aperture *ap = findAperture (curr_aptr_list, pending_drills[i].diam, ROUND); fprintf (f, T%02d\r\n, ap-dCode); } - pcb_fprintf (f, X%06.0mmY%06.0mm\r\n, + pcb_fprintf (f, X%06.0mlY%06.0ml\r\n, gerberDrX (PCB, pending_drills[i].x), gerberDrY (PCB, pending_drills[i].y)); } Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in PCB's Gerber generation?
On Fri, 17 Jun 2011 12:42:09 +0200 Gabriel Paubert paub...@iram.es wrote: - pcb_fprintf (f, X%06.0mmY%06.0mm\r\n, + pcb_fprintf (f, X%06.0mlY%06.0ml\r\n, Is this commited? Thanks, Levente -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: help needed; asymmetric load after rectifier seems to disrupt its working.
On 06/16/2011 02:30 PM, myken wrote: Hello all, I would appreciate some expert advice. Are you trying to make a low current power supply? I agree with DJ - the unequal loading on + and - cycle will average to something other than zero (unequal capacitors, unequal diodes, etc) If Vx must always be average zero - you'll need to do something else. If you can handle a little voltage drop, don't care what happens to Vx, and don't mind adding a few parts, make a cheapo regulator with a zener and BJT? (Or maybe use TL31 instead of zener) What about a small transformer, one winding on primary, center tapped on secondary. Add a diode and a cap for each leg - and there you go! Anyway, there's lots of ways to do this. If regulated output is what you want, a little more work is required. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test updates to auto-uref.scm
Krzysztof Kościuszkiewicz wrote: Please add this to the system-gschemrc: /-- (..snip...) \- My patch contains something like this Except for the first line, the text was taken from your patch ;-) - I have provided a separate function for changing this value because new Guile versions do not allow for redefinition of values. Ah. I did not get what auto-uref-set-page-offset was good for. So the system-gschemrc addition would be: /--- ;; Set the value of page-offset for auto number on insert. ;; Refdeses will be numbered from integer multiples of page-offset, ;; depending on the lowest refdes value found on the page. ;; If lowest value is 323 and page offset is 100, then next refdes ;; will be 301. ;; Setting to 0 disables the feature. (auto-uref-set-page-offset 100) \--- I think, it is reasonable to set this value to 100 by default. This covers probably most use cases. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem saving symbols
Colin D Bennett wrote: That's a good question... as is often the case in the gschem documentation, the symbol creation guide says you should always translate the symbol to the origin, but it does not explain why this is required. On insert, the mouse cursor is at the origin of the symbol. So the graphics will only be near the mouse if it is placed near the lower left. Other than that I see no consequences. (Correct me, if I am wrong) I attached a symbol that was deliberately translated a few centimeters up and right. Try to insert it into a schematic and you see, what I mean. Proposal: On insert, position the cursor at the sensitive point of pin one if it exists. Else, fall back to the position of the first pin in the symbol. If there are no pins at all, fall back to the mean position of all objects of the symbol, rounded to the next grid point. Rationale: The pins should be on major grid points to allow for easy connection. So the sensitive point of a pin is a reasonable reference point for symbol placement. Benefit: Changed symbols won't break schematics as easily as they do now. There is an aspect less to worry about during symbol creation. Impact: This proposal is completely backward compatible. All existing symbols still work. There is no change of file format either. ---)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
Re: gEDA-user: Bug in PCB's Gerber generation?
On Fri, Jun 17, 2011 at 01:35:11PM +0200, Kovacs Levente wrote: On Fri, 17 Jun 2011 12:42:09 +0200 Gabriel Paubert paub...@iram.es wrote: - pcb_fprintf (f, X%06.0mmY%06.0mm\r\n, + pcb_fprintf (f, X%06.0mlY%06.0ml\r\n, Is this commited? No, I don't have write privileges, nor do I want them since I don't have time to work on significant improvements. I hope that Andrew will pick this up and commit it when he checks his mail. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in PCB's Gerber generation?
On Fri, Jun 17, 2011 at 10:49:34AM +0200, Gabriel Paubert wrote: For some reason Andrew replied priavtely, but I want to thank him for having fixed the bug in git head, and having added a testcase for arcs. Now it is the drill file (I did not come around to checking it yesterday, sorry) which is incorrect: too targe blobs and in the wrong place :-( Good catch. I missed this in my test case as well, since I ran ``gerbv *.gbr'', forgetting about the .cnc file. I have committed your fix, checked that the output (of ALL files) is correct now, and fixed the test. Thanks for reporting! -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: skpi_drc patch
Attached you can find the skip_drc patch for the current head.
It would be nice if it was checked in to git HEAD.
Thanks,
Levente
--
Levente Kovacs
http://levente.logonex.eu
diff --git a/src/action.c b/src/action.c
index 4f2e401..af93c19 100644
--- a/src/action.c
+++ b/src/action.c
@@ -6947,7 +6947,7 @@ find_element_by_refdes (char *refdes)
return NULL;
}
-static AttributeType *
+AttributeType *
lookup_attr (AttributeListTypePtr list, const char *name)
{
int i;
diff --git a/src/action.h b/src/action.h
index ee116e8..6dbaf2d 100644
--- a/src/action.h
+++ b/src/action.h
@@ -46,4 +46,5 @@ void warpNoWhere (void);
/* In gui-misc.c */
bool ActionGetLocation (char *);
void ActionGetXY (char *);
+AttributeType * lookup_attr (AttributeListTypePtr list, const char *name);
#endif
diff --git a/src/find.c b/src/find.c
index eb4cac2..cdd1063 100644
--- a/src/find.c
+++ b/src/find.c
@@ -94,6 +94,7 @@
#include set.h
#include undo.h
#include rats.h
+#include action.h
#ifdef HAVE_LIBDMALLOC
#include dmalloc.h
@@ -822,6 +823,8 @@ LookupLOConnectionsToPVList (bool AndRats)
/* now all lines, arcs and polygons of the several layers */
for (layer = 0; layer max_copper_layer; layer++)
{
+ if (LAYER_PTR (layer)-no_drc)
+ continue;
info.layer = layer;
/* add touching lines */
if (setjmp (info.env) == 0)
@@ -1169,6 +1172,8 @@ LookupPVConnectionsToLOList (bool AndRats)
/* loop over all layers */
for (layer = 0; layer max_copper_layer; layer++)
{
+ if (LAYER_PTR (layer)-no_drc)
+ continue;
/* do nothing if there are no PV's */
if (TotalP + TotalV == 0)
{
@@ -2901,6 +2906,22 @@ ListsEmpty (bool AndRats)
return (empty);
}
+
+static void
+reassign_no_drc_flags (void)
+{
+ int layer;
+
+ for (layer = 0; layer max_copper_layer; layer++)
+{
+ LayerTypePtr l = LAYER_PTR (layer);
+ l-no_drc = lookup_attr ((l-Attributes), PCB::skip-drc) != NULL;
+}
+}
+
+
+
+
/* ---
* loops till no more connections are found
*/
@@ -2908,6 +2929,7 @@ static bool
DoIt (bool AndRats, bool AndDraw)
{
bool newone = false;
+ reassign_no_drc_flags ();
do
{
/* lookup connections; these are the steps (2) to (4)
@@ -3350,6 +3372,7 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
/* check if there are any pins or pads at that position */
+ reassign_no_drc_flags ();
type
= SearchObjectByLocation (LOOKUP_FIRST, ptr1, ptr2, ptr3, X, Y, Range);
@@ -3366,8 +3389,8 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
int laynum = GetLayerNumber (PCB-Data,
(LayerTypePtr) ptr1);
- /* don't mess with silk objects! */
- if (laynum = max_copper_layer)
+ /* don't mess with non-conducting objects! */
+ if (laynum = max_copper_layer || ((LayerTypePtr)ptr1)-no_drc)
return;
}
}
diff --git a/src/global.h b/src/global.h
index daa82a9..08abbb8 100644
--- a/src/global.h
+++ b/src/global.h
@@ -303,6 +303,7 @@ typedef struct /* holds information about one layer */
char *Color, /* color */
*SelectedColor;
AttributeListType Attributes;
+ int no_drc; /* whether to ignore the layer when checking the design rules */
}
LayerType, *LayerTypePtr;
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug in PCB's Gerber generation?
On Fri, 17 Jun 2011 10:40:50 -0700 Andrew Poelstra as...@sfu.ca wrote: Good catch. I missed this in my test case as well, since I ran ``gerbv *.gbr'', forgetting about the .cnc file. I have committed your fix, checked that the output (of ALL files) is correct now, and fixed the test. Thanks for reporting! Thanks for commiting! -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: skpi_drc patch
+ l-no_drc = lookup_attr ((l-Attributes), PCB::skip-drc) != NULL; You want the (already global) AttributeGet() function. l-no_drc = AttributeGet (l, PCB::skip-drc) != NULL; This does assume that the attribute has *some* value, even if the value is the empty string. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
