Re: gEDA-user: next PCB release - 1.99za vs 4.0
On Tue, Sep 14, 2010 at 10:34:23PM -0500, John Griessen wrote: > On 09/13/2010 05:07 PM, John Doty wrote: > > > >On Sep 13, 2010, at 2:27 PM, DJ Delorie wrote: > So let me rephrase: Why have seven geometric holes, > >>one for each layer, when we can have one geometric hole applied to the > >>whole composite? > > >My notion is that you need a general mechanism to align objects between > >layers. > > Having such a mechanism, you should then use it universally. If > >you bypass general general mechanisms for special cases, you risk creating a > >mess > where general automation procedures fail in > >those special cases. > > John D has something here -- suppose we start using pcb to model the physical > in > a way that is used to analyze layer stack up alignment of weirdly processed > layers? > For instance layers that get folded and stretch some, and so need alignment > checking? > > Perhaps holes get made in one stroke still, but the via pads need a tolerance > to be able > to hit them close enough to their centers with the drill. Perhaps holes > don't even all > get made in one stroke! I heard about microvias being made with UV lasers > that would be on just a few layers. > Also there is a max feasible aspect ratio to a via hole width vs. its depth > to drill with carbide bits. > Some board makers said they handle this by drilling in from both sides. Take > it a little further > and you make two composites separately drilled, then bond together > > Sure, all of this is far out, but still worth planning for. > I -think- that all these cases are accounted for with: 1. DJ's composite idea 2. Distinct canvas/layer structure with tagging 3. Custom vias At the very least, we're on the right track. For custom vias, we will probably want to allow drills in footprints. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: next PCB release - 1.99za vs 4.0
On 09/13/2010 05:07 PM, John Doty wrote: On Sep 13, 2010, at 2:27 PM, DJ Delorie wrote: So let me rephrase: Why have seven geometric holes, one for each layer, when we can have one geometric hole applied to the whole composite? My notion is that you need a general mechanism to align objects between layers. Having such a mechanism, you should then use it universally. If you bypass general general mechanisms for special cases, you risk creating a mess where general automation procedures fail in those special cases. John D has something here -- suppose we start using pcb to model the physical in a way that is used to analyze layer stack up alignment of weirdly processed layers? For instance layers that get folded and stretch some, and so need alignment checking? Perhaps holes get made in one stroke still, but the via pads need a tolerance to be able to hit them close enough to their centers with the drill. Perhaps holes don't even all get made in one stroke! I heard about microvias being made with UV lasers that would be on just a few layers. Also there is a max feasible aspect ratio to a via hole width vs. its depth to drill with carbide bits. Some board makers said they handle this by drilling in from both sides. Take it a little further and you make two composites separately drilled, then bond together Sure, all of this is far out, but still worth planning for. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: (hierarchy-uref-mangle "disabled") doesn't seem to work when generting a bom
Mike Crowe wrote: > I resolved this issue (given enough time even a monkey can solve his > problems!). I'm posting just for future reference. Did you post a big report? > The separator appears to be important even if it is disabled by > (hierarchy-uref-mangle "disabled") Ouch. Magic characters hitting again? ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: next PCB release - 1.99za vs 4.0
On 12.09.2010 00:20, Peter Clifton wrote: (Can someone who uses / has used keepouts on another package describe for me how they work, or how you use them?) (In our company we are using a 5 year old package that has support for keepouts. It has pre-defined one keepout layer where the user can draw areas/polygons. Such an area can be referred to one or more layer. If an object on one of the referred layers is in that area the user gets a drc error. I, for example, used that for the tracks for the "miniature wave selective soldering". Placed the tracks as areas and assigned the silk and paste (for this board only smt parts had paste layer) layer to it. Now I got errors if I placed parts in the soldering tracks. Copper are allowed because it was covered by solder mask.) Frank. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: (hierarchy-uref-mangle "disabled") doesn't seem to work when generting a bom
Hi all I resolved this issue (given enough time even a monkey can solve his problems!). I'm posting just for future reference. I was using (hierarchy-uref-separator "_") instead of (hierarchy-uref-separator "/") The separator appears to be important even if it is disabled by (hierarchy-uref-mangle "disabled") By keeping the separator as a "/" everything works. I was also wrong to say that the operation was different for gnetlist and gsch2pcb. The operation appears to be the same. On Thu, 2010-09-02 at 15:40 -0500, Mike Crowe wrote: > Hello group > > I am doing my first hierarchial design. In my local gnetlistrc I have > (hierarchy-uref-mangle "disabled") un-commented as I don't want the Sn_ > in the front of the uref. > > gsch2pcb does what I desire and correctly drops the "Sn_" prefix. > > When generating a bom. The prefix is not dropped which is NOT what I > want. > > If I change from > (hierarchy-uref-order "append") > to > (hierarchy-uref-order "prepend") > > The Sn_ value is placed at the end, so gnetlistrc seem to be picked up, > but I'm not sure where as I don't see it in the .scm that I'm using. > > My command line syntax is > gnetlist -g xmlbom circuit.sch -o circuit-bom.xml > > I tried the nomunge option, but it didn't seem to have any effect. > > gnetlist --nomunge -g xmlbom circuit.sch -o circuit-bom.xml > > Yes, I am using a scheme that I hacked from gnet-bom(2?).scm (see > attached). So I'm probably at fault, but I don't know where. > > Could anyone give me some pointers as to what I'm doing wrong? > > Thanks in advance > Mike > > > > > > > > > ___ > 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: next PCB release - 1.99za vs 4.0
On Tue, Sep 14, 2010 at 02:57:31PM -0400, Windell H. Oskay wrote: > > > > I like "canvas" - it's a more popular idiom than cel. > > Indeed it is. > > My concern about "canvas" is that it does not convey a relationship to our > physical layers. In some cases it would be reasonable to expect a "canvas" > to refer a full layer or even to a stack of layers. IMHO, it would be > beneficial if the term chosen connotates "sublayer" rather than layer or > stack of layers. > > Another couple of suggestions: > > - Sublayer > It's straightforward > There are some cases where it doesn't quite make sense - you could have a sublayer mapped to two layers, for example. Plus it sounds too close to "layer" and might be confusing in conversation. > - Sheet > A common metaphor in engineering-- it would make sense if there were > multiple sheets to specify the details of each physical layer. > Anti-copper sheet, digital keep-out sheet, anti-mask sheet, etc. This > name would lend itself naturally to printed documentation for a project. > I really like this. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: next PCB release - 1.99za vs 4.0
> > I like "canvas" - it's a more popular idiom than cel. Indeed it is. My concern about "canvas" is that it does not convey a relationship to our physical layers. In some cases it would be reasonable to expect a "canvas" to refer a full layer or even to a stack of layers. IMHO, it would be beneficial if the term chosen connotates "sublayer" rather than layer or stack of layers. Another couple of suggestions: - Sublayer It's straightforward - Sheet A common metaphor in engineering-- it would make sense if there were multiple sheets to specify the details of each physical layer. Anti-copper sheet, digital keep-out sheet, anti-mask sheet, etc. This name would lend itself naturally to printed documentation for a project. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: next PCB release - 1.99za vs 4.0
I like "canvas" - it's a more popular idiom than cel. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: next PCB release - 1.99za vs 4.0
On Sep 14, 2010, at 7:23 AM, Andrew Poelstra wrote: > On Mon, Sep 13, 2010 at 10:20:52PM -0400, Matthew Sager wrote: >>> [*] We need a better term for drawing layers, since "layer" means >>> something specific in PCB design. Or another name for physical >>> layers. Or something ;-) >>> >> >> How about "overlay"? >> >> "Canvas" comes to mind. It hints that you draw on it. Or this could >> just be the fact that I have a painting that I need to finish. > > Canvas sounds good to me, too. Overlay feels like a more > "circuity" word, but either one would be fine by me. Another good metaphor might be that of the Cel, from hand-drawn animation: A stack of cels makes up a layer? http://en.wikipedia.org/wiki/Cel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote: > On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote: > > XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal. > > I think that using a Lisp (or Lispy-looking) format would be extensible, > > easy to parse, and make the most people happy. > > Allow me to toss out JSON. It is about as light weight as using S-EXP, > but politically it isn't tied down by references to Lisp. Plus, since > it has become fairly popular, there are good readers/writers for most > languages. > > The format is defined at: http://www.json.org/ > Recently I had to implement multiple output formats for a project of mine, including xml, JSON and plist (property list). After that session, for simple trees, I'd prefer plist over JSON. Myabe it's just me but i found it more readable for the human eye (independent of the indentation). Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: next PCB release - 1.99za vs 4.0
On Mon, Sep 13, 2010 at 10:20:52PM -0400, Matthew Sager wrote: >> [*] We need a better term for drawing layers, since "layer" means >> something specific in PCB design. Or another name for physical >> layers. Or something ;-) >> > > How about "overlay"? > >"Canvas" comes to mind. It hints that you draw on it. Or this could >just be the fact that I have a painting that I need to finish. Canvas sounds good to me, too. Overlay feels like a more "circuity" word, but either one would be fine by me. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Phil Frost writes:
> I would point out a valid YAML representation of the above is also:
>
> {pin: {pinNumber: 2, pinName: rst, x1: 1234, y1: 4321, x2: 2345, y2: 4321,
> layer: component}}
> Neither sed nor awk can process XML or YAML the right way in all cases
> without reimplementing a libyaml or libxml in sed or awk.
This one-line form is pretty accessible to sed and awk.
I'd write an awk script that transforms arbitrary YAML into this form,
and include that in any commandline pipe of one-liner processing. At
the next save from PCB it will be back to the original format, so that
subversion diff will happy. I like that format.
--
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Mon, Sep 13, 2010 at 04:25:49PM -0700, Steven Michalske wrote:
> pin:
> pinNumber: 2
> pinName: "rst"
> x1: 1234
> y1: 4321
> x2: 2345
> y2: 4321
> layer: component
>
> or
> 2"rst"<\pinName>1234<\x1>4321<\y1>2345<\x2>5432<\y2>component<\layer><\pin>
I would point out a valid YAML representation of the above is also:
{pin: {pinNumber: 2, pinName: rst, x1: 1234, y1: 4321, x2: 2345, y2: 4321,
layer: component}}
and also:
{pin: {pinNumber:
2, pinName: rst,
x1: 1234, y1\
:
4321, x2: 2345, y2: 4321, layer: compo\
nent}}
A valid XML representation, using a slightly different schema, is:
XML and YAML are equally capable of being made unreadable. Either can be
made more readable by defining a reasonable schema and selecting a
clueful output library.
Neither sed nor awk can process XML or YAML the right way in all cases
without reimplementing a libyaml or libxml in sed or awk.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem : minor beautification
Hello,
This patch place the scrollbars and the drawing area in a table, this prevents
that the scrollbars doesn't intersect in the bottom right corner.
--
Kam
diff --git a/gschem/include/prototype.h b/gschem/include/prototype.h
index 5948c74..c0fc760 100644
--- a/gschem/include/prototype.h
+++ b/gschem/include/prototype.h
@@ -854,7 +854,7 @@ gint x_stroke_translate_and_execute (GSCHEM_TOPLEVEL *w_current);
void x_window_setup (GSCHEM_TOPLEVEL *w_current);
void x_window_setup_gc(GSCHEM_TOPLEVEL *w_current);
void x_window_free_gc(GSCHEM_TOPLEVEL *w_current);
-void x_window_create_drawing(GtkWidget *drawbox, GSCHEM_TOPLEVEL *w_current);
+void x_window_create_drawing(GtkWidget *draw_table, GSCHEM_TOPLEVEL *w_current);
void x_window_setup_draw_events(GSCHEM_TOPLEVEL *w_current);
void x_window_create_main(GSCHEM_TOPLEVEL *w_current);
void x_window_close(GSCHEM_TOPLEVEL *w_current);
diff --git a/gschem/src/x_window.c b/gschem/src/x_window.c
index 07beb6e..485df94 100644
--- a/gschem/src/x_window.c
+++ b/gschem/src/x_window.c
@@ -98,27 +98,20 @@ void x_window_free_gc(GSCHEM_TOPLEVEL *w_current)
* \par Function Description
*
*/
-void x_window_create_drawing(GtkWidget *drawbox, GSCHEM_TOPLEVEL *w_current)
+void x_window_create_drawing(GtkWidget *draw_table, GSCHEM_TOPLEVEL *w_current)
{
/* drawing next */
w_current->drawing_area = gtk_drawing_area_new ();
- /* Set the size here. Be sure that it has an aspect ratio of 1.333
- * We could calculate this based on root window size, but for now
- * lets just set it to:
- * Width = root_width*3/4 Height = Width/1.33
- * 1.333 is the desired aspect ratio!
- */
- gtk_drawing_area_size (GTK_DRAWING_AREA (w_current->drawing_area),
- w_current->win_width,
- w_current->win_height);
+ gtk_widget_set_size_request (GTK_WIDGET (w_current->drawing_area),
+ 160, 120);
- gtk_box_pack_start (GTK_BOX (drawbox), w_current->drawing_area,
- TRUE, TRUE, 0);
- GTK_WIDGET_SET_FLAGS (w_current->drawing_area, GTK_CAN_FOCUS );
- gtk_widget_grab_focus (w_current->drawing_area);
- gtk_widget_show (w_current->drawing_area);
+ gtk_table_attach_defaults (GTK_TABLE (draw_table), w_current->drawing_area,
+ 0, 1, 0, 1);
+
+ gtk_widget_set_can_focus (w_current->drawing_area, TRUE);
+ gtk_widget_grab_focus (w_current->drawing_area);
}
/*! \todo Finish function documentation!!!
@@ -247,7 +240,7 @@ void x_window_create_main(GSCHEM_TOPLEVEL *w_current)
GtkWidget *label=NULL;
GtkWidget *main_box=NULL;
GtkWidget *menubar=NULL;
- GtkWidget *drawbox=NULL;
+ GtkWidget *draw_table=NULL;
GtkWidget *bottom_box=NULL;
GtkWidget *toolbar=NULL;
GtkWidget *handlebox=NULL;
@@ -258,12 +251,16 @@ void x_window_create_main(GSCHEM_TOPLEVEL *w_current)
w_current->main_window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_set_name (w_current->main_window, "gschem");
- gtk_window_set_policy (GTK_WINDOW (w_current->main_window), TRUE, TRUE, TRUE);
-
- /* We want the widgets to flow around the drawing area, so we don't
- * set a size of the main window. The drawing area's size is fixed,
- * see below
+
+ /* Set the size here. Be sure that it has an aspect ratio of 1.333
+ * We could calculate this based on root window size, but for now
+ * lets just set it to:
+ * Width = root_width*3/4 Height = Width/1.33
+ * 1.333 is the desired aspect ratio!
*/
+ gtk_window_set_default_size (GTK_WINDOW (w_current->main_window),
+ w_current->win_width,
+ w_current->win_height);
/*
* normally we let the window manager handle locating and sizing
@@ -275,9 +272,9 @@ void x_window_create_main(GSCHEM_TOPLEVEL *w_current)
gtk_widget_set_uposition (w_current->main_window, 10, 10);
/* this should work fine */
- gtk_signal_connect (GTK_OBJECT (w_current->main_window), "delete_event",
- GTK_SIGNAL_FUNC (i_callback_close_wm),
- w_current);
+ g_signal_connect (G_OBJECT (w_current->main_window), "delete_event",
+G_CALLBACK (i_callback_close_wm),
+w_current);
/* Containers first */
main_box = gtk_vbox_new(FALSE, 1);
@@ -408,51 +405,47 @@ void x_window_create_main(GSCHEM_TOPLEVEL *w_current)
/* Try to create popup menu (appears in right mouse button */
w_current->popup_menu = (GtkWidget *) get_main_popup(w_current);
- drawbox = gtk_hbox_new(FALSE, 0);
- gtk_container_border_width(GTK_CONTAINER(drawbox), 0);
- gtk_container_add(GTK_CONTAINER(main_box), drawbox);
- x_window_create_drawing(drawbox, w_current);
- x_window_setup_draw_events(w_current);
+ draw_table = gtk_table_new (2, 2, FALSE);
+ gtk_box_pack_start (GTK_BOX (main_box), draw_table, TRUE, TRUE, 0);
- if (w_current->scrollbars_flag == TRUE) {
-/*
Re: gEDA-user: Functional blocks and PCB format changes
On 09/13/2010 09:57 PM, Ouabache Designworks wrote: pin: pinNumber: 2 pinName: "rst" x1: 1234 y1: 4321 x2: 2345 y2: 4321 layer: component or 2"rst"<\pinName>1234<\x1>4321<\y1>2345<\x2>5432<\y2>component<\layer><\pin> I call the second large, bloat, and ugly. I would prefer rectangle: type: pin pinNumber: 2 pinName: "rst" x1: 1234 y2: 4321 x2: 2345 y2: 4321 layer: component or pin 2<\pinNumber> rst <\type> ref92134<\basepos> 1234<\x> 4321<\y> <\loc, ID = 12360> <\x> 0<\y> <\loc> <\rectangle> I'm not exactly sure how the referenced position will work out in XML or the first format (yaml?). Time for me to leave the house - so I'm not sure how correct any of this is. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Steven Michalske writes: > Now we may want to write a parser, and emitter, but that is a good > amount of work, to serialize a data structure in the code that could > be output be a data serializer that just works. The emitter shall conserve order and formatting (probably not) or at least be deterministic about it, so that load-save cycles do not screw with the subversion/git/... diffs. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
I prefer: # -*- makefile -*- CSA-L%.sch: CSA-1.sch Makefile sed 's,^\(refdes\|netname\)=,&L$*_,' $< > $@ CSA-N%.sch: CSA-2.sch Makefile sed 's,^\(refdes\|netname\)=,&N$*_,' $< > $@ FSH-S%.sch: FSH-1.sch Makefile sed 's,^\(refdes\|netname\)=,&S$*_,' $< > $@ direna-preamp-P%.sch: direna-preamp-1.sch sed 's,^\(refdes\|netname\)=,&P$*_,' $< > $@ TFlex-34.pcb: TFlex.pcb Makefile sed <$< >$@ '/^Element.*\(c1206\|c0805\|c0603\|CWR11B\)/,/^..$$/d;/^Via.* 400 "" "".$$/d;/Groups/s/1,c:2,3:4:5:6,7:8,s/1:2,3:4,c:5,s:6,7:8/' TFlex-16.pcb: TFlex.pcb Makefile sed <$< >$@ '/^Element.*Omne/,/^..$$/d;/^Via.* 400 "" "".$$/d' -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
