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=20210112; t=1680287010;
	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=Y06AEqEZM2NDhLbXnwFXdq+ZYCyNptJoiLRZVRmsE8E=;
	b=OGq6PYWNAEa9YruEbmu5eSQROu/HsrlIbV44hjwLffa9WtiQn8dKDu+L76PK3YhSqE
	j54e1qcYiJ2R8lDNNnzPEs3goejFNH9DITGOKxSLdMMwTSbPriUisniY+vaOUmXxgxuh
	67FpiLiit9t0FsqbhlOSwegIlCamRqeaTwrWg19jcuJoUDzKFnUmQTzNQgBLx+wK3KP1
	018k1ckQpFX5tg7oYRVpRm9kLoeruvApzT/+DWXbbMtRYVfTBJSknaT9NGfhXDsDmzEq
	1kELPs3cZtBCS41ZvlVF5thpZRoJapGv0jMGYd55X6KPyFkmS5RLJ+N0MPzuowMxfcqe
	YZgA==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20210112; t=1680287010;
	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=Y06AEqEZM2NDhLbXnwFXdq+ZYCyNptJoiLRZVRmsE8E=;
	b=e35Y0oyLRLg5xKXhvvoUVOMCFKgEwtwVdsJi6hv/dVvqd55i4XDE1/XLdMmOlfg5uT
	ROsrKLYYeVVayARjpGBpc6PageUSsCUWkdqy+aeVkB4aPFzYAJGJyAimy9d7N9iLiFR3
	Yu/gp/eB2LtWSVdgN/TxsbDQ4btTNg4jVBcuBSRyyqs8u3PC2gf9UOAYnegxbHiFao1K
	OQqaGJpMdaBJ8eDGapYrubnfevRvEH1VGWWzR1YP4CFhWkYkOcjHAkoP+DSliSpBTP3J
	AkITtbbcsqrqO1yRVrbI7tSl9P+HRXdo+l6jHqu9wIvtOP8bTPo85Aj+awHoTlwTYskv
	NRAg==
X-Gm-Message-State:	AAQBX9dQYePpTNjz3OTkiFmVTSPsIrJsTGicyOguV3dF7ja1gSPa6BOv
	QWhzDf79Zsx3CWBVzX87TxBYLmO2LGXtulbtHgsObTP6
X-Google-Smtp-Source:	AKy350bBE1YNq6s3b36TFFT40eGW7c8nlSyMkpDSQKDO9CDGipUM79RpmbUk9udvX4jY5RvrBTB3sQGvTKXmGhBk4BE=
X-Received:	by 2002:a17:907:2152:b0:888:b471:8e18 with SMTP id
	rk18-20020a170907215200b00888b4718e18mr13131016ejb.8.1680287010454; Fri, 31
	Mar 2023 11:23:30 -0700 (PDT)
MIME-Version:	1.0
References:	<xncz5nvzvd DOT fsf AT envy DOT delorie DOT com> <0350ae12-d97f-3fc0-f146-c83066c0e695 AT linetec DOT nl>
	<CAJZxidB2RihL-CwFDUuaG9tnkUz-yNeQrRqaFaGZYQKR-c8Tww AT mail DOT gmail DOT com>
	<48f8fe1f-b377-be59-6493-5d61140fdc13 AT linetec DOT nl> <s6nmt4pn5xz DOT fsf AT psjt DOT org> <407d4f7a-f529-b0bd-de4f-39fd357cb7c0 AT linetec DOT nl>
In-Reply-To:	<407d4f7a-f529-b0bd-de4f-39fd357cb7c0@linetec.nl>
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Fri, 31 Mar 2023 10:23:18 -0800
Message-ID:	<CAC4O8c_LeDPsEzBu0tk5YczqkzO_3xeHy-2KCZMsJZDipCZy4w@mail.gmail.com>
Subject:	Re: [geda-user] Connecting pads directly to polygons
To:	geda-user AT delorie DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id 32VIO2Oo016044
Reply-To:	geda-user AT delorie DOT com

On Thu, Mar 9, 2023 at 2:44 AM Richard Rasker (rasker AT linetec DOT nl) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
> Op 06-03-2023 om 18:30 schreef Stephan Böttcher (geda AT psjt DOT org) [via
> geda-user AT delorie DOT com]:
> > Moin,
> >
> > "Richard Rasker (rasker AT linetec DOT nl) [via geda-user AT delorie DOT com]"
> > <geda-user AT delorie DOT com> writes:
> >
> >> - Short circuits are currently not flagged by DRC, but only by
> >>    pressing 'O' (optimizing rat's nest) -- while I'd say that an
> >>    unintended short is certainly a design rule violation. I have in
> >>    fact been bitten by this arguably Very Bad error, when I made some
> >>    last-minute changes, performed a DRC, but forgot to also check with
> >>   'O'.
> > No.  An unintended short in the drawing is not a DRC violation.  Testing
> > the connectivity is not DRC.  A DRC check is independent of the desired
> > connectivity. DRC checks if the manufacturer can reliably implement the
> > layout with the same connectivity as drawn.
>
> Yes, that makes sense.

No, this doesn't make sense.  If you have a near-short and nudge it
such that it becomes a full short it shouldn't disappear from DRC UI
entirely, that's weird and mystifying behavior.  Nor should the UI
entirely ignore it in the first place, at the least a warning about
the DRC behavior should show prominently.  I made a patch to put a
warning like this in a while back, I hope it's still in.

> > Flagging zero clearance of a pad as a DRC error is wrong, even if the connection is undesired.
> Not to put too fine a point on it, but flagging zero clearance is the
> current DRC behavior.
> > I personally prefer if the DRC check tool does pure DRC checks and not mix in
> > connectivity checks.  You may well disagree.
>
> I'm mostly looking at things from a practical point of view. I quite
> often need SMD pads to be fully embedded in copper, but there appears to
> be no convenient way to accomplish this like with through-hole (the
> third thermal option).
>
> The past few days, I was reworking the old design that triggered this
> issue. I tried the 'promiscuous extra polygon' method (i.e. selecting
> the spare layer, drawing a polygon to connect the pad to the surrounding
> polygon, using S to toggle the PolyClear flag, and then M(ove) it to the
> desired layer), but that just causes lots of new real and potential
> problems (adjusting the polygon, avoiding new DRC erros and shorts
> etc.), especially when moving or rotating the component.
>
> Drawing thick lines and Join these to both the surrounding polygon and
> the pad were just as bad.
>
> In summary, I find that polygons and lines with zero clearance are way
> more troublesome than pads with zero clearance, which I think makes
> sense: the component's pads are the focus of the direct connection, not
> any polygons or lines that are separate from that component, and are
> only used as a sort of patch. Also, pads clearly stand out in the
> design, but those 'promiscuous' polygons and lines are completely
> invisible as soon as they're integrated in a layer, and more or less lie
> lurking to cause trouble when making changes at a later time.
>
> So even though it may not be the approved method and triggers oodles of
> DRC errors, I still use the solution with zero clearance for pads -- as
> I find that this is by far the cleanest (at least from my perspective)
> and most convenient method. This is also because surrounding pins and
> lines are automatically cleared with their defined, DRC-compliant
> clearance. This way, I get maximum connectivity on the desired pads
> combined with maximum surrounding copper fill, without any hassle or new
> errors. The only drawback is having to wade through a long list of
> Insufficient (read: zero) Clearance DRC errors to see if there are any
> other, genuine DRC issues, but that is far less problematic.

Yes, this is what I do also after trying other methods and I agree
it's the best.  In the version of pcb I last used it didn't trigger
DRC errors, and IMO it really shouldn't.  What was the exact issue
that required this change?

Britton

- Raw text -