Connector_HDMI.pretty is missing since v8.0.2

Hello,
I notice that footprint with the name Connector_HDMI.pretty is missing from KiCad / KiCad Libraries / KiCad Footprints · GitLab since v8.0.2. Apologies if here is not the correct place to discuss this.

Background:
Current used version: KiCad v8.0.4.
OS: Windows 11.
KiCad is installed without the official library. I clone the official repos that containing the symbols, footprints and 3d models instead. I always use the official library in this manner and have no issue so far until recently, where KiCad is complaining about the missing footprint wherever KiCad is trying to load the footprint library. And I am not sure if the same issue happens for those using the library come with the installer.

Can someone confirm this?
Thanks very much.
WH Tan

It was renamed to Connector_Video.

I have been seeing the same warning for some time every time I started KiCad.

Going to: Preferences / Preferences / Manage Footprint Libraries and changing the “HDMI” part to “Video” does fix it.

I wonder, should this be handled automatically as part of the updates? There is no sense in keeping the old library name to a path that does not exist anymore.

Thanks very much.
Been puzzling for a while. I don’t know I have to manage the list by myself until this post.

WH Tan

I am not sure it is possible, since the fp-lib-table file is the one from the user’s KiCad config directory.

A simple string replace may be acceptable for one of the known default libraries if the name changes. Or else, I would also be happier if changes like this are mentioned in the release notes. Maybe even in the popup dialog itself if it concerns one of the default libraries.

But maybe it’s wishful thinking. It is a minor thing and KiCad developers already have plenty to do.

that requires KiCad [the application] to be aware of what the default libraries are. Currently, by design, KiCad [the application] is agnostic to and uncoupled from the default libraries, and I don’t think that’s likely to change.

In other words, nothing in the KiCad code has any awareness of the what the default libraries are. KiCad gets installed with a default library table from the libraries, but other than that KiCad just loads whatever libraries are in the library table.

Issues like this are why I don’t directly use standard libraries.

I copy them to my own, and then that’s where they stay.

I’ve spent far too much time (not just on KiCAD) faffing about finding symbols or footprints because some bright spark thought fit to rename it, or change something else that broke my project.

That bright spark wasted life time for you to be able to “don’t directly use standard libraries”.

So that you can “copy them to your own”.

Are you getting the point?

1 Like

I don’t think you’re getting mine.

In a professional setting, which I’d like to think that KiCAD is aiming for, libraries should never be changed beyond fixing things known to be wrong. It’s fine to add new things, or add new things to replace old things. It’s especially important when you have a team of engineers, and even more so when you have separate teams that work on schematic capture and PCB layout.

New symbols and footprints should be checked carefully for correct pin mapping and physical fit on the footprint, pad sizes and so on. It’s a complicated process, especially with some fine pitch parts, making sure that the board itself can be made, and that solder paste can be printed correctly, and it reflows properly.

But once everything is confirmed to be correct, that’s it. It’s locked down. No random renaming or changing of either the footprint or symbol, or changing pin numbering.

Doing such changes just adds in extra work, and adds a big uncertainty into your designs.

An example I had in KiCAD was the USBLC6-2SC6 symbol. Here are the two side by side in the schematic:

Why did someone decide to do this? Wouldn’t have been so bad if the relative pin ordering around the symbol was the same, but it isn’t. So you’ve then got to spend time fixing it.

In a professional setting, this is just plain bad. Imagine saying your project leader / supervisor “Oh, someone a thousand miles away changed a few library symbols, and it’s totally cocked up our schematic. It’s going to be an extra weeks work to fix it.”

The reality in a professional setting is this sort of thing is an unacceptable risk.

Once you’ve been burned, you NEVER directly use libraries you don’t have direct control over ever again.

In KiCad, the symbols/footprints used in your design do not update themselves. Once you add them to your schematic/board, they are embedded in the file and only change when you manually edit them or manually perform an “update symbol/footprint from library” action. The engineer (you) is responsible for checking that the new symbol/footprint is still appropriate and your design hasn’t changed. If it isn’t, no one is forcing you to change it.

Further, I would expect a company to have its own version controlled libraries that go through a review process before any changes are integrated (based on the standard library, possibly).

In a professional setting, I would expect an engineer to understand how to use their own tools and implement their own processes, not blame others for the results of their own actions.

If you do not find the standard libraries useful, by all means don’t use them, or feel free to provide constructive criticism. Insults towards people who volunteer a substantial amount of their free time to support your business are unprofessional and unappreciated.

If changes to libraries are messing up your schematic, I would suggest there is something wrong with your workflow. Changes to libraries are never automatically propagated to your schematics. You have to take manual action to do that, which means you have a chance to review and decide whether or not to do so. KiCad 8 even has a graphical comparison tool that lets you preview changes to library content.

If KiCad’s own libraries would not change, there would be no progress in KiCad’s libraries. The symbol you show is a good example I like the new much smaller one much better, and it also allows for better readable schematics. Also, you have connected the symbol wrongly in the first example. The goal here is to force the signal though the protection device to keep stray inductance of the IC housing to a minimum. The new symbol guides you to do this automatically.

Yes. That is why KiCad has the KLC If you submit symbols or footprints to the KiCad project, they are not just put into KiCads libraries. Each and every symbol or footprint can take upto hours of review. As a result, new parts are added slowly, but it keeps the libraries up to a high standard.

KiCad’s own libraries are also a “getting started” point, and often directly used by hobbyists (which is a big part of KiCad users). If you design PCB’s for a production environment, it is common to have full-time librarians which just do symbol and footprint creation and verification. If you are in that category, then you can still use KiCad’s libraries as a starting point to vet though your own process, but you should never use them directly. Over time you will build up your own verified libraries, and you probably also want to use the database driven library system in KiCad. It’s not visible to beginners who just use the simple libraries, but once you set up your own database, parts management between librarians and PCB designers becomes easier, you can add ordering info, compatible replacements, status info etc. KiCad uses an external database, so if you already have a database of parts, you can link them to KiCad and use them in KiCad too.

Paul,

That’s exactly what I’m saying. 100% agree. Improvements are always good, and always welcomed, but only when neccessary.

I can see why some people would like to be on the latest and greatest, but for some poeple, myself included, stability is more important.

Take something like a BSS138 MOSFET. What can possibly be “improved” on by changing things? It’s a simple part, a simple symbol, and a simple footprint. It doesn’t need improving, so why change it? If you apply the same logic to the USBLC6?

The “Incorrect” connection of the part on the schematic snip was specifically requested by my customer, to allow a do-not-fit should they choose. I raised it at the time as a bad idea, pointing out stray inductance (as you mentioned), and unprotected IC pins exposed to the outside world (generally a bad idea) but as always, the customer is always right!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.