Change of Workflow

Sorry about this and if I get the words or thought wrong.

As presented the software appears to be biased towards PCB packages as opposed to Schematic Components.

It seems that if I wanted to create a base MF25, Metal Film Axial 250mW resistor as a Schematic Component and then derive a Family of Schematic Components, MF25100R MF25110R, MF25120R, from that I am forced to create and assign individual PCB packages to each Family Schematic Component.

To me this appears to be the wrong way around in as much as it is the Schematic that contains the base and maintained information for the project. I would rather define an MF25 family of Schematic Components assigned to a single MF25 PCB package to those components.

Looking at and deciphering a manufactured PCB is a lot harder than looking at the Schematic.

Hope that makes sense but I could try harder with some pictures…


I’m not sure if I understand your question. All you need to create for an MF25 family is one package and one device (component and symbol already exist). Then add MF25100R, MF25110R etc. as parts to the device. It’s not described yet in the documentation because it was just added in LibrePCB 1.0.0 but it should be easy to see how it works:

If this does not help, please clarify your question, if possible with pictures.

Sorry for the late reply. I’ve only just come back to this, tried it again, failed and then come back to the topic to see your reply. Having poked about with it I think I have understood. I may still have to rethink things a bit but…

Rather than entering the part numbers/values one by one as in the second picture is there a way to ‘hack’ the files…?

Oh! Hang On. I may have found it…

And… Fingers Crossed

That seems to work. So I should be able to write a little program that adds that range, E6/E12/E24 etc, to the device file and save a bit of time.

Something like that anyway.

Thanks for the reply and apologies for the late reply.

OK good you figured it out! :+1: Welcome to the world of human readable/editable files :grin:

Just a small note: Generally I’d recommend to set the attribute type to “resistance” to get the values displayed as “100Ω” instead of “100R”. But of course generally string attributes work too…

Thanks. It’s something I did years ago with an old version of Protel, also human readable/editable files. The company I worked for used something else and had kittens when I suggested I wasn’t going to touch it. I got the chap who did stock control to do a csv dump of the company part numbers and stuffed it into Protel in a couple of days.

I guess, as with anything new, you get to jump hurdles as you find out how to do, or undo, new/old habits. The first thing that slightly floored me was the Component/Package categories in as much as they are ‘flat’

but, ultimately, they are not…

Screenshot from 2024-05-25 17-13-53

Given it is a TTreeView [?], I get that you set it up by setting up the parent/branch when you add a new category, would it be better to have right click on a root item and add below then have the first picture match the second picture.

If that kind of makes sense I’ll assume that if you make a change you will break other peoples heads but in as much as the second picture shows the expand arrows they would now appear in the first picture as a visual clue that, hopefully, people would recognise as being a known navigation element.

In respect of nomenclature wars I had noticed the attribute type but I am used to



and so on.

Oh. Thinking a bit harder about that one. If, in the first picture, it becomes a tree view then the second and third panels need only display items in that particular ‘bottom’ category. I’m not sure but it might tidy up the overall display.

Just FYI, this has already been discussed and is tracked in an issue:

I know this is the concept used in most other EDA tools and of course you’re free to do this in LibrePCB as well. Just note that the idea of our type system is to be able to provide “smarter” tools in future - for example to suggest a list of concrete capacitor MPNs for a given capacitance value, LibrePCB knows that 100nF and 0.1uF represent the same value so even if the distributor uses a different unit than in the schematic, LibrePCB can find all matching capacitors. But this only works fine when using the proper attribute type. However, at the moment it doesn’t really matter as no such feature exists yet… :wink:

Thanks again.


Not easy to fix since a library usually contains only parts of the category tree, not all of them. Let’s consider a category “A” is in library “L1”, and its child “B” is in library “L2”. If L2 is not installed and you open L1 in the library editor, the parent category of B is not available so it’s impossible to render it correctly.

Maybe for such cases a virtual “Unknown” category could be displayed instead, probably we need to make some experiments to see what works well.

This may be wrong but it strikes me that when placing a component you get the TreeView and then when you are building a library you can bend it to kind of do the same.

What I find is that if I scrub the lot and load the recommended libraries they seem to be fragmented in terms of Symbols/Components and Packages/Devices appearing in different places/libraries but they are referenced back up the tree using dependencies. A library can depend on another library.

This might be what you are referring to in terms of dependencies. Perhaps a Device in one library refers back to a Component in another, further up the tree, library. I’m not so sure it should work like that but I’m not trying to make waves. As it stands it can be kind of bent to my way of thinking.

I don’t hit Symbols/Components and/or Packages/Devices until I am at the bottom level of the, it is what it is, tree of libraries. I have not fully tried it but I was wondering if I could load the recommended libraries and reference a dependency back from one which I had created back into one of them but that does not seem to work.

Unless I have missed something, I probably have, it seems that it should be possible to collapse everything back into one tree from the outset without breaking things. However I’m not the person doing the programming and since I can bend it to make it work the way I would like I guess it’s not a problem.

I’ll just suggest that at first glance, for the average idiot like me who does not read the manual… I missed the dependency thing, it could make more sense and overall give a tidier and more meaningful result at that first glance and later on. Rather than having multiple open library windows it could be folded back into one with the Symbols/Components and Packages/Devices only being displayed when the main Tree is expanded to select them.

Apologies if that does not make sense.

Ooops. Having babble on I appear to have lost the dependencies. They were there and it still seems to work without them. Grrrr. I’ll go put them back in. No… it throws them away again. I guess since there is no referencing back to an actual ‘thing’ I’m still doing it wrong. No. I had broken something else by renaming something.