Migrating libraries from old version (<1.0) "pressfit" problem

Hi.
I have a problem with “pressfit” in .lp files of my old libraries (2020-2022 y.).
I copied them as files to the new version. Many of my elements (packages) in the new version (1.1) are “hidden”. I created many, many elements in a non-standard way. I have astigmatism and need packages (pads) with large dimensions, e.g. ~3.2 x 1.8 mm THT pad (and I often use THT packages as SMT - without drilling). I copy elements from the standard library to my own. I make a duplication - for another UUID (non-conflicting). I delete the copied element and add my own footprint to the elements + replace categories with my own (with a text prefix - so I can see that they are from my library), etc. - a lot of work. It’s all manual work - which I like (quick design, frequent changes, fast thermal transfer, and possibility to be done by someone like me… etc).
In official libraries I can’t add “my” footprints and it would be great if I could copy elements in a simpler way (with the risk of being up-to-date). A lot of writing :slight_smile: After a few days I noticed that the reason why my (some) packages are not displayed is the use of “(function pressfit)” in old package .lp files (“Press-Fit” THT in edit menu) - after manually (Linux/Midnight Commander) changing the text of the files to “(funcion standard)” the old definitions appeared in the library(!).
LibrePCB gives me a lot of joy. Thank you!

Hi @kenubi

Oh wow, you just found a bug in LibrePCB :astonished: I fixed it now (Fix deserialization of pressfit pads by ubruhin · Pull Request #1444 · LibrePCB/LibrePCB · GitHub).

You have two options:

  • Wait for the next release (not sure when it will be available)
  • Change the term “pressfit” to “press_fit” in the affected files. Note that this change will be reverted when you save the package again from LibrePCB. Only the next release will fix the problem correctly.

Thanks for reporting! :sparkles:

You could keep their UUIDs and just add your own footprints to them:

  1. Instead of duplicating a library element to your local library (duplicate means generating new UUIDs), use the “Move To Other Library” context menu in the library editor:
    image
    This copies the element while keeping the UUIDs.
  2. In your local library, assign a very high version number to the copied element (e.g. 999) to give it a higher priority than the official library element.
  3. Add your own footprints. Move the default footprint to the top of the list. But you should not remove existing footprints.

This way all the devices from our libraries will still work with your own footprints.

1 571 / 5 000

Wyniki tłumaczenia

Thank you!
in point 2 - I saw it somewhere (some thread) - it’s very important information for people like me. It explains the principles of operation. It’s worth emphasizing this at the beginning of the documentation (I’m old (52) and I don’t have time - sorry - it’s probably in the documentation)

Of course, I don’t delete the elements in the original library - first I copy, then duplicate (for the new UUID) and edit the new UUID, and delete the elements with the original UUID - leaving the new ones - duplicated. See point 2. Why do I do it? For mistakes. I’m afraid of libraries from the Internet (I’ve seen threads about it) and new versions (of the world ;). Symbol + (category), component + package + device - I duplicate all of that, map it, and create a whole new “box” in my own directory. Yes - it’s a lot of work, but if you create specific packages 1 hour for each (on average 1/2), you have 10-20-30+ of them, do you understand why you try to protect it irrationally? Such behavior provided me with material to detect the error (I fought to recover the library) and share this information.

This is just my feedback on how I use the project!

Your work is great and full of commitment - I admire it.

The program is extremely valuable.

I am worried about the lack of funds (I can’t help much, a trivial amount).

Request :slight_smile:
Can you introduce selecting multiple pads and filling common (non-conflicting) parameters, e.g. the same width?
If I remember correctly, a similar method works in LibreCAD (QCad/2.2+ professional engine). For me, improving the handling of tables with dimensions will be a great help.

Yeah I know the documentation lacks many topics. Maybe I can give a try to add this section quickly…

I totally understand, I had the same problem with other EDA tools. Libraries from the internet were totally inconsistent, ugly, contained errors etc. That’s why in LibrePCB I enforce strict review and guidelines for libraries. And updates don’t necessarily need to be applied to projects as every project contains a copy of the required libraries. Maybe you should give these libraries a try :slightly_smiling_face: But of course it’s up to you.

This is planned, I hope it will be contained in LibrePCB 2.x. But the next release will already contain a similar feature which is very useful, see Package editor: Support copying properties to other objects by ubruhin · Pull Request #1412 · LibrePCB/LibrePCB · GitHub.