Some time ago I made an environment variable called KICAD_DATASHEET_DIR and I’m pointing more and more of my schematic symbols to it.
The datasheet links to the internet constantly break. It might be ignorance, but I suspect it is sometimes/often done on purpose because manufacturers don’t want us to use their parts (or other reasons…).
I think it is a good Idea if there were support for KICAD_DATASHEET_DIR, and that that location is checked first for availability of datasheets before attempting to find it on the internet. I am in a habit of saving all datasheets in lowercase names and stripping all suffixes from the datasheet .pdf. which makes it a lot easier to match the base name of a component with a datasheet. And Eeschema could (try to) match the base name of the “value” field to files in the datasheet directory (Including sub directories).
This can easily be extended by adding symbolic links in the datasheet directory for datasheets which have aliases or datasheets which handle multiple parts (TL71, TL72, TL74 for example).
This will greaty improve the chance of KiCad being able to find the datasheets for the parts I use, without having to update the Datasheet field manually for each part I use.
I’m just curious what others think of such a feature.
If I put it on Launchpad, would you click the “This affects me to” button?
Edit:
A similar name for the location of SPICE models would also make those easier to manage (I have temporarily given up on ngSPICE because my attention is stretched too thin over multiple subjects).
I would assueme the implementation of this would most likely be best done by being able to add multiple datasheet urls with a given priority listing between them.
I am not sure why a kicad pre defined variable would help to be honest.
I can already ensure you that the official lib will most definitely not ship with datasheets. For many reasons starting from maintainance (people will start to blame us for out of date datasheets) and also copyright as i am not certain one can simply redistribute datasheets without permission. (I am quite certain that a lot of manufactures have copyright notices attached to their datasheets that would be incompatible with the official libraries license.)
So what would you expect this pre defined variable be used for exactly? And where should it point to? (If it does not point to kicad shipped datasheets then it really makes no sense to point to a system directory where the user has no write access)
Most users who use KiCad will have a personal collection of datasheets gathered from various sources.
The KICAD_DATASHEET_DIR is an easy link to make an (implicit or explicit) link to the datasheets gathered by the users and Eeschema.
I have some “Open Documentation” links pointing to datasheets, and others to bitmap files of modules to only have a quick reference to verify pinout etc.
KiCad does not do anything with datasheets itself, so there can be no copyright issues, it just provides an easy link to whatever a user adds himself. Also, because users have to add their own datasheets the amount of fuss by “outdated datasheets” will be much less. (Some people will still complain “why doesn’t the world revolve around me?”)
I have been hogging (a lot of) datasheets for years before I used KiCad and having KiCad start a web browser for a dead link by default instead of opening the file I already have locally is not very usefull.
I like the Launchpad idea of having multiple sources for datasheets, and having an $KICAD_DATASHEET_DIR) as one of the search locations for all schematic symbols makes it a lot easier to make the links between Eeschema and the user maintained datasheets.
Edit:
Sometime ago I made a link “[RMB] / Open Documentation” point to a .png file and KiCad opened it in a picture viewer. A .zip file gets opened in an archive manager, but a .txt file does not get opened in my default text editor, while double clicking on it in the file manager does open it.
Hmmm, “[RMB]/Open Documentation” does open and play an .mp3 file (for which I see no immediate use), so the text file not getting opened may be an OS / mimetype related issue.
I read that bugreport a few times but the more I read it the more it sounds like the OP wants KiCAD to facilitate (in some form) documentation management. For KiCAD to provide a link to external documentation is good if not necessary - but I’d say that the numerous pieces of info that could be pointed to should be done by external apps that are OS and user specific.
I am all for standardization but not entirely getting how this helps. You have a variety of info in different locations and this variable will help out with the organization of this? Forgive me for being foggy…
Documentation of all components is very important - it can never be pointing towards an outside source. Not only because that source may go away but also because 20yrs from now you may need to know the specs of a component you used so you can properly replace it with something else (been there done that).
I am on a mac and use DevonThink for component database. It houses all datasheets, appnotes, guides and other smarty pants stuff. It is organized by manufacturer, documentation type and technology type, with the main group taxonomy following digikey’s taxonomy. I set up my symbol and footprint libraries accordingly. The KiCAD “Datasheet field” contains a link to the datasheet in DevonThink, double clicking it brings it right up in DevonThink. Its a total dream compared to the ocean of books and papers we used to have in doc-control. DevonThink only exists on the Mac but I am sure there are equivalents on windows/linux …
That “DevonThink” seems to be some external application you have to install separately. Correct?
And how do you make the link between Eeschema and DevonThink? You have to edit Eeschema’s “Datasheet” link for evey schematic symbol separately by yourself.
You prefer DevonLink, I want a simple link to a directory where I have collected datasheets. Some “universal” mechanism that works for all schematic symbols would be nice.
If I were smarter I chould have figured out on half a finger that the dev’s would be well aware that having static links to pdf files somewhere on the 'net is not the most optimum situation for handling documentation.
Maybe I should not have brought the subject up at all at the moment.
One of my T-shirts says “Good things come to thosw who … wait”.
The question is not if it is a good idea to allow for a second (or third or n) alternative links do datasheet info. We already know this is a good idea.
The question is how would a pre defined environment variable help and what should it point to (a pre defined variable must point to something. It can not be empty as you would end up with strange things called exceptions that way.)
A user would have to set it himself in KiCad, but the schematic symbols use it to find documentation.
Adding $(KICAD_DATASHEET_DIR) manually to the list of environment variables is easy and trivial, but without changing the “Datasheet” Fields in each symbol separately it is of not much use.
If it has to point to something in a cleanly installed KiCad, then it can simply point to the users home directory. I can make it point to “/home/paul/electronics/datasheets” easy enough, but the issue is that such a link is not used by any symbol unless you manually edit it.
For me, a default path that gets searched before the internet would be adequate.
Joost seems to want an external program started (DevonThink) for documentation. I do not know how that works, but I assume he wants the symbol name as a parameter for that program.
For shared projects, all datasheets for that project could be accessible via a local or remote file server. It’s just for having a default name for a project to search for datasheets, so it only has to be set once for a project, instead of for each component separately.
For Spice libraries it is similar. KiCad can not be responsible for managing spice libraries, but having a default location to put those files helps in maintaining a level of uniformity.
Yep, DevonThink (DT) is a paid for, external app. It is meant for documentation management/research etc. and goes well beyond the needs for harvesting datasheets. You can use it across multiple installations/Macs and sync the database(s). Each item (datasheet) has a unique link that is preserved across the independant installations. That unique link is what I plunk into the ‘datasheet field’.
So my symbol lib contains symbols with these DT links. New schematics introduce new components but not tons so a couple of new links is not a problem. The “Datasheet field” as KiCAD supports it right now, works and is sufficient for my purposes.
But I am not a DT sales person (although by now I may sound like one). From your last reply I understand that you prefer to not populate the Datasheet field but have kicad search your proposed link instead. That would mean some sort of file name convention so KiCAD can find the appropriate component datasheet, no?
How unique is that DT link you put yourself in each schematic symbol?
Can DT handle it if KiCad starts DT with the name of the “value” field (which is the part number for IC’s) to DT?
If that works, you would not have to edit the symbols at all, but only manage the backend part in DT.
Disk space is cheap now days. I download the data sheets when I get the parts if I can get them so no worries later on. I mirror my home directory which is on its own raid and, yes,I do backups. 3 to 5 terabyte USB drives aren’t that expensive anymore. If I lose it all in a double failure I have more problems that tracking them back down on the internet.
And how usefull would it be if you can tell KiCad to use your NAS as a default search location for all datasheets? Just a default of “$(KICAD_DATASHEET_DIR)/$(ValueField)” would make managemet of such things a lot easier.
Hmm… Never looked into linking them to Kicad. Probably should be more diligent about personal libs for all parts I have/use I guess. Opening a file browser would be more useful to me. Having it open to at least the top directory of my sheets would be a nice thing.
Edit. It isn’t uncommon for me to have at least one part open in Okular so I’ve just been using that for navigation.
It’s al about pressing the right mouse button over a schematic symbol and have the “Open Documentation” do more then just search for a static link on the other side of Internet, and ways to implement this in an easy and flexible way.
“Open Documentation” can already handle different mime types. http:// links get opened with a web browser. local .pdf files get opened in a .pdf viewer. .png gets opened in a picture viewer, etc.
That link is generated by DT. It needs that format as it refers to its articles that way. On macOS apps can be linked by this sort of internal URL. If I take that link into the web browser, it opens DT with that datasheet also.
When I capture the datasheet from within a browser, it is immediately handled by DT and stored with the taxonomy context as I mentioned above. The datasheet is named by DT which is most often how it is named by the supplier/manufacturer with corrections so it stored properly in the macos file system. The link between KiCAD and DT would then come down to a datasheet naming convention. I would find that more cumbersome and error prone. Like I said, I do not do a ton of link creation as my database grows I use fewer new components. Copy and paste a link is really no big deal.
But if KiCAD can support the existing datasheet link and your proposed default folder link for a cheap and cheerful doc system - lets do it.
Sorry to skip reading in detail. But I think Relative path is best for me (not oppose to the environment variables). Since it not required me to configure the Environment variable every time some one check out my lib repo. Also, with Linux, and Windows system now a-day, once can just create a “link” folder, then Relative path actually cover more use case than just environment variables.
