I’ve added a number of IC symbols in a schematic, most contain 2 or more elements, such as a dual-timer, a quad op-amp.
I’ve been searching the forum for answers to how to change the documentation type from http: to a folder location containing a PDF file in a Win10 Pro external USB drive. When I change the documentation in one of the dual timer elements it also modifies two of the op-amp elements for no apparent reason.
I prefer pointing to my IC datasheet PDFs stored on my local USB drive rather than using a web link that may or may not be around tomorrow. I’ve read where the documentation field supports different MIME types and understood this to mean DOS drive:\directory\file locations.
What gives?
Edit: I’ve discovered that, at least in part, it is related to not having generated a Netlist. After doing so, updating the documentation field on one op-amp element in the quad, it appears to update all of the op-amp elements, ditto for the dual-timer element documentation directory link.
But there is inconsistency in other symbol component such as a hex CMOS inverter. Of the six, four of the a,b,c,d,e,f elements were changed to LM556 along with documentation pointing to the LM556.PDF, but two were not. After creating the Netlist, changing the name of one changed only 3 more, but not the last two elements.
I need to better understand whether or not there is any “linking” between each quad op-amp, hex inverter, dual-timer section to the other elements within their given package, because at the moment it seems a bit erratic.
Strictly speaking a local file URI should start with file:// So paulvdh’s example should declare KIDATASHEET to be file:///home/paul/electronics/datasheets (note the resulting three /'s). This is in case you encounter a strict, unforgiving browser some day.
“http://” and “https://” are common prefixes for web browsers. Some time ago it became customary to hide this part of the URI, but thankfully it’s back and the show the full adress by default in the adress bar these day’s. I can also use “sftp://” to reach my NAS-wannabe.
I did not give the creation of my custom variable much thought. I just duplicated what was already present in KiCad
That’s because the file path on paulvdh’s Linux machine starts as /home/paul/… The third / is not part of the scheme indicator but the beginning of the Linux pathname.
So, for Windows 10 Pro, the “file://” prefix to a normal DOS file path worked for some symbol documentation PDFs but others resulted in “File not found” even though the file was there.
Edit: Restarting KiCAD had no effect.
Changing the KIDATASHEETS variable back to a normal DOS file path (drive:\folder\folder), made all symbol documentation references open properly.
It depends on the browser used to view the documentation. If it’s say a PDF viewer rather than a web browser it may not know about general URI schemes and in this case you have to defer to the local situation.
Adobe Acrobat Reader is not a web browser, and what I use by default for PDFs. I’ve no idea what is involved to use a web browser PDF viewer instead of a PDF app.
But you’ve explained what was happening to me, thanks.
And it’s not even possible to reliably change the pdf viewer for KiCad and use URI. Here on Linux (Kubuntu) I can change the PDF viewer to e.g. firefox in KiCad’s Preferences. However, then I can use only the normal file path starting with / to open it with firefox. If I use file:// it probably goes to directly to the system, bypassing KiCad’s choice, and it’s opened with Okular which is the default PDF viewer of my system.
Also firefox can delegate handling of MIME types so some installations may handle application/pdf with an external program.
Anyway it’s probably moot in the OP’s situation since a local directory isn’t portable to other systems, but it may matter for say a distributed package that uses a local library of PDFs in which case somehow the path has to be adapted to the end user situation.
