On 01:22 AM 31/01/2002 -0500, Abd ul-Rahman Lomax said:

>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*.

I wouldn't - it is a different resistor, just so happens that one attribute 
is the same (designator).  I hate designators being special - one of the 
best things about the synchroniser is that it does not rely on designator 
except for initial match.

But I will grant this - Undo should re-instate the previous GUID rather 
than create a new one.

>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.

Precisely, inflexible but precise.  This is almost always what I want as I 
am almost *never* taking in external data.  It is almost always exported 
twiddle (possibly using external sources) and then updated.  I would 
suggest that this is the most common use of spread export/import at least 
for the engineering design community.  That may differ from the contract 
PCB design community where external data is more common.

>  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.

I do not consider this incorrect, on the contrary - if I have a strict 
company part numbering scheme and the Sch feeds back into a complete MRP 
system then what I want is a unique number that I can track changes and 
deletions.  Designator no longer cuts it.  We spend a bucket of time on 
configuration control.  Unique component numbers would suit me really 
well.  Already an increasing number of designs we do (both internal and 
external clients) use the "one manufacturers part number one SchLib part" 
library system.  So the issue of simply changing the value of a component 
is not on.  I am hoping that the next version of Protel may in fact allow 
every component attribute to be locked at the library level (apart from 

In the above scenario, the correct manner of dealing with a component value 
change is to copy a correct value part of the sch or to place a new one of 
the correct value.  or more sensibly to swap the components back (in your 
example).  This may seem like more work to the person laying out the Sch 
but the back end work reduced can be enormous - especially once a design is 
under ECN control. Once under ECN, a designator change can be a huge 
undertaking.  In some companies I have seen standards that disallow the 
reuse of designators to prevent the reduce the chance that a old iteration 
part list is used, so causing a wrong value to be fitted.

The increase in rigor required at the front end directly reduces the scope 
for configuration control errors later (at which time they cost more and 
are harder to fix).  So the forced reliance of strict matching can help to 
reduce the human element.  But I can still sort my spreadsheet and not 
include all the columns - which will cause some interesting changes.. (but 
ones that will be detected in the back end database systems that will 
detect masses of invalid value changes etc).

How does this relate to the point under discussion?  For us we have almost 
no external data that can not easily be merged into an exported spreadsheet.

So any solution that does not allow for *forced strict* matching would be a 
potential hole in our configuration control system.  So any other option 
for matching would be an option we would probably rarely use that we would 
want to be able to disable.  (This raises the idea of Admin driven design 
options and tool configuration.)

One point we have not addressed, yet, is that currently any entity can be 
exported and modified in the spreadsheet and then updated.  the bloat from 
a GUID attached to every entity could become significant, I will accept that.

We are definitely coming at it from very different viewpoints.  It is now 
Protel's problem to think about all this and to distill it into realizable 
and useful implementation (assuming they haven't already done much of this 
and assuming they think any of it is a good idea.)

bye for now,
Ian Wilson

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
* Contact the list manager:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to