At 03:12 PM 1/31/2002 +1100, Ian Wilson wrote: >On 09:17 PM 30/01/2002 -0500, Abd ul-Rahman Lomax said: >>Right now, if designators are changed, we are stuffed. > >Well, not in the case of an exported spreadsheet we are not. Designator >changes can be updated from the spread - since the matching is not done by >designator. In the case of an external (not exported) spreadsheet then >the situation is different....
No, with an exported spreadsheet we *are* stuffed *unless* the spreadsheet and schematic have remained open while the designators were changed *and* everything in the barely-tested spreadsheet code works as we might hope. This is a precarious situation. Sure, if we have permanent GUIDs, this would not be a problem. But GUIDs would introduce other problems. >>Physical location is not directly usable to recover links. So what is >>being proposed is the addition of facilities. If designator is changed >>but location remains, linkage can be restored. If location is changed but >>designator remains, linkage can be restored. If both are changed, yes, no >>method has been proposed to restore linkage. It starts to get difficult. >>But the difficulty has not been created by the proposed facility, it >>pre-exists. It might be possible to link on connectivity. I can't think >>of much else that could work. >> >>An unstated assumption was that part types did not change. "location" in >>what I wrote meant that a particular part type (library reference) was at >>a particular location. >> >>There would be a relink command that would link a spreadsheet to >>Schematic; it would make the linkages for parts based on (a) reference >>designator or (b) type/location. > >or (c) by matching the GUID allocated to each component (in my proposed >solution) which would of course be a readable but not changeable attribute >of a Sch component. It would be like a read only Part field (in that it >is component specific, not allocated by the library editor, but not >changeable). An external spreadsheet could have the GUIDs added >(manually/macros/whatever) to "force" a reliable match. Sure, GUIDs would make for reliable matches, but at the cost of severe inflexibility, in my view. If I have a schematic with a 10K resistor R25 on it, and I delete that resistors. Then I think better and replace it. The GUID is now different, isn't it? But *I would want any spreadsheet update to be able to work on R25 across this process*. It may take some thought, but this is why I suggested that connectivity also might be used to relink. If I renumber R25 but it is the same value *and it has the same connectivity*, it is clearly the same part even if I have moved it to another page. So we have a number of handles for linking: reference designator, which is good for most situations. For the others, there are physical location on the schematic together with part library reference, and, with even more potential accuracy, connectivity. If I have a schematic/PCB where R25 is replaced by D21, connectivity will tell me exactly what has happened, a resistor was replaced with a diode. >>Handles could themselves be restrictive, because they would need to be >>supplied for data import. > >Not really. They could be used if available - just as your solutions are >only as useful as the information that pre-exists. On external data >persistent handles become another option when doing the synchronisation >between external spreadsheet data and the Sch. Okay, persistent handles could be another possible method of linking. My point has been that relying on handles for linking is inflexible. But handles, if they exist, could be useful, just as they could produce incorrect results (like any of the other methods). For example, I have two resistors, 1K and 10K. The engineer says, swap them. So I pick them up and move them. Then the engineer says, oops, swap them back. So I edit the 10K to 1K and the 1K to 10K. Connectivity linking would be unconfused. GUID linking would get it wrong, presuming that a part retains its GUID when moved and when its value is changed.... >As far as I can see it: >1) Improving the existing limitation on editing Sch in a spreadsheet >requires persistent handles. A GUID is one option. I disagree. Persistent handles would be useful for the single problem of how to allow closing the files in the middle of the process. Persistent handles would thus be useful, but they would not increase the flexibility of spreadsheet editing for import of outside data. Methods of component matching besides a GUID could also solve the persistence problem; essentially they would generally allow re-establishment of links. It is common in database translation programs to have a field-matching wizard. >2) Others dealing with external data (often) have some use for additional >tools that would work somewhat like the current Sch<->PCB synchroniser but >with spreadsheet data. Useful match methods include: Designator, >Location, GUID and .... > >Do we agree on anything? Sure we do. We agree on a lot; if we disagree it is on emphasis and priority. I suspect that I am thinking a little more broadly, trying to suggest solutions to a broader range of problems, not just the persistence problem. Further, I'm thinking of schematics as tools for generating netlists; if two schematics generate the same netlist they are fundamentally the same schematic even if they may appear to be very different. Where they differ is in how they make the connectivity information visible to the human reader and also in the accessory information that we use schematics to carry and generate. But this discussion, at core, is about linking the elements of two different representations of a schematic, and possibly about making this link after one of the representations has been edited. The accessory information is not a problem. What is a problem is identifying parts which may have been moved or which may have suffered a reference designator change or maybe even both. I think I have shown that a GUID *might* help in this, but it might also be inferior for this purpose to other techniques. A combination of techniques might be used, with weighting or preference. If it is the same refdes and the same location and the same GUID, obviously we have made a link. If it is the same refdes and a different location and the same GUID, perhaps it is the same part. If the connectivity is the same, then bingo, it is definitely the same part. Connectivity is king. One tool in establishing linking (I've had to do this manually more than once) is to identify a known part. Once that part is identified, connectivity for the rest of the schematic will generally fall out. [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
