X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713438678; x=1714043478; darn=delorie.com; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pgs3F3NIWK1gpO51oNKhZvociZAUHF4jw7/rvihV4xo=; b=AlSxUquh+vZCHo20e5JnaGATvuetKeGELEVNrfItoREVUuZX7KDdHx+k3sbPFa0p+B 2nXwDY+340FSeGjcALnK4skID1ZQjDhG3Wexp4ZPGGVK37hg4hBRZu7xmsGISgGDShiE KNCluKvBrMc8fyZZrMGbKaP9qjysyA5/g3cTo7iJ8ddDLSa1J4lXM+RuBc7AJULj4gmf 6C3VO1cdYlT5lOu+sTM16Ba14zguIYk5hrjUfUhE3xdtNiLuo1YQgDRQYwFqAu+lMdQh BwbLvBu26AJyVF1GCvQywYpBpHTf/NIaAl7Zn93XqSiq9v1Tvjh4jrIbD0zz+gd7qV77 x5sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713438678; x=1714043478; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pgs3F3NIWK1gpO51oNKhZvociZAUHF4jw7/rvihV4xo=; b=oJEOWuc/CBkINckCVGNevVpqXlfHyVS0ctiYv+BKhoZMuNbuZpJfDd0y6TQAv0bpBq sfBVzgNeb4DqY2cS/Jo84gOGbZD0n7BFeb0wf5rYAOqE/vKfYP3gPmzpxZTBqD9l6Jbz wBnIUjJq1s++0v+wQEfh1Lr5DlizgvVp7cNU5BjpA/mR+lshjhFOfxxN+Ro1wKCu7swZ E8/hdE+hbcGn3Tbi8jU0Ww1oVD7e1acrFBLkw3dtYhpQrACIEeJxlmcP/P/+/I2kbfCK e5qVJtoXjPQBFbtSHBiwu8tGa2klgQTuM8N1vN0XKKVRNVBtUMNUzodkDg8Kcj76dCF+ QELQ== X-Gm-Message-State: AOJu0Yxap/4j14hgwco74YzsALcxv4UBg0pJJNvS+aGAU0ZE5V/tC3Df y13xyREk+ETJMzA+BZAtRhAISK4jPMP9s24OLYWWa4s1zJbuTkVIs0HNxJ63DGXP/7FNJQNo4v1 aKPNvglu0D7VB4MihYwhP2oj1gpknaA== X-Google-Smtp-Source: AGHT+IGKp4vFBbCwVyO4x9XhAI+EXXvU9yV5hghJLmTL4DFNsVKIoqie7U69BHG09eIX0DQb5wsq9pqRMTPgo2vbecs= X-Received: by 2002:a17:906:1353:b0:a55:6ad9:3cbb with SMTP id x19-20020a170906135300b00a556ad93cbbmr1588629ejb.26.1713438678146; Thu, 18 Apr 2024 04:11:18 -0700 (PDT) MIME-Version: 1.0 References: <7d9c541bc1c2c214b65906e0389b4eb6d26fbc1e DOT camel AT gmail DOT com> In-Reply-To: <7d9c541bc1c2c214b65906e0389b4eb6d26fbc1e.camel@gmail.com> From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" Date: Thu, 18 Apr 2024 04:11:06 -0700 Message-ID: Subject: Re: [geda-user] Allowing pins/pads with zero clearance to contact polygons To: geda-user AT delorie DOT com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 43IBBMKb3552791 Reply-To: geda-user AT delorie DOT com On Thu, Apr 18, 2024 at 3:29 AM Onetmt (onetmt AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > > > Il giorno mar, 23/01/2024 alle 20.52 -0900, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] ha scritto: > > A while back there was some discussion here about different ways of > connecting pins/pads to polygons (e.g. ground pads to ground plane). > At least some people like to do this by setting the clearance for the > pin/pad to zero, then simply drawing the ground plane over the part. > It's a nice way to do it because it removes the need to have little > hard-to-select traces everywhere to connect e.g. ground pins to ground > plane (which in turn makes it much less painful to move parts around > after the fact. > > > Yes, please, keep the zero clearance feature working - my last 10 years projects rely on that :-) I've fixed this in my private mini-fork but I don't know if there's any appetite to merge it into anything official. Britton > > > This used to work without any DRV violations, but a fix to the polygon > clearance tests by Charles Parker in de49a513 seems to show that it > only ever worked by accident. > > However the current code in master contains this code that explicitly > allows zero-clearance vias to contact polygons: > > case VIA_TYPE: > if (clearance == 0) > { > /* Vias with zero clearance are allowed, make sure it's connected. */ > if (obj_touches_poly(&thing1, polygon, GetLayerNumber(PCB->Data, layer))) > break; > else > { > /* not connected to the polygon, raise an error*/ > new_polygon_not_connected_violation (layer, polygon); > break; > } > } > > I think this same condition should apply to PAD_TYPE and PIN_TYPE objects as > well, because it's essentially correct to take zero to mean zero, and incorrect > to do otherwise. > > What I don't agree with is the subsequent requirement that the object touch the > nearby polygon, for the following reasons: > > * It adds significantly more meaning to clearance == 0 than that setting > explicitly states > > * As implemented it triggers on nearby polygons that aren't meant to be > connected > > * As implemented the message doesn't make clear what the problem is (refers > only to flag and doesn't mention clearance) and gives a wrong prescription > for the case of a nearby polygon that isn't supposed to be connected. > > * It doesn't catch thin connections (as happens for DRC elsewhere) anyway > > * Complete misses with polys that are supposed to be connected are caught by > connectivity anyway > > Changing this to honor the literal meaning of clearance == 0 while not adding > any unexpected implicit meaning would be fairly low-risk: it wouldn't change > any existing board, and would only impact users who have deliberately set > clearance to zero. So far as I know none of the available footprint libraries > ship footprints with clearance set that way by default. > > Thoughts? > > Britton