Re: gEDA-user: new footprint guidelines
On Sep 30, 2010, at 7:00 AM, Armin Faltl armin.fa...@aon.at wrote: Yes and No. The number of practical orientations a board and part can have are very limited, but to check them, until now a human will be involved. True automation readines requires that you can feed the file into the machine, the machine knows, where it's fixtures are and therefore will correctly transform design positions to machine positions without manual intervention. The operator just has to follow the rule, that the (0, 0) marking on the board (to be invented) has to be at the fixture with the red dot. To help everyone involved, I include 'TOP' and 'BOT' in my copyright notices, written in copper. My current board isn't square, but then I could state, that the baseline of the copyright is parallel to X-axis in the XYRS file. Would registration marks help with this? Three points forming approximately a 90 degree corner. Would give the ability to detect +x,+y I know our smt lines heavily depend on these marks. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: new footprint guidelines
On Sep 30, 2010, at 7:43 AM, Rick Collins gnuarm.2...@arius.com wrote: Trouble is that the machine doesn't know how the parts are oriented in the feeders. Rather than trust that the system works if they get each piece right, they manually run through an sample of each component type to make sure it is placed on the board right. That is all they care about and you only do this once for a given board. They call this setup and charge a couple of hundred dollars for it. Not enough of a charge to worry about and it gives them a warm fuzzy feeling that they aren't screwing up. I know that the newer placement machines have cameras to detect orientation of the parts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: new footprint guidelines
On Sep 30, 2010, at 7:43 AM, Rick Collins gnuarm.2...@arius.com wrote: they manually run through an sample of each component type to make sure it is placed on the board right. That is all they care about and you only do this once for a given board. They call this setup and charge a couple of hundred dollars for it. Not enough of a charge to worry about and it gives them a warm fuzzy feeling that they aren't screwing up. My favorite is when they place the parts onto the boards with double stick tape and measure each part by hand. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb-20100929 released
Great!
Now let me suggest some kind of Patchlevel 0.
Most of these patches deal with well-known issues
discussed on the list or on the tracker; some of them
are years old.
Of course, there are lots of more patches e.g. on the tracker;
I just randomly picked some obvious ones that were not likely
to cause strong objections.
The developers have no resources to push them into master;
however, the users could collect them and release inofficially.
If somebody is interested, we could discuss what we want
to be included, and what we don't; if nobody is interested,
I'll just stack more patches than otherwise expected and
use them locally.
Best wishes,
Ineiev
From 9b8d3cda761b1a719d10768cd34d4908c70023a5 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Sun, 12 Sep 2010 08:14:14 +
Subject: [PATCH 01/12] RectPoly: check arguments to avoid empty polygons
fixes PCB segfaults when running DRC #3064413
---
src/polygon.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/polygon.c b/src/polygon.c
index 586e8cc..72e65d5 100644
--- a/src/polygon.c
+++ b/src/polygon.c
@@ -330,8 +330,8 @@ RectPoly (LocationType x1, LocationType x2, LocationType
y1, LocationType y2)
PLINE *contour = NULL;
Vector v;
- assert (x2 x1);
- assert (y2 y1);
+ if (x1 = x2 || y1 = y2)
+return NULL;
v[0] = x1;
v[1] = y1;
if ((contour = poly_NewContour (v)) == NULL)
--
1.6.5.2
From 1e25441acaa40ceff0518e71b6d5f87cbc322bb8 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.sourceforge.net
Date: Fri, 20 Feb 2009 20:19:01 +0300
Subject: [PATCH 02/12] misfix annoying decimals bug 1741659
bug report by Kai-Martin Knaak
also make polar coordinates less verbous
---
src/hid/gtk/gui-misc.c | 88 ++-
1 files changed, 63 insertions(+), 25 deletions(-)
diff --git a/src/hid/gtk/gui-misc.c b/src/hid/gtk/gui-misc.c
index a607a69..5ffbbd6 100644
--- a/src/hid/gtk/gui-misc.c
+++ b/src/hid/gtk/gui-misc.c
@@ -1,10 +1,8 @@
-/* $Id$ */
-
/*
*COPYRIGHT
*
* PCB, interactive printed circuit board design
- * Copyright (C) 1994,1995,1996 Thomas Nau
+ * Copyright (C) 1994,1995,1996,2009 Thomas Nau
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -42,8 +40,6 @@
#include dmalloc.h
#endif
-RCSID ($Id$);
-
#define DEFAULT_CURSORSHAPEGDK_CROSSHAIR
#define CUSTOM_CURSOR_CLOCKWISE(GDK_LAST_CURSOR + 10)
@@ -549,6 +545,53 @@ ghid_set_status_line_label (void)
ghid_status_line_set_text (text);
}
+/* returns an auxiliary value needed to adjust mm grid.
+ the adjustment is needed to prevent ..99 tails in position labels.
+
+ All these are a workaround to precision lost
+ because of double-integer transform
+ while fitting Crosshair to grid in crosshair.c
+
+ There is another way to fix: report mm dimensions with %.3f, like
+ in the Lesstif hid; but this reduces the information
+ */
+static double
+ghid_get_grid_factor(void)
+{
+ /* when grid units are mm, they shall be an integer of
+1 mm / grid_factor_per_mm */
+ const int grid_factor_per_mm = 1;/*min grid is .1 um PCB unit*/
+ if (Settings.grid_units_mm)
+return floor (PCB-Grid * COOR_TO_MM * grid_factor_per_mm +.5) /
+grid_factor_per_mm;
+ return 0;
+}
+/* transforms a pcb coordinate to selected units
+ adjusted to the nearest grid point for mm grid */
+static double
+ghid_grid_pcb_to_units (double x, double grid_factor)
+{
+ double x_scaled = (Settings.grid_units_mm? COOR_TO_MM: 1./100) * x;
+ double nearest_gridpoint;
+
+ if (PCB-Grid 4.5)/*nothing to adjust: the grid is too fine */
+return x_scaled;
+ /* adjustment is not needed for inches
+ probably because x/100 is always 'integer' enough */
+ if (!Settings.grid_units_mm)
+return x_scaled;
+ nearest_gridpoint = floor (x / PCB-Grid + .5);
+ /* honour snapping to an unaligned object */
+ if (fabs (nearest_gridpoint * PCB-Grid - x) 1)
+return x_scaled;
+ /* without mm-adjusted grid_factor
+ (return floor (x / PCB-Grid + .5) * PCB-Grid * COOR_TO_MM),
+ the bug appears for 0.1 or 0.05 mm grid at coordinates more than 4000 mm.
+ grid_factor makes the stuff work at least up to 254 m,
+ which is 100 times more than maximum board size as of Aug 2010. */
+ return nearest_gridpoint * grid_factor;
+}
+
/* ---
* output of cursor position
*/
@@ -556,32 +599,27 @@ void
ghid_set_cursor_position_labels (void)
{
gchar text[128];
+ int prec = Settings.grid_units_mm ? 4: 2;
+ double grid_factor = ghid_get_grid_factor();
if (Marked.status)
-{double scale, dx, dy, r, a;
- scale = Settings.grid_units_mm ? COOR_TO_MM: 1. / 100;
- dx = (Crosshair.X - Marked.X) * scale;
- dy = (Marked.Y -
Re: gEDA-user: pcb-20100929 released
I suggest we give this release a few weeks stress-test, then do another late October, focusing on bug fixes. I'd like to make it build for windows much easier too. After Oct 17th I'll have more time for it anyway. Perhaps frequent patch releases on this source base would make sense. Every 2-3 months? We can continue with the pcb-MMDD scheme for now, until we've dealt with a majority of the known bugs and old patches in the trackers. Big changes (i.e. redesigns and new features) should be done in git branches, tested, released as alpha, then merged just after a patch release. When enough big changes accumulate, we release pcb-4.0.0 and switch to the pcb-major.minor.patchlevel scheme. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: new footprint guidelines
Steven Michalske wrote: Would registration marks help with this? Three points forming approximately a 90 degree corner. Would give the ability to detect +x,+y I know our smt lines heavily depend on these marks. Steve I think registration marks help a lot. Attached you find my favourite mark, that regrettably can't be converted into a footprint, because it contains polygons. It's very good for machine vision, gives sub-pixel accuracy. Since they allow to measure board manufacturing distortions, I'd eventually place 3-4 marks along each side. Using different marks to indicate axes. regmark.pcb Description: application/pcb-layout ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Zero length pins
On Sep 28, 2010, at 7:25 PM, kai-martin knaak wrote: One of the things that attracted me to gEDA years ago was how clean and concise the documentation was. Coincidently, some of the my most frustrating experiences with geda/pcb were due to a lack of readily available documentation ;-) You and I have very different ideas of what constitutes good documentation. If I'm visiting a new country, a map is far more useful that a book of narrative directions to get from place to place. Give me a little narrative to get me started, then give me a map and let me figure it out. That's the high productivity route, and I'm tremendously grateful that gEDA, bucking the trend to comfortable fritterware, supports it. Fortunately, gEDA isn't commercial software, so user comfort can have lower priority than productivity. Works fine with UTF-8 characters, although I don't know how to make it work right to left or top to bottom. Well, Hebrew left to right is like Latin script written backwards. Sure. I worked on an early Hebrew/Arabic document processing system in the 1970's. It's unclear how to do that within gEDA and its underlying graphical tools. Also, try to make auto number use Japanese digits... Except that Japanese engineers don't use kanji for that purpose anyway. Writing R三 for a refdes would be like Rthree in English. Japanese would use R3. Is there any engineering culture that uses a system different from the latin-arabic system commonly used for this like this? Multi line text cannot be centered or flushed to the right. Fancy word processing features should not be included in a schematic drawing program. They are a distraction. Text alignment is hardly fancy word processing. Decent looking comments are a requirement when it comes to incorporate a schematic in public documents. Think PHD thesis, presentations, manuals, proposals... I import gEDA graphics into TeX for this purpose. Let gEDA do what it does best, let TeX do what it does best. Support for unusual graphics does not belong in gschem. They can be imported in the rare cases they are needed. A company logo is not exactly a rare case. Also, publication quality symbols are more like fonts than like stick drawings. But gEDA supports the import of graphics, so you can do this. Well, I just drew the following, which would claim is impossible: Well, an imported pixel format does not exactly fit to the workflow of an otherwise completely vectorized suite. But that's inconsistent with your view above. If I want my company logo on a schematic, I must import pixels: it's based on an astronomical image. Similarly, the stick drawings you complain about are a consequence of using a vector format. For example, printing to PDF via cups-pdf barfs on PNGs. But export of graphics to PS works pretty well in gEDA. Specialized tools need not and should not support every graphics format. There are plenty of graphics conversion tools. Real flexibility would allow to include vector graphics and/or a way to do formulas. The way xfig incorporates LaTeX may be worth a closer look. That's real *inflexibility*. gEDA should work with tools like LaTeX without any specialized connection. Users should not be required to use LaTeX, make, or any other specific tool, but should be able to easily get gEDA to cooperate with these tools, and others, if they fit their flow. 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
