Imagine a typical Schematic with an op-amp shown as a triangle in the middle. The user double clicks on the op-amp and expects to "push into" or edit those parts that are in the op-amp. What does the software actually do when the user requests to see the contents of the op-amp? Well, the op-amp "use" in the schematic has a data item in it that says "I am from C:\schematics\op-amp.sch" and so when asked to edit, the code opens the file C:\schematics\op-amp.sch and shows the contents. This sounds very simple and easy but there is a problem. Suppose the user copies the schematics to another machine and the disk on that machine is named E: not C:. Now when the schematic looks for C:\schematics\op-amp.sch (because remember that name is in the "use" object - it's in the database that represents the schematic) it wont find it. If the user copied the files in an obvious way perhaps it's in E:\schemtics\op-amp.sch.
How shall we solve this potential problem? One solution used by many tools is simple: always use a relative pathname. So for example, the "use" would not contain C:\schematics\op-amp.sch it would contain for example, ..\schematics\op-amp.sch. This means go up one level then come down in schematics and look for op-amp. This solution solves the problem we postulated: now on E:\schematics\op-amp.sch (or indeed on E:\my-stuff\kelowna-stuff\schematics\op-amp.sch) this rule of "always use relative pathnames" works fine.
And thatís about as far as most, but by no means all, CAD tools go. We quickly learn that if we want to move a design to another place (take it home for example) all we need to do is copy the entire directory and we will be able to open the schematics on our home machine. Indeed, some engineers even use this knowledge that relative pathnames will be used to archive or copy their design, to substitute a new cell into a design etc by changing files "behind the back" of the software as it were. They know the software will just load up whatever file is there. These (archive, copy, change) are all good things, clearly.
So why not do that? Why donít I just use relative pathnames? Well there is another problem with relative pathnames. Suppose some common designs (PADCELLS for example) are kept in a file \\Capella\e\design\padcells\ for example. Now on CAPELLA we could use relative pathnames: we could be working in \\Capella\e\design\myschematic\ and use ..\padcells\io.sch to find the padcell. But what if we are on another machine? Now we cant use relative pathnames. We cant send a file from one user to another and have him use the library of padcells, because clearly he does not have the same relation to the library that we do. [What do other CAD tools do about this problem? In my experience they define multiple search libraries that may be assigned to the PADCELLS directory. This is then similar to the Logical Pathnames as used in the Schematic - you may imagine that the logical pathnames are the libraries if you wish.]
This is where Logical Pathnames help. On each machine PADCELLS is defined to point to \\Capella\e\design\padcells\ in the data base the file name is stored as "PADCELLS:IO.sch" and the tool first looks up the "Logical Pathname Translation" of PADCELLS and finds it to be \\Capella\e\design\padcells\ and then appends IO.sch to make the correct "Physical Pathname" \\Capella\e\design\padcells\io.sch.
So pathnames operate like libraries: they name an absolute file someplace and resolve the name somewhere "under" that pathname.
To see the Logical Pathnames use the Options > Logical Pathnames menu item, which will bring up something like this:
Here you may change the translations from the Logical Pathname to the Physical Pathname