It’s also worth considering what is important in the library level and what is not. The amount of files isn’t necessarily important. The size of the whole 3D library is.
The EP makes sense once you start to think about a future where somebody wants to do some thermal simulation.
4 Likes
Does the EP in the 3D model help with simulation?
For thermal i would imagine yes. Especially if it is implemented by use of FEM simulators borrowed from mechanical engineers.
2 Likes
@hermit sorry if i offended you in any way - not my intention!
Accuracy depends on the application. At the moment the 3D models don’t have any tolerance information defined, and in real life could be slightly larger or sightly smaller, by a lot more than the thermal pad.
@eelik If I read you correctly you are agreeing with my argument? 
As I was typing this reply 3 new replies came in! I was just about to write: “can anybody give me any reason why thermal pad should be in the 3D model?”, but @Rene_Poschl already answered with the FEM reason .
Ok then now we are getting somewhere to discuss the “3D model accuracy” question: if the 3D model needs to be used for FEM analysis then the existing models would not be sufficient as you’d also need accurate thickness of the metal pad and also the silicon chip inside: its size, how is it bonded to the thermal pad, how it is bonded to other pins in the package etc. See example below:
Source: https://www.eetimes.com/thermal-analysis-for-power-devices/
[edit: added picture]
1 Like
To add to my above points, I was just browsing the footprint library and noticed that majority of the 3D models for BGAs only have the outer rows of balls modeled. Three examples below:
Library Package_BGA
Footprint UFBGA-100_7x7mm_Layout12x12_P0.5mm.kicad_mod
Library Package_BGA
Footprint UFBGA-132_7x7mm_Layout12x12_P0.5mm.kicad_mod
Library Package_BGA
Footprint UFBGA-144_7x7mm_Layout12x12_P0.5mm.kicad_mod
Now I am not in any way saying that the above BGA footprints should have their 3D models fixed to have the correct number of balls. I actually think the 3D model that they have is perfectly valid for the two use cases that they are intended for:
- Providing a nice looking visual for rendering.
- Accurate outer dimensions for integration with MCAD systems, which allows checking if there are any collisions with other objects in the overall assembly.
The fact of having the inner balls missing from the model wouldn’t make a difference at all for above use cases. In fact any unnecessary additional features would result in a very sluggish MCAD model due to the amount of objects it needs to render as you rotate it around. The other thing is even though the above footprints are for different number of balls, all of them actually have the same outer dimensions and if you pay attention to the 3D models, they are actually identical. Therefore, they could all share a common BGA model: the 3D models are identical anyway - why have three separate files of the same thing wasting hard drive space?
Considering that the issue of different number of inner balls on BGAs is similar to different sized thermal pads in QFN packages, I would like to propose the below modification/addition to the KiCad Library Convention for 3D Models (you may change wording as you wish to ensure it is clear):
If a footprint is a simple variation that does not change the external 3D representation, the common 3D model should be used ( do not duplicate models unnecessarily )
R0805_HandSoldering.kicad_mod→R0805.wrlQFN-48_ThermalVias.kicad_mod→QFN-48.wrlThis also applies to components with identical external representation but variable features on the underside (the hidden side) - e.g. variable sized thermal pads in QFNs or variable number of balls in a BGA package:
DFN-6-1EP_2x2mm_P0.5mm_EP0.6x1.37mm.kicad_mod→DFN-6-1EP_2x2mm_P0.5mm.wrlDFN-6-1EP_2x2mm_P0.5mm_EP0.61x1.42mm.kicad_mod→DFN-6-1EP_2x2mm_P0.5mm.wrlUFBGA-100_7x7mm_Layout12x12_P0.5mm.kicad_mod→UFBGA-xxx_7x7mm_Layout12x12_P0.5mm.kicad_modUFBGA-132_7x7mm_Layout12x12_P0.5mm.kicad_mod→UFBGA-xxx_7x7mm_Layout12x12_P0.5mm.kicad_modUFBGA-144_7x7mm_Layout12x12_P0.5mm.kicad_mod→UFBGA-xxx_7x7mm_Layout12x12_P0.5mm.kicad_mod
Feel free to disagree with me on above points - maybe I am missing something?
I will say this again: I am not just arguing for the sake of arguing: I am offering my help to carry out the necessary changes to the KiCad library in order to fix at least some of these issues of missing 3D models. However, if I can fix the issues the way I am proposing, it will be significantly less work than having to create a huge number of new 3D models from scratch. Also, I am keen on reducing the 3D library size if at all possible.
Even if the models right now do not have all details we still need the option to add more detailed ones later which requires every unique package to have a separate model set in its footprint(s).
Also consider our continuous integration setup. It needs to be able to discover what a valid path is. Right now this is rather simple as we just compare the model path to the footprint path. Anything more complex is simply not in the cards right now.
Also consider that all these models are script generated. The reason some do not have models is because nobody got around to generate them from the already existing data. We could of course require every user to add a 3d model if they add a footprint but to be honest 3d models are simply a way too low priority right now to require this from our contributors. (We could make it a requirement for script generated ones but also here our scripts are not that user friendly so i am not sure this would be the right move)
What makes it even worse is that the footprints are also scritped. The long term goal is to get rid of any handcrafted footprints for standardized packages. Which is why none of these are allowed to be edited from within kicad.
And now something worse: The decision to do it the current way was made a long time ago. Such a decision of course means that a lot of infrastructure is build up under the assumption of the current rules (a lot of scripts). All of these scripts would need to be adapted and i really don’t see the point.
If you really want to help then i suggest you adapt the 3d model scripts found in https://github.com/easyw/kicad-3d-models-in-freecad to accept the size definition files used for the footprints https://github.com/pointhi/kicad-footprint-generator That way it would be really trivial to get all required 3d models.
3 Likes
@Rene_Poschl thank you very much for the detailed explanation. I hadn’t considered that the models were script generated and the existing inter-dependencies of 3D model naming and scripts for auto-generation of models - I now see why you need to have separate files for identical 3D models.
Also, you made a really good point about needing to have the ability in the future to add more detailed models if it so was required - continous improvement.
I now understand the direction of the 3D libraries much better and will proceed accordingly and see what I can do to adapt the 3d model scripts. Side point: at the moment I can’t get the 3D model scripts to work on my machine - I’ll make a separate topic about this.
Thanks again for taking the time to explain all this and look forwards to helping out where I can!
Edit: added link to separate topic
1 Like
Being able to parse the size parameter from the FP generator would be a huge improvement (has been on my todo list for way too long, but I don’t have much Kicad time nowadays).
@Qbort please let me know if I can assist you with anything
I just realised I haven’t replied to this main thread: just to update everyone that I am working on this. At the moment I have found there are issues running the scripts: some only run in FreeCad 0.17, some only run in FreeCad 0.18. This is due to python3/2 compatibility and a few other minor bugs.
I’ve created merge request with the fixes (still WIP): https://github.com/easyw/kicad-3d-models-in-freecad/pull/374
2 Likes
If you are in a hurry Py2 scripts can be converted by using 2to3, and if you wish to go the other way, you can use pasteurizer.
2 Likes
Scripts that need Python 2 need to be updated, FreeCad 0.17 is obsolete.
Hopefully 0.19 won’t introduce more incompatibility
2 Likes
there are still distribution using FC0.17, so when possible I tend to let both py2 and py3 compatibility available
There are a bunch of scripts and many of them are still untouched since the very start (using FC0.15)… nerveless the main incompatibilities are python related, and are already patched in some of the 3D model builder simply allowing both py versions
I won’t trust this approach… this will migrate from py2 to py3 without allowing the back compatibility
Ideally you’re not meant to go backwards. If you have users relying on Py2, then you’ll have to make the difficult decision to either abandon them or maintain two versions. That’s why it’s important that Kicad makes an unequivocal decision to go forwards.
Ideally you’re not meant to go backwards. If you have users relying on Py2, then you’ll have to make the difficult decision to either abandon them or maintain two versions.
@kenyapcomau
My 3D repos started with py2 and FC 0.15… since 2015 we have gradually moved to FC0.16,0.17,0.18 and now 0.19 but still most of the scripts can just run fine in older FC releases and with simple py check code it is possible to let the tools to be fully usable with both of the py versions. I don’t see why we cannot keep this approach that need few simple line of code in the scripts.
You don’t need to have two versions but just keep in mind when you code to check py compatibility.
1 Like
I think the approach is up to the author. But I also think the large software applications have dragged their heels even though EoL of Py2 was announced long ago.
even if I agree py2 is dead, as I said:
Thanks, I’ll have a look. I would never trust what an automatic conversion tool does blindly, but I can see the result and fix any other issues manually.
@maui I am testing code in FC0.17 and FC0.18 to ensure backward compatibility.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.