kicad-lib-committers team mailing list archive

[Bernd Wiebus <bernd.wiebus@xxxxxx>]

Hello Jan

> If I mount it from the bottom, I don't really need the silkscreen on
> the top, right?

This depends on the quality of the firm you have for assembling the
board. Good workers will look at additional documents, bad will not
recognize that there is a device to mount, if there is no placeholder
at the silkscreen. And they even will not look at the bottom, if you
made really a board with silkscreen at top and bottom.

To remember such people, the placeholder at the top silkscreen is
with dashed lines for items at the bottom. 
But sometimes, even this is not enough..... ;O)

>I can e.g. place some additional components from the
> top, where the transistor is at the bottom ...

Yes you can. In this case, you have to look, that no print at the top
silkscreen is across of some pads.

> Anyways I'll make script to also create this symbols (should be wuite 
> easy) and then we can discuss in the final PR. OK?

Ok

With best regards: Bernd Wiebus alias dl1eic



Am Sat, 5 Nov 2016 12:04:02 +0100
schrieb Jan Krieger <jan@xxxxxxxxxxx>:

> Hi Bernd!
> 
> about the large pads: I agree!
> about the _MountFromLS: I'm not so sure ... is that really required?
> If I mount it from the bottom, I don't really need the silkscreen on
> the top, right? I can e.g. place some additional components from the
> top, where the transistor is at the bottom ... What's missing then is
> mainly the REFDES ... SO maybe having only the Vertical package for
> mounting from below is enough?
> 
> Anyways I'll make script to also create this symbols (should be wuite 
> easy) and then we can discuss in the final PR. OK?
> 
> Best,
> JAN
> 
> 
> Am 05.11.2016 um 10:54 schrieb Bernd Wiebus:
> > Hello Jan.
> >
> >>    * MountedFromLS: This is not necessary, as it can be done by
> >> mirroring the device
> >
> > No. This is a footprint for mounting from the backside, but the
> > silkscreen is still at the frontside with dashed lines.
> > This is because sometimes you have a single transistor mounted from
> > the backside at a doublesided or multilayer board but with only a
> > silkscreen at the upper side. So you cannot simple create this
> > footprint by mirroring it. Notice also, that this footprint has the
> > transistor mounted with its head sink pointing downwards, so you
> > place this transistor beneath a board and mount it directly to a
> > heatsink beneath the board.
> >
> > If you want to thin out the library, you should take first the large
> > Pad variants. It is easy to chance the pad sitze. I ceated this
> > footprints to show newcomers to make rough layouts with bigger pads,
> > because i noticed, that they cling to the more traditional smaller
> > footprints found at the most librarys. ;O)
> >
> > With best regards: Bernd Wiebus alias dl1eic
> >
> >
> >
> >
> >
> > Am Thu, 3 Nov 2016 08:00:28 +0100
> > schrieb Jan Krieger <jan@xxxxxxxxxxx>:
> >
> >> Dear all!
> >>
> >> I'm currently putting together a python script to regenerate the
> >> TO-220/247/... packages in TO_SOT_Packages_THT.pretty. I would also
> >> add missing packages ...
> >>
> >> For that I would like to thin out the lib a bit and make the
> >> namjing scheme simpler:
> >> - Basically I think there are only 2 necessary footprints for any
> >> TO220-like package :
> >>    * TO-220_Vertical
> >>    * TO-220_Horizontal
> >> - As an Extension one can add versions with larger pards:
> >>    * TO-220_Vertical_LargePads
> >>    * TO-220_Horizontal_LargePads
> >> - Today there are two more extensions
> >>    * Reversed: mounted with the metal-shield up ... this could also
> >> be useful and can be included
> >>    * MountedFromLS: This is not necessary, as it can be done by
> >> mirroring the device
> >>
> >> So I would propose to have (example for TO-220):
> >>    * TO-220_Vertical
> >>    * TO-220_Vertical_LargePads
> >>    * TO-220_Horizontal
> >>    * TO-220_Horizontal_LargePads
> >>    * TO-220_Horizontal_Reversed
> >>    * TO-220_Horizontal_Reversed_LargePads
> >>
> >> Based on that I would do all still missing packages (the script
> >> only needs the measures and is otherwise easy to operate).
> >>
> >> Then I would delete all old version and replace them with the new
> >> set. A series of simple search-replace in the .lib-files should
> >> then fix the footprint-names in a second PR.
> >>
> >> Is this OK for everybody, or did I miss something?
> >>
> >> Best,
> >> JAN
> >
> >
> >
> >
> >
> 
>

Attachment: pgpwng2mSUi97.pgp
Description: Digitale Signatur von OpenPGP