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: <0350ae12-d97f-3fc0-f146-c83066c0e695 AT linetec DOT nl> <48f8fe1f-b377-be59-6493-5d61140fdc13 AT linetec DOT nl> <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]" Date: Fri, 31 Mar 2023 10:23:18 -0800 Message-ID: Subject: Re: [geda-user] Connecting pads directly to 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 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] 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]" > > 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