andete / madparts

A functional footprint editor.
GNU General Public License v3.0
80 stars 8 forks source link

Added ability to specify the solder mask swell and paste ratio per pad. But only for KiCad. #104

Closed metacollin closed 8 years ago

metacollin commented 8 years ago

Both the smd and pad types now have two more members, @mask_swell and @paste_ratio. They default to 0.0 and 1.0 respectively, which is what madparts specifies anyway, albeit by omission.

It's relatively quick and dirty, but I desperately need this feature. I am working on a set of automation tools that use madparts to generate footprints procedurally en mass, but many footprints require more details than is currently achievable with madparts. Don't get me wrong, madparts is awesome. But, just as an example, QFN footprints require 1:1 paste ratio on the pads, but a 0.5 to 0.6 paste ratio on the thermal pad, otherwise the part will 'float' on a solder blob during reflow, causing the part to potentially misalign or not solder down on one side. Additionally, let's say it's a 0.5mm pitch QFN footprint. There must be exactly 0.076mm of solder mask swell around the pads, but no solder mask swell around the thermal pad. Meaning the pads are copper defined, but the thermal pad is mask defined.

These are specified by the JEDEC QFN standards, so without the ability to specify mask swell and paste ratio per pad, madparts cannot actually generate JEDEC compliant QFN footprints, and many others that also require fine-tuning mask swell and/or paste apertures.

This does probably need to be fleshed out, but this certainly is a quick and dirty start. I will try to work on it further soon (unless you decide to before then of course). Just busy at the moment so this is quicker and dirtier than usual.

Oh, I also 'fixed' (really, it's more of an opinion than broken or fixed) the code formatting in the kicad export python file, it is now PEP8 compliant (go ahead, check it with a python linter - I believe it is perfect now!). I certainly don't mean to tell you how to style your own code, it's just I actually couldn't figure out the if/else structure in the pad function as it was indented (just too many nested things for my brain to handle) so I correctly indented everything ('correct' according to the PEP8 style guide anyway - https://www.python.org/dev/peps/pep-0008/ ) and figured I might as well go all the way.

andete commented 8 years ago

Hello metacollin. Thanks for the nice work. I did not know yet about this new kicad feature, very interesting I could use that as well :) I'm low on time to work on madparts lately though. I'll try to fit in a review soon though. About the PEP8 style, I'm just a casual python programmer, (And lately almost completely switched to rust...) so I didn't really consider any specific style. I'm happy with formatting fixes as long as they are not combined with code changes as well.

metacollin commented 8 years ago

D'oh, you're right, I definitely combined formatting fix with a code change, and it didn't occur to me that this would completely ruin the ability to see the actual code changes in the diff. Here, I am going to reverse that and simply add the code changes, now that its written, and may do the style change as a separate commit, though I dunno if its worth it.

Also, madparts is honestly pretty much 'done', it seems like a very polished and feature complete tool and it just works. The addition of solder mask swell and solder paste ratio is the only thing that even comes to mind as missing. I also understand not having enough time to spend on a project, or even support a finished tool, that's every other week for me. Don't waste any time looking over this pull request until I make it easy to see the changes. I added 4 lines I think hehe.

Also, long ramble on styling that you can ignore if you don't care. It's not a lecture or anything, just my own experiences, as I completely shunned that sort of thing for 10+ years:

I'm a casual python coder too. In fact, the only time I write python is usually because I'm playing with something someone else wrote in it heh. I'm mostly a big fan of code linters - for years I couldn't have cared less if indentation was proper or consistent code styling or any of that, it seemed like just a lot of obsessive compulsiveness and needless attention to something ultimately cosmetic.

I finally got it when I had to go through some code I wrote 10 years ago and had totally forgotten about. My code then was just as 'unstyled' as 10 years ago, but what I was missing is that when it is your own code, and you remember how it works, then you can just see around any indentation weirdness or whatever because you still remember the logic behind some really nested control structure, or the structure of a class, or what have you. The moment that is truly forgotten about code you wrote, code you haven't even looked at for years and years, you realize how and why it matters. It's the same if looking through others' code. Without that personal knowledge of the code, you're suddenly forced to mentally parse code, rather than simply read it. If that makes sense. Code you wrote is code you have a good idea of how it works and what it does. Forgotten code or other people's code, you have no idea, and all those little formatting style guides etc. for each language are not just about making it look pretty, but about giving code consistent cues that make it much easier to 'parse' by people.

That said, I totally have never gone back and cleaned up any of my old code haha. I've simply started using linting with new code though. If you use vim or sublimetext or any sort of extensible editor, it is relatively easy to set up live linting, which will note style errors in much the same way misspelling is denoted in word processors/internet forms, and move your cursor to it to see what is specifically wrong. Many linters actually will autocorrect the code for you as you type it. I am not specifically a fan of PEP8, it just has the best linter =P.

Anyway, sorry, I'm not lecturing you or anything. I personally found a lot of use and value in this kind of thing despite years of dismissing it, so I just wanted to share my experience with another programmer, but there is nothing wrong with not using a linter or code style etc. and just because I found it worth doing doesn't mean someone else will.

metacollin commented 8 years ago

OK, it's now fit for review. As you can see, it is hardly a massive amount of code hahaha. However, madparts doesn't run on newer versions of OS X without the PIL line change. I am not sure why. Python dependency stuff confuses and frightens me

andete commented 8 years ago

Merged. Thanks for contributing!