Skip to content
This repository has been archived by the owner on Oct 2, 2020. It is now read-only.

Populate IC sockets by default #388

Open
leoheck opened this issue Aug 30, 2018 · 8 comments
Open

Populate IC sockets by default #388

leoheck opened this issue Aug 30, 2018 · 8 comments

Comments

@leoheck
Copy link

leoheck commented Aug 30, 2018

Referencing an idea here KiCad/kicad-footprints#866. but I still think that it is an issue for the footprint repo.

@leoheck
Copy link
Author

leoheck commented Aug 31, 2018

So the idea is to populate the sockets with the IC. @poeschlr said that it is better to have a whole model with the socket+ic because adding the IC model will need to shift it up (considering the Z axis) and it is not a good practice to store this kind of data there.

What do you think?

So, adding on top of the @poeschlr idea, if the whole model with the socket+ic is a good idea, the footprint should reference both socket and socket+ic models keeping the preview of the first disabled.

@Ratfink
Copy link
Collaborator

Ratfink commented Aug 31, 2018

I agree with your original idea: I understand that we generally want our 3D models to not require an offset (a model should be made to fit its footprint, after all), but adding a second model reference with a Z offset to make an IC fit in a socket seems fine to me.

The only problem I could imagine would be that if we change the height of the socket model, the footprint would have to be changed as well to update the offset of the IC model. But that seems unlikely, and it wouldn't be a big issue anyway since the symbols and footprints in question are script-generated.

In short, I don't see a problem with your original idea, I see a problem with KLC forbidding it.

@poeschlr
Copy link
Collaborator

@easyw could i get your expert opinion on that?
Is there any reason not to allow adding two models with different Z offset?

@easyw
Copy link
Contributor

easyw commented Aug 31, 2018

@poeschlr
this is an exception in the library that I consider acceptable, because the z-offset applied to the 3D IC model is exactly what is applied to the real IC.
Referring to the previous post, what I would like to have in the future, is the option to show/hide the 3D models dynamically and directly in the 3D viewer.
So I wouldn't suggest to add a field in the footprint to enable/disable the view, but I would like to have a full list of the 3D models (a tree list) within a correspondent check option to enable/disable the visualization on the 3D viewer (an evolution of what is now available to show/hide all SMD, TH and Virtual models).
This list with related checked options could be saved along with the pcb project, to reload the board in the same way next time it will be displayed.
And a nicer addition would be the ability to change transparency to the selection too.
Adding a check option inside the footprint would be a very unfriendly way to enable/disable the view in the 3D viewer... Within the option inside the footprint would force the user to change the option in the pcb 2d editor and then switch back to the 3D viewer. A tree view list available in the 3D viewer menu would let having a better/friendlier user experience IMO.
Moreover, a tree list for 3D viewer would not change the pcb file format, but will add just a preference file for what is enabled to be viewed and with the level of transparency that will be applied.

@Shackmeister
Copy link
Collaborator

Looking at this wishlist item
https://bugs.launchpad.net/kicad/+bug/1766323

I think we would have to revise the KLC for offset of the "extra elements" (dips for sockets, batteries, cards etc) since these might make sense to reuse for multiple batteryholders etc

@easyw
Copy link
Contributor

easyw commented Sep 1, 2018

here my wish 😄

3d-selector

@serkanxselcuk
Copy link
Contributor

serkanxselcuk commented Sep 20, 2018

@poeschlr @easyw

this is an exception in the library that I consider acceptable, because the z-offset applied to the 3D IC model is exactly what is applied to the real IC.

I don't believe, that a library for IC+socket and IC only or change offset on IC library can be good for future. If we change anything on one of packages, we must change the otherone as well, which can be forgotten quickly. A part IC+Socket would appear on BOM list as like only IC.

At the other side, there are more type of sockets with different height. We would choose only those socket types if we set Z-offset on library.
image image image image

I think it is better to put socket and IC in schematic editor separately, which will shown separated on BOM as well. Only disadvantage is now, two THT although there must be only one. Actual user must delete one of them manual on fabrication files, which takes time and can be forgotten.

What would you think about footprint library for sockets, which has no pads? So:

  • user add a symbol for socket in EEschema (symbol should have no wire connections)
  • a separate symbol for IC, which will be connected like before.
  • At PcbNew IC and Socket are placed on each other and then set z-offset for IC

image
image

@leoheck
Copy link
Author

leoheck commented Sep 21, 2018

I still think that sockets should come with the IC considering the 3D model.

I agree that the schematic and BOM will be better (complete) if you add both symbols on the schematic.

My thought process it something like this:

  1. Place the Socket and the IC on the schematic sheet
  2. For the Socket, add a footprint (which will have the 3D models for the IC and Socket)
  3. For the IC, do not add a footprint since you want it only in BOM.
  4. On the layout, everything will be the way we expect.
    1. No multiples footprints considering IC and the Socket.
    2. No extra work for filling the ICs on the sockets
    3. No extra work changing IC placement settings

The offsets rule should be an exception for sockets.
This will reduce librarians work reusing the already made 3D models, it will reduce the space required by footprints+3Dmodels

For the end-user, everything will be there by default. If he doesn't want the IC on top of the socket it is just a matter of disabling it on the footprint properties.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants