So what i was wondering having watched the video is that he seemed to not understand why it would be done any other way than the old fashioned way and from what I understand he effectively runs kicad as he guides it’s direction and decides what edits to put in. I am still exploring what is available obviously both ways of working can run in parallel as things stand and i hope it stays that way.
As things are at the moment a component symbol that already points to a footprint just goes through to the PCB but if a footprint is not pre-assigned it can be done in the transfer phase manually which is perhaps better than the whole thing constantly failing like other packages do because they can’t find an assigned footprint.
When i heard that it was immediately clear where your confusion comes from. I am willing to bet my live on the fact that it is a misunderstanding. As mentioned above: wayne is acutely aware of the fully specified symbol workflow. He has on numerous past ocations put us librariens on the spot and made it clear that footprints need to be assigned correctly. He would not do that if he would not believe in that workflow.
The problem of this thread is that you do not believe people who closely work with the devlopers.
Or you missed who you talk to. For you info i am the current head of the kicad library team. I would now about any plans to scrap this feature.
I just watched the relevant part of the video again (https://www.youtube.com/watch?v=NRwTyBX2BFk and about 6:30 ff.) and I can interpret it only in one way, namely that the way the KiCad’s own libraries are done will not change. Wayne explicitly says he understands both ways.
I can understand that without background information someone can interpret Wayne’s comments differently. But you didn’t give him any benefit of doubt nor did you ask us what he possibly meant or did he really mean that, you just assumed his opinion was against your workflow and started the discussion quite agressively. That’s why the whole discussion here went in a wrong direction. Forum veterans also sometimes come to conclusions too hastily without much patience, it’s not necessarily you alone. Is it possible that we now give it a fresh start? No blaming anyone anymore?
I don’t hold grudges, as I said I have not used KiCad for years and the library management has been a well known and admitted issue which is why I was concerned. From what I see it’s much better than it used to be and will now work for me.
Wayne just confirmed in the mailing list that KiCad won’t provide atomic libraries but the users can make their own and “There is no plan to change the current allowable work flows.” On the contrary, KiCad will be even more flexible than now.
Ok , everyone is using the word atomic differently so there is some confusion.
I have been trying to use it synonymously to @Rene_Poschl term of “fully specified part”, I believe.
Note that the term “Atomic part” appears on the KiCad Library Convention Guide https://kicad.org/libraries/klc/G2.1/ and that is how I have used it in every response here
@Rene_Poschl@eelik can you help communicate to wayne/devs that this is not about having a single atomic “library file” where footprints and symbols are tightly coupled. But simply the 1-to-1 association described in the style guide being better integrated into KiCad library management .
That being said atomic/fully specified parts work today, atomic libraries don’t exist, and derivative/sibling symbols are part of the plan for v6. Sounds to me like everything is moving in the right direction
Well, to be truly honest, some of the parts in the libraries are fully specified. Look through the MCU libraries, a lot of the sensor symbols, and others. Just doesn’t make sense not to since a specific uP in a specific package may have a different number of pins than any of the other packages that uP comes in. But they aren’t fully specified for the more jelly-bean parts (discrete components (L, R, C, etc), TTL logic chips, transistors, etc.).
The confusion being that “atomic libraries” was interpreted by the Dev team as “Monolithic library structure”, inseperable, in the same file, in software terms, similar to “integrated library” from altium land.
Two different domains, different interpretation. Libraries of atomic parts exists already as you point out. Rene is alergic to the term atomic and so confused me, thats OK, I think everyone is can be on the same page
to reiterate
Sounds to me like everything is moving in the right direction
I had already re-written that description of the KLC but other maintainers pushed back because it of course would have meant that some things that are now in the gray area would have then been clearly not allowed.
Which is what i said earlier, it’s a really scary prospect to be assigning that sort of part on the transition to schematic over and over again because the symbol may only be valid for one footprint so the association is already implied so it makes sense to more than imply it so things don’t go wrong. But if you do want to use the full part number then you will find that some chips while having different footprints also have different temperature/speed grades like the lagacy AVR so it can kind of push you to want to create the specific part number you will purchase. Personally i do this.
things like resistors you could assign at the transition, personally I just fully specify those too as the tolerance is part of the design and I usually know the package size because I know the power dissipation because i chose the value and know the system voltage etc. Same with capacitors with no two electrolytics being the same you want to be careful someone does not make an unfortunate substitution and pick a capacitor meant for mains filtering for a circuit works at a higher frequency.
Not some. Nearly all symbols are made that way. Only the device lib, the connector libs and the logic family libraries contain generic symbols. Everything else uses fully specified.
We might however also convert the relay library over to generic but that will require a lot of work. (Similar to the audio connectors we will need to define a convention for naming pads for this to work. We have an idea for that but did not get it done yet.)
