ID: | 3276 |
From: | ge...@igor2.repo.hu |
Date: | Sat, 17 Aug 2019 17:55:15 +0200 (CEST) |
Subject: | [pcb-rnd] pcblib: parametric footprint script switchover |
replies: | 3277 from ge...@igor2.repo.hu |
Hi all, today I've finished switching over our parametric footprints from the obsolete geda/pcb element format to the native lihata subc format. Footprints already placed on a board are not affected. I did extensive semi-automated testing, brute forcing a few values of each parameter of each parametric footprint script, comparing the render of the old to new to make sure there are no differences. Thus an sch->pcb-rnd flow wouldn't be affected by the switchover either: the same footprint string will result in the same footprint generated, copper-wise. Please test parametric footrpints; they should do the same as before. If you see any difference (other than the ones listed below), please mail me the exact footprint string (parameters included) and a short description of the difference you see. There are only a few, insignificant differences that are known and intentional: 1. One of the reasons for the switch was to be able to use the benefits of proper padstacks. In some cases of totally invalid footprints this causes copper difference: the old scripts could not place paste without copper, the new ones can. So if you specify invalid center pad paste patterns that extend far beyond the actual center pad, the old script placed copper+paste (causing shorts), the new script places paste only, as that's what the user requested. Again, this affects only broken *qf*() footprints where the center pad paste pattern is bigger than the center pad. 2. Padstack origins changed: the new utility lib places padstacks faithfully, as the script places them. For example in so(14) the old scripts had padstack origin in the center of pads, so the span between origin and origin was 205mil - not making sense. The new scripts use the outer dimensions, pin-end-to-pin-end (with a minimal margin), resulting in 250mil. This helps us debugging the scripts as the origins will typically match some input dimension or at least some phsyical thing directly calculated from input. Note: this does _not_ affect actual copper/mask/paste geometry, only the little '+' mark of the pad and sometimes some snapping behavior. 3. The new scripts use a new utility lib called common_subc.awk. The old utility script, common.awk is kept because some parametric footprints hosted on edakrill depend on common.awk and I don't want to force those scripts to upgrade. All in all, we did not break backward compatbility even on external parametric awk scripts depending our utility awk script. 4. The new parametrics are not yet shown on the web (repo.hu) footprint generator. I will need to rewrite that script a bit. Until that happens, the old footprints are shown there (but as we are backward compatible, this won't make any diff to the end user, other than new parameters introduced won't be accessible there). 5. While we were writing the obsolete element format, the output could be loaded in geda/pcb. Now with lihata, it won't work any more. But this is not our business, it's something geda/pcb developers could worry about. (I can't recall any geda/pcb user using the output of my scripts in the past 2 years, not even the web version, so it's probably zero loss.) With keeping 100% backward compatibility, we will have some extensions, mainly new parameters controlling aspects of padstacks that were impossible to control with the old format. I will write separate announcements about these when they are implemented Best regards, Igor2
Reply subtree:
3276 [pcb-rnd] pcblib: parametric footprint script switchover from ge...@igor2.repo.hu
3277 Re: [pcb-rnd] pcblib: parametric footprint script switchover: from ge...@igor2.repo.hu
3279 Re: [pcb-rnd] pcblib: parametric footprint script switchover: from ge...@igor2.repo.hu
3280 Re: [pcb-rnd] pcblib: parametric footprint script switchover: from Gabriel Paubert <pa...@iram.es>
3281 Re: [pcb-rnd] pcblib: parametric footprint script switchover: from ge...@igor2.repo.hu