When I click on the info for a 2N3904, instead of the datasheet (which calls out fairchild.com, RIP) I get sent to an ON Semi landing page. ON bought Fairchild some years back and all of those links are FU now. I’d bet there are other issues of this sort as there’s been plenty of “churn” (M&A) in the semiconductor sector of late. It may not be worth anybody’s time to re-sync all of that collateral but thought I’d at least point out the problem.
if you have a github account, submit your findings here: https://github.com/KiCad/kicad-symbols/issues
if your a programmer there’s a suggestion for adding a simple URL-check to the KLC-scripts: https://github.com/KiCad/kicad-library-utils/issues/240
You had just help me conform the case where I had try to warning the KiCad develop about when they had move away/make it harder to reference datasheet to local files. Using relative path to the symbol itself had been drop, and required you to use environment variables. This do not play nice when you need to save “importance” datasheet with your symbol files avoid the URL link move around on the internet.
In fact, you are pointing to TWO problems that plague the whole electronics industry - not just KiCAD.
One is the ephemeral nature of web content. It doesn’t take a merger or buyout to disrupt access to a datasheet - it could be just a webmaster who gives his site a facelift.
The second is component obsolescence. At least your example (the 2N3904) is still in production - I suspect ON Semiconductor is down to manufacturing just a few dozen parts in TO-92 packages.
In the case of KiCAD, the straightforward solution to both of these problems is to distribute a library of datasheets (yeah, yet another library!). I imagine the file size would grow to gigantic proportions, though in a decade or so the datasheet library may become the most valuable component of KiCAD in some circles.
Dale
1 Like
The idea is not without merit. Obviously maintaining public library would be hard to do from the license perspective, as I am not certain the companies allow redistribution of datasheets. But since library format is open and human readable, one could write a tool which would parse the library entries, find URL to datasheet, download datasheet in private library and remap URL to point to local library.
1 Like
Datasheets change over time. Who updates the datasheet library? Distributing them simply moves the same problem one layer forward.
I agree distribute should be the last resort. It think URL or event nothing are fine for symbol. Every designer need to manage that in house themselves. Perhaps, there is a tool like @MitjaN say to localize one that needed by the designer. A capture to the datasheet is very importance, it help your 100 years project can be alive again, event none of the part are in sale. Using a moving target, and always up-to-date version isn’t help, and pointless on the design point of view.
Also, keeping a copy if of it very help full to help you confirm that new URL/update document still valid one. Otherwise, you left out with question is my symbol or footprint still work? Which versions of IC was it? What is the alternative replacement? What were the pinXYZ function?
In software development, it call tidy coupled architecture. One fall, everything else fall. At the last resort, designer need way to isolate themselves from external uncertainty first.
The same thinking can be apply to 3D Models, but why in this case they chose to cache all the models instead URL link to manufacture if they are easy for download? Perhaps, a mix of URL, cached, and generic shapes.
I have to say that I think the right answer is to eliminate the parts
Web link altogether, maybe just leave a field for manufacturer (at
the time) and part number (maybe another field for sub-version,
package style, whatever, as this can matter to some components’
detail values - think FET on-resistance, TO-3 vs SMD-2). Let the
user know what the symbol represents, and do their own legwork
from there. DuckDuckGo is happy to help; Datasheets360, even
better (more help than you can stand, maybe).
Your code developers and symbol-librarians should not be made
responsible for combing the shifting sands of Teh InterWebz every
time somebody buys somebody. That’s a full time job with zero
thanks.
Of course some sad gimme-gimme sack will complain about having
to do their own work, but I think the cost of accommodating such
laziness is plain and out of proportion to any benefit (in the case
of busted links, maybe even negative value).
I was mean the personal lib. But the main thing is not event the personal lib, it actually only importance for the project to cached all the 3D, datasheet that it used into one place/archive. For global lib I agree 100% with you @dick_freebird.
But I would think at least to have some predefine fields with empty value or something (doesn’t matter). If there are the fields for manufacture, part number etc. It will help all the projects start to use the same field names. That would be the only thing that good for, the value for these fields on global are not have any role at all to me. manufacture, partnumber, or URL may only use for showing where the symbol/footprint based from (documentation proof). But it the URL dead, let it be on the global lib…
With those predefine fields names - People can have script use them in more consistent ways instead looking for mfr, manufacture, mf… Also would promote atomic part consistency between digikey, or kicad lib, or any other may come up in the future.
1 Like
The 3D models are largely generated by KiCad volunteers. Most manufacturers restrict redistribution of their own models and place them behind sign up walls or outsource to one of the commercial 3D model library sites.
1 Like
This comes up fairly regularly and there have been several proposals in the past about standardizing fields - they seem to cause a lot of disagreement…
Just set a name by KiCad lib master (not enforcement/standardize). Use it or not still up to user. It better than have nothing. Naming or thing like this don’t need public agreement, or event vote! It will never get anywhere.
I thought you were suggesting that this should be in some way standardised. If that is not the case, I am not really clear what you are suggesting here?
I thinking way that people can write script to support at least a common consistent ways instead looking for mfr, manufacture, mf… , partnumber, PN, P#… and across projects.
This would help sharing scripting between people/project are easier. One way to promote this common field name is introducing them in KiCad Lib. Not to the KiCad software.
For my case, I love to know what is KiCad people name for there field for manufacture, part number, datasheet. KiCad software had introducing the Datasheet field (This to me is ok, but is is a enforcement to make all of it user had to use it this way – luck me that I had used the same name). If manufacture, and part number of in every symbol from KiCad Lib for instance, then it would tell everyone that a lot of people using it this way, so I better write my script at least compatible with it, or event use them for my projects. So this would increasing the efficiency of sharing… Like what if I now want to take Digikey part/other people in my project and it break every convention way that I had come up with filed name, just because I had not know the common style of these field name.
With this, people than can easily come up with script to help cached URL, 3D Files for project/projects, so that obsolete reference are not a problem to KiCad lib, or software. It just the problem for individual project (by using scripting/manual way to handling it). If scripting, this script will be easily to share by supporting the known common field names.
Or you know the script has a config file where you enter the translation between your field names and the ones used by the script internally.
That is much more flexible and would not give us librarians extra work. (If we add these default fields then we will need to fill them. Unless we want to answer one bug report a day why they are left empty.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.