Support generating two-terminal footprints with IPC density argument #439
Conversation
- File renames to remove 'chip' if file contained more than chip info - Aligned size definition file names - Print part type and definition during execution - Corrected descriptions and keywords in SMD_chip_devices.yaml - Fixed a few typos in comments
- Branched on top of pointhi#438
|
Code Climate has analyzed commit 3189413 and detected 4 issues on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
| parser.add_argument('--force_rectangle_pads', action='store_true', help='Force the generation of rectangle pads instead of rounded rectangle (KiCad 4.x compatibility.)') | ||
| args = parser.parse_args() | ||
|
|
||
| # if the user requests an IPC density, put that and footprint suffix in a list | ||
| # otherwise, use nominal density with no suffix | ||
| if args.ipc_density is None or args.ipc_density not in ['l', 'L', 'n', 'N', 'm', 'M']: |
There was a problem hiding this comment.
| if args.ipc_density is None or args.ipc_density not in ['l', 'L', 'n', 'N', 'm', 'M']: | |
| if args.ipc_density is None or args.ipc_density.lower() not in ['l', 'n', 'm']: |
There was a problem hiding this comment.
I think there's an even better way to do this. I believed this could be improved but my brain was feeling worn out as I mentioned above; hopefully now inspiration has struck.
|
You might have done something wrong with git here. The list of changed files looks strange. Edit: this might be the result of merging combined with the original branch being different to master. Will simply mean that we need to check this locally with better difftools than github. Plus it will need to be squash merged as it will otherwise make the git history horrible. |
|
Also a general thing: The size definitions used for this script are massive compromises as these sort of devices are not really standardized. I am therefore not really sure the official lib will benefit from having other densities of these footprints in it. I am however not opposed to adding this feature to the script to allow users to generate their own set of footprints with differing density levels (really only makes sense if the user then also adds their own size definition fitting their device) |
|
@evanshultz while looking at #438 I also found this PR. The history of this one looks broken. I think its best to fix this branch after #438 is merged. |
|
@cpresser |
Fixes #421.
Branched from #438. Merge that PR first!
This adds a parameter to support IPC density settings. If the user does not enter a value for the density, nominal density is assumed and footprints are generated exactly as they are now (or, rather, would be if the aforementioned PR is merged). Giving an argument to this parameter generates footprints with correspondingly bigger or smaller pads and a suffix on the footprint name which indicates the density.
It appears the density is used during pad calculation for the handsolder footprints and I've left that alone since it gives further options for handsoldering pads. Or, those footprints can be discarded if the density argument is given and only the non-handsolder footprints added to the library. That would be my expectation.
I feel like there might be a better way to sort out the density during argument parsing than what I added at the end of
SMD_package_rlc-etc.py, but my brain feels empty now so I may need to come back to this later. Or get suggestions.I also renamed the function
TwoTerminalSMDchip()toTwoTerminalSMD()because the script can generate non-chip footprints.