Pin socket

[SchrodingersGat]

This PR moves the Socket Strips across from the Socket_Strips repository.

• Separated into folders based on pitch
• Renamed to match new convention

When this is merge I shall mark the Socket_Strips repo as not accepting any new PRs

[poeschlr]

1mm pitch version is missing.

[SchrodingersGat]

Yep, these footprints have not been created

[poeschlr]

So we have them for pin headers but not for socket strips? That is kind of strange. But ok we can only transfer what is there.
@Shackmeister you created these. Care to add the 1mm version as well?

[Shackmeister]

@poeschlr I no its kinda strange, I was working on the pinheader scripts (as you probably remember) and suddently needed the 1mm headers at work. I wanted to overhaul the socket script before making those.
@terjeio has been making new socket models, and might be working on the footprints?
in case not Ill be happy to take a look at the socket footprints and also add the 1mm strips

[terjeio]

@Shackmeister The footprints should be updated, they are script generated and I have been looking for the script that has been used to make them in order to remove offset and rotation.

No luck yet, see Issue #9 for the socket strip models

[Shackmeister]

Hi @terjeio I added a comment in the link you provided, that should fix it.
should I fix the offset etc or would you like to do it?

[terjeio]

@Shackmeister I am not sure it is so simple, see this comment I made earlier

The best option would be to track down the script used to generate the footprints because there has been other changes made as well - maybe by @jkriege2 knows where it can be found

[Shackmeister]

this part was simply getting the script running.

These are the scripts which has been used for the footprint.
The problem is a lot of changes have been done using other python scripts and text editors in order to fix KLC errors. (even the pinheaders have been renamed now which was done with a seperate script)
Getting this script up and running with up to date standards is gonna take a while.
I spend 1 or 2 weeks on the pinheader script, which is why I have postponed this for some time :)
if you are up for the task Ill be happy to ask you, otherwise I can make it sometime hopefully not too distant in the future

[terjeio]

@Shackmeister maybe we should wait until @jkriege2 responds? It was he that commited the last PR for the footprints so hopefully he knows the whereabouts of the script used.

Script generated footprints and models should contain a link back to the script used, at least in the PR comments, in order to avoid issues like this.

[antoniovazquezblanco]

I have never used the generation scripts and I don't know if it possible to insert comments in the model files themselves but maybe having the file with the name of the generator inside is a good option.

[SchrodingersGat]

It should be sufficient to add an entry into the README.md file. For large batches of scripted items, you can have:

• Author
• Link to script
• Date generated
• Any special notes

This is how it is managed in packages3d / packages3d-source

[jkriege2]

Hi!

have a look at the original PR: KiCad/Socket_Strips.pretty#6 My scripts have been linked there. The PR for the scripts is: pointhi/kicad-footprint-generator#18 ... i.e. they are part of @pointhi 's kicad-footprint-generator repo ... but I have no clue what was changed after that without adapting these scripts!

The only way to link the scripts would be by adding the link to the description field, which ist usually not that easy to do, as the script-PR is typically merged only AFTER the footpritns have been merged ... so only the PR could be linked!

JAN

[terjeio]

Ok - so how to fix this?
The script in question does not run so it cannot be the one that has been used to create the footprints.

Should it be fixed so it generates exactly the same footprints as the KLC compliant version in the repository and the modified to add the 1mm sockets and match my script generated models?

[Shackmeister]

@terjeio I just had a look at my commit back when I rewrote the pinheader part. Apparently I was the one who made the script unrunable, sorry, my bad.

I dont think the script needs to make footprints exactly like the ones in the repo, but they should comply with KLC. I also think the parameters could use an update

[poeschlr]

I think adding a readme at the library level should be sufficient. In my new footprints i added the phrase: generated with kicad-footprint-generator to the end of the description field. (This should make it really clear to everyone that these are in fact script generated footprints.)

[terjeio]

@Shackmeister I can have a go at it but I do not know how long it will take. The code for drawing the lines isn't exactly easy to follow with all the math involved but the framework looks good to me.

Which parameters did you think of? For 3D rendering?

As a side note: it would be nice to be able to drag&drop a footprint file into the footprint editor or an easy way to reload...

@antoniovazquezblanco Adding a link to the script in model files is possible, I have done so by including it in the license text in the header

[terjeio]

Why didn't I check the pin headers? This since the core code is shared with the socket strips. I believe @DASFrank has the updated script...

[Shackmeister]

DASFrank is my work account, pretty sure he doesn't have any updated script. But I can probably make it

[terjeio]

@Shackmeister Oh well, complete confusion for me then. The core script has been recently updated
for the pin headers - you did that? And by modifying footprint_scripts_pin_headers.py?

[Shackmeister]

yes I did that, I found some errors in the way some of the silkscreen was handled when making the 1mm header.. therefore the changes in kicad-footprint-generator/scripts/tools/footprint_scripts_pin_headers.py

I also made some changes in kicad-footprint-generator/scripts/pin-headers_socket-strips/make_pin_headers.py
which was simply to add the new distance between the pads

[terjeio]

@Shackmeister ok, so you have the updated scripts after all. The scripts int pointhi's repositiory was last changed in july and does not contain code for the 1mm headers. Or am I completely lost now?

[Shackmeister]

@terjeio I can see why its pretty confusing.
I have made a PR for Pointhi's repo a little over a week ago
pointhi/kicad-footprint-generator#72

[terjeio]

@Shackmeister ok - thanks, that was pretty obscure for me.

Now I have to find out how to apply this PR or extract the updated files - I have downloaded the repo as a zip for now, not cloned it.

A bit OT:
As a part of learning Python I have added a new class to make the code more(?) readable:

This makes my soggy brain hurt when I try to follow it:

    # create FAB-layer
    chamfer = (rm-pin_width)/2
    kicad_modg.append(Line(start=[l_fab + w_fab, t_fab+h_fab], end=[l_fab, t_fab+h_fab], layer='F.Fab', width=lw_fab))
    if start_left == True:
        kicad_modg.append(Line(start=[l_fab + chamfer, t_fab], end=[l_fab + w_fab, t_fab], layer='F.Fab', width=lw_fab))
        kicad_modg.append(Line(start=[l_fab, t_fab+h_fab], end=[l_fab, t_fab+chamfer], layer='F.Fab', width=lw_fab))
        kicad_modg.append(Line(start=[l_fab, t_fab+chamfer], end=[l_fab + chamfer, t_fab], layer='F.Fab', width=lw_fab))
        kicad_modg.append(Line(start=[l_fab + w_fab, t_fab], end=[l_fab + w_fab, t_fab+h_fab], layer='F.Fab', width=lw_fab))
    else:
        kicad_modg.append(Line(start=[l_fab, t_fab], end=[l_fab + w_fab - chamfer, t_fab], layer='F.Fab', width=lw_fab))
        kicad_modg.append(Line(start=[l_fab + w_fab, t_fab+h_fab], end=[l_fab + w_fab, t_fab+chamfer], layer='F.Fab', width=lw_fab))
        kicad_modg.append(Line(start=[l_fab + w_fab, t_fab+chamfer], end=[l_fab + w_fab - chamfer, t_fab], layer='F.Fab', width=lw_fab))
        kicad_modg.append(Line(start=[l_fab, t_fab], end=[l_fab, t_fab+h_fab], layer='F.Fab', width=lw_fab))

    if cols==1:
        for c in cleft:
            kicad_modg.append(Line(start=[l_fab, c*rm-pin_width/2], end=[-rmx_pin_length, c*rm-pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[-rmx_pin_length, c*rm-pin_width/2], end=[-rmx_pin_length, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[-rmx_pin_length, c*rm+pin_width/2], end=[l_fab, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
        for c in cright:
            kicad_modg.append(Line(start=[l_fab + w_fab, c*rm-pin_width/2], end=[rmx_pin_length, c*rm-pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[rmx_pin_length, c*rm-pin_width/2], end=[rmx_pin_length, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[rmx_pin_length, c*rm+pin_width/2], end=[l_fab + w_fab, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
    elif cols == 2:
        for c in range(0,rows):
            kicad_modg.append(Line(start=[l_fab, c*rm-pin_width/2], end=[-rmx_pin_length+rm/2, c*rm-pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[-rmx_pin_length+rm/2, c*rm-pin_width/2], end=[-rmx_pin_length+rm/2, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[-rmx_pin_length+rm/2, c*rm+pin_width/2], end=[l_fab, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[l_fab + w_fab, c*rm-pin_width/2], end=[rm/2+rmx_pin_length, c*rm-pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[rm/2+rmx_pin_length, c*rm-pin_width/2], end=[rm/2+rmx_pin_length, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))
            kicad_modg.append(Line(start=[rm/2+rmx_pin_length, c*rm+pin_width/2], end=[l_fab + w_fab, c*rm+pin_width/2], layer='F.Fab', width=lw_fab))

I like the CadQuery style where method calls can be chained so I redid it like this, kind of turtle graphics style with relative drawing:

    # create FAB-layer
    even_pins = rows % 2.0 == 0.0
    chamfer = (0, 0, 0, 0) if cols == 2 else (w_fab / 4, 0, 0, 0) if start_left else (0, w_fab / 4, 0, 0) 

    fab = Polyline(kicad_modg, 'F.Fab')\
            .rect(w_fab, h_fab, chamfer)\
            .setOrigin(-w_fab / 2.0, -h_fab / 2.0)

    # pins
    if cols >= 0:
        fab.moveTo(0.0, rm / 2.0 - pin_width / 2.0)

    if cols == 2:    
        for c in range(0, rows):
            fab.left(rmx_pin_length)\
               .down(pin_width)\
               .right(rmx_pin_length)\
               .moveTo(w_fab, -pin_width)\
               .right(rmx_pin_length)\
               .down(pin_width)\
               .left(rmx_pin_length)\
               .moveTo(-w_fab, rm - pin_width)
    elif start_left:
        for c in cleft:
            fab.left(rmx_pin_length)\
               .down(pin_width)\
               .right(rmx_pin_length)\
               .moveTo(w_fab, rm - pin_width)
            if even_pins or c != cleft[-1]:
                fab.right(rmx_pin_length)\
                   .down(pin_width)\
                   .left(rmx_pin_length)\
                   .moveTo(-w_fab, rm - pin_width)
    else:
        for c in cright:
            fab.moveTo(w_fab, 0.0)\
               .right(rmx_pin_length)\
               .down(pin_width)\
               .left(rmx_pin_length)\
               .moveTo(-w_fab, rm - pin_width)
            if even_pins or c != cright[-1]:
                fab.left(rmx_pin_length)\
                   .down(pin_width)\
                   .right(rmx_pin_length)\
                   .moveTo(0.0, rm - pin_width)

I am sorry for beeing a fool and not finding the updated scripts myself.

[terjeio]

@Shackmeister your changes has now been merged and I am digging into the latest version.
So far I have found a nasty "bug" that took a while to pin down.

from the scripts - this code gives incorrect results:

pad=[2.75, 1]
slk_offset_pad = pad[1]/2+slk_offset+min_pad_distance

this is ok:

pad=[2.75, 1.0]
slk_offset_pad = pad[1]/2+slk_offset+min_pad_distance

Python is more type aware that I thought:

>>> print 1/2.0
0.5
>>> print 1/2
0
>>> print 1.0/2
0.5

There are many potential integer by integer divisions like that in footprint_script_pin_headers.py and I do not want to touch that code too much as it is shared with the pin headers, it could be that this behaviour is deliberately relied upon (or coded around?). This could be dangerous though since it is dependent on input data type, a better practice is either force a float division by using a float divisor or, if the intention is to do an integer division, ensure the dividend is an integer.

I will "fix" this by ensuring input data that can be affected is of type float.

[poeschlr]

use python3 or from __future__ import division to get the same behavior in python 2.x
http://www.informit.com/articles/article.aspx?p=1439189