search

pointhi / kicad-footprint-generator

creating kicad footprints using python scripts
GNU General Public License v3.0
186 stars 176 forks source link

Add ipc noLead silkscreen calculator #508

Open rnd2 opened 4 years ago

rnd2 commented 4 years ago

When the custom pin number generator is used pin 1 is in a different location than the expected.

Pin 1 can be in one of the four corners: top left/right and bottom left/right

Add calcsilk(x,y) to calculate the silkscreen line coords.

codeclimate[bot] commented 4 years ago

Code Climate has analyzed commit f7544415 and detected 0 issues on this pull request.

View more on Code Climate.

rnd2 commented 4 years ago

This request is related to #507 and #479.

If #507 is going to be merged first the this PR needs to be rebased to relocate the file silkscreen_calc.py to util.

When this PR is merged #479 can be merged (after a rebase) too.

rnd2 commented 4 years ago

A few examples to demonstrate:

For num_pins_x = 0,

left: cw_dual generator right: ccw_dual generator, start = 'bottom_right'

For num_pins_y = 0,

left: cw_dual generator, start = 'bottom_left' right: ccw_dual generator, start = 'top_right'

cpresser commented 4 years ago

Question: in the F.Fab layer the Pin1 marker does not match the silkscreen marker. Why?

evanshultz commented 4 years ago

This is what is shown for IPC 7351 and built by the generator. See https://ocipcdc.org/archive/What_is_New_in_IPC-7351C_03_11_2015.pdf#page=19 for an example of the silk and the fab is the historical way IPC docs have shown pin 1, though I don't see an example if that doc.

rnd2 commented 4 years ago

Question: in the F.Fab layer the Pin1 marker does not match the silkscreen marker. Why?

You are right. The fab layer must be changed too.

Should I push more commits here to address this or make a new PR just for (F/B).Fab layer?

evanshultz commented 4 years ago

Sorry for my stupid comment earlier. I didn't understand at that time all that was going on. I vote to push more commits here, otherwise MASTER will be able to generate footprints that have known issues. A squash merge can be used to keep history clean so there's no issue.

rnd2 commented 4 years ago

Ready for merging,

top_lefttop_right

bottom_leftbottom_right

cpresser commented 4 years ago

Another question: KLC F4.2 says Pin1 should be top left (https://kicad-pcb.org/libraries/klc/F4.2/). All the above examples could be rotated to full fill that requirement. Is that something that should be addressed as well?

rnd2 commented 4 years ago

The defaults are set so that the resulting footprint is conforming with KLC. The rest is just for completeness.

rnd2 commented 4 years ago

For some background info.

This all started so that the generator could generate the footprint for DMR0004A (http://www.ti.com/lit/ml/mpss084/mpss084.pdf).

For an unknown reason Texas decided to use non-standard numbering. I had a look in the datasheets for all SON packages from TI and this is the only one that uses counter-clockwise numbering.

evanshultz commented 4 years ago

@cpresser is right that the footprints don't conform to KLC since pin 1 is not in the top left (orientation A). Are you willing and able to update this PR to address that? While I haven't tried using this part of the framework myself, I believe https://github.com/pointhi/kicad-footprint-generator/blob/master/KicadModTree/nodes/specialized/Rotation.py may make this easy.

We can merge this anyway and Rene can clean up https://github.com/pointhi/kicad-footprint-generator/pull/507 later.

evanshultz commented 4 years ago

@cpresser What do you want to do with this? I quickly looked at just the changed file (not the new one) and I'm not thrilled with some variable names but it is a needed fix. The custom pad generators are in the script right now but they don't work as expected without this code (and then the further footprint rotation fix for pin 1 location). Thoughts?

cpresser commented 4 years ago

I looked at DMR0004A (http://www.ti.com/lit/ml/mpss084/mpss084.pdf) to understand the problem. Disclaimer: I have not yet looked at this problem in Detail.

My first idea how to solve this would be to patch the pin-number-generator. Or introduce a new one. How about adding a property

pin_numbers: [1, 4, 3, 2]

The generator iterates that list and just yields one number after another. If we ensure that the list always starts with 1, no changes to component orientation, Silkscreen and F.Fab are required. That will reduce the amount of code needed significantly.

rnd2 commented 4 years ago

Hi @cpresser , did you have a look at the first PR for this (#371). Initially I had the following properties:

pad_numbers_top: [1, 4] # left to right
#pad_numbers_right: [5, 6] # top to bottom
pad_numbers_bottom: [2, 3] # left to right
#pad_numbers_left: [8, 7] # top to bottom

Later on that PR there was a suggestion to use a generator instead, which was then merged.

It won't be too difficult to add a generator that yields the items of the property.

cpresser commented 4 years ago

Hi @cpresser , did you have a look at the first PR for this (#371). Initially I had the following properties:

I was not aware of that. Thanks for the hint.

It won't be too difficult to add a generator that yields the items of the property.

Sounds good to me. But that seems to simple given. Is there another angle to the original problem not solved by this? It feels like I am missing something.

evanshultz commented 4 years ago

I don't think pin 1 has to be the first pin as the entire footprint can be rotated as I mentioned above. I haven't tried this, but it looks from the documentation that it would work.