Capacitor_SMD outdated

[antoniovazquezblanco]

As an example C_0805.wrl should now be called C_0805_2012Metric.wrl. Only happening to non polarized capacitors.

[easyw]

@antoniovazquezblanco because of this big renaming wave, we would need a big help to fix all the repos..

Thx a lot for any available help 😄
Maurice

[antoniovazquezblanco]

I will help with as much time I find. I am currently a bit stuck due to not being able to execute anything from the scripting repo due to my version of FC and the CQ workbench (I would prefer not to renounce to my current setup).

[easyw]

@antoniovazquezblanco
which FC and CQ releases do you have and in which Os? Which errors do you get in your Report Panel? And which family are you trying with?

[antoniovazquezblanco]

Latest Win64 FC release (0.16 6712) and CQ from the addons_installer macro (CadQuery 1.0)

[easyw]

@antoniovazquezblanco
could you please add:

1. Which errors do you get in your Report Panel?
2. And which family are you trying with?

[antoniovazquezblanco]

For example:

Open FreeCAD, Open CQ Wb, open C_Chip_SMD/main_generator.py script, press run. Error is raised because exportPartToVRML cannot be imported due to the fact that it seems that CQ runs scripts from a random dir instead of the path of the script.

[easyw]

you need to launch:
create_model-example.bat
(change FC path to your actual FC installation path)

[antoniovazquezblanco]

Removed the try catch in order to see the actual error:
Exception while processing file: main_generator.py [No module named Gui.Command]

[easyw]

@antoniovazquezblanco
this is because CQ changed since these models were done...
You can see how that error have been removed in more recent model families... this is a good moment to update these old generators

[antoniovazquezblanco]

Please give me an example of an updated script. Will do some work on this.

[easyw]

@antoniovazquezblanco
I updated the C_Chip_SMD generator to go further on CQ check... still there are problems because of different CQ releases ... you will get errors on fillet ...
maybe @Shackmeister may help on that ...

@SchrodingersGat please consider that a renaming of footprints can be useful for a 'better' library structure, but is generating a huge mess for 3D model generation... 3D CAD is much more complicated than a footprint or a wrl model.

[SchrodingersGat]

What are the difficulties beyond just renaming the models? Is it an issue of changing the output of the scripts? If the models already exist, is there any problem just to rename the model files without changing the scripts?

[easyw]

if

1. you are doing that for about 5K models
2. you are planning to rename also the STEP model name inside the step file (STEP doesn't accept all characters in internal names, so a check has to be done)

I'm fine then

Moreover this will disalign the generators from the 3d repo, which is a bad option in case of further needs

[Shackmeister]

@easyw this work is needed IMO, I think the library and dev teams very rarely makes huge changes just for the fun of it :) Ill be reuploading my new combined pinheader yaml script hopefully this evening :) from there Ill move on to resistors and go from there :)

[easyw]

@Shackmeister
this work in not needed IMO and moreover is breaking compatibility with previous releases ...
and which is the gaining advantage?
You get a better understanding of your library having a model renamed from C_0805 to C_0805_2012Metric? Do you really think this kind of action will give a better user experience, or you just would get a bad reputation from users that will get mad because of these frequently changes?

Recently, you may have noticed, has been changed also a footprint internal format...
Particularly the field 'at' had its values in deci-mils since the first release of the 3D rendering... now Oliver decided to write this field in millimeters to have a 'consistency' in all internal fields...
Then for this 'sofism chosen' there is a bump in kicad pcbnew version:

• all footprint libraries that had this value different from zero will be affected (those are most of mechanical parts that users are integrating in their libraries, using pcbnew to align the 3D model)

This is a longer story... you can have a look at the kicad dev mailing list (Subject: [PATCH] Fix for 3D model offset)
and here few gentle messages from affected users:

It will break most of my boards. I won't complain because I appreciate the effort and I welcome every improvement, but be prepared for some very rough comments out there.

I have several footprints that use manufacturer's models, where offsets and rotations are necessary. I really fail to see the point of breaking people's designs and libraries needlessly.

and most of people didn't even noticed because the process of breaking is 'silent'... moreover this patch actually has introduced a 'multiplying' effect on 3D offset that the author is trying to re-patch adopting a more invasive solution that will break even more the pcbnew compatibility...

My point here is that I haven't seen no ECAD around (commercial or open source) changing its libraries and sw compatibility just for 'pedantic' reasons IMO.
Libraries are the 'foundation' of the ECAD work and changing them with such lightness is a very bad attitude IMO.

Now we would need to spend hours in aligning the models to the new re-naming wave instead of using these hours for developing something new and real useful for KiCad...

But this is just my opinion (and some other user's as seen at the mailing list) ...
Maurice

[poeschlr]

@easyw regarding your criticism of our decision about including metric. Have fun reading this:
KiCad/Resistors_SMD.pretty#17

You had a very long time where you could have given input here KiCad/kicad-library#1447 or here KiCad/kicad-library#1402 (Or even over on the forum in this post: https://forum.kicad.info/t/klc-turns-three/8347)

We are reorganizing the libs in combination with a major release. So users should expect some changes all over the software. During a stable release cycle such big changes will not happen. The libs for the 4.x stable will stay unmodified.

I think the new naming scheme is a major improvement over what we had. (Well we really did not have a naming scheme in the past. A lot of libs had quite random namings. Edit: The resistor libs where some of the better libs. Have a look at the old fuse lib.)
Sometimes one really has to redo something right from the ground up.

The only problem in old designs is that kicad does not cache 3d models as it does with footprints and symbols. This will sadly result in breaking 3d model linkages for old projects. (Unless the user has a copy of the old 3d models around. Something they could not do with past changes.)

We did not shy away form having incompatible 3d models in the past. Otherwise we could have never introduced your new step models in combination with correctly scaled wrl.

Edit:
We will try to keep the current KLC stable over the v5 release cycle. (Only make small amendments if we discover something new. But try not to make old footprints and symbols obsolete.)

[easyw]

Hi @poeschlr
I see your point and I totally missed the discussion at KiCad/Resistors_SMD.pretty#17
but I wouldn't have accepted the Team14 user's suggestions...
As I already pointed out, reorganizing the libraries is a delicate process...

You had a very long time where you could have given input here KiCad/kicad-library#1447 or here KiCad/kicad-library#1402 (Or even over on the forum in this post: https://forum.kicad.info/t/klc-turns-three/8347)

Nobody ask me or even called me in the discussion... but these decisions are affecting all 3D models libs... don't forget I made the new 3D library setup and I did it one and half year before kicad librarian even think to move to my model approach... so I'm very disappointed that in terms of users experience this is getting worst

We did not shy away form having incompatible 3d models in the past. Otherwise we could have never introduced your new step models in combination with correctly scaled wrl.

The 3D library at the beginning was a real mess, with:

1. no models with a real mechanical part
2. all the wrl models with different scales and offset
3. most of wrl models were with wrong appearance properties values
4. most of users even didn't use the 3D models

That was a real needed reworking...
This new renaming is IMO something more 'formal' than 'substantial' and as I already pointed out, I see no commercial or open source products doing this kind of library reworking for formal needs...

Moreover you probably missed also the footprint format change that had recently introduced and I re-call in this discussion...
This is an other 'bad move' IMO and I hope that in the future these aspects will be much more taken in count...
Maurice

[poeschlr]

I think the name for the two terminal smd packages is a good compromise. (And long overdue.)
Giving users the option to see metric codes is an improvement.

Another major improvement is that we now include what the letter codes in tantal caps means. (There are multiple competing standards that contradict each other. Saying CP_A_.... can be misleading.)
Also long overdue: Splitting the pin header and pin socket libs and the phoenix lib. (Github could no longer handle these large libs.)
Another thing was unifying connector naming. (It was impossible to write a footprint filter with the old mixed naming convention.)

Where we might have gone overboard is by changing Housings_* -> Package_* and by changing Pitch->P. Without this change, at least the IC libs would be identical.
(But again i think this are changes that will make the lib better over all.)

By doing all these changes at once users have an easy option to keep their projects alive. (By having the 4.0.7 lib somewhere locally) If we would introduce this over a long period this option would not exist.

---

About the offset stuff: I totally agree with you. This was somewhat strange. (Introducing offset only if at!=0 is a good compromise i think.)

---

By the way i am sorry that we did not explicitly tag you in the discussions.

The original intention was not to completely rename all footprints but to find a common theme existing in the old footprint names. Sadly this was not really possible.

[easyw]

By doing all these changes at once users have an easy option to keep their projects alive.

@poeschlr I'm not saying that the change is a bad option in general, but only that changes will have consequences...
If this would have happened in a commercial environment, before the changes one would must have calculated the cost and the resources to manage the changes...
Just to remember what I already said: "I see no commercial or open source products doing this kind of library reworking for formal needs..."
Here everything has been heavily underestimated...
Again I'm not saying that is not useful, but then my question...
In a commercial environment the administrator would have asked: "Who is going to pay for that?"
In an open source environment the question is: "Who is going to managed that?"
3D mechanical libraries are much more delicate than an electrical part library or even a footprint... 3D models quality depends on many factors and cannot be easily automatically managed... I haven't found a reliable method to inspect if a model if fine in terms of geometry errors... I remember that I raised an exception about it and I realized that the library maintainer was not even aware what a 3D geometry check means... Moreover it is enough that a single part is wrong to mess up all the mechanical assembly...

---

About the offset stuff: I totally agree with you. This was somewhat strange. (Introducing offset only if at!=0 is a good compromise i think.)

the 'offset' thing would be even worst than the original change...
the-cure-is-worse-than-the-disease
Then for the sake of a formal 'incoherence' in assigning 'deci-mils' to the field 'at' inside a footprint,
this patch, described as:

noble goal of fixing one of the biggest KiCad sins - incoherence

is going to:

• break pcbnew back compatibility
• add a 'silent' changes inside the footprint libraries that will fool user's libraries
• add a more 'incoherence' in the way the footprint is going to be written/read:
  • use 'at' if offset is all to 'zero'
  • use 'offset' if one or more are different to 'zero'

Does it seem more clear/coherent than simple state that 'at' field was written in 'deci-mils', without breaking anything???
I don't remember how many times I stated that at developers mailing list, but this changing has started for a wrong assumption: that 3D viewer and exporters would have failed in managing the 3D offsets... which is wrong... this wrong assumption started a misunderstanding of the issue itself.
Moreover the internal representation of a data that was just simple correctly managed is a real formal issue and not an user issue...
The first proposed patch was completely wrong, the second one, which was even commit-ed and reverted, was even more wrong, the third one is giving a multiplying of offset when importing and saving a footprint, and this last one, that I think it will be merged, is going to add more mess to users library because of breaking back compatibility and add an ODD way to manage an internal field...

Just my 2cents

[Shackmeister]

HI I just finished making the new script and parameters for these models, a PR will be up in a few days.
so please dont spend time on renaming caps :)

[Shackmeister]

PR has been submitted
#199

[antoniovazquezblanco]

Thanks!