A note first: this could be getting fairly abstruse. We are discussing the 
fact that to use the spreadsheet to edit data on a schematic requires that 
the schematic and spreadsheet remain open from creation until update, 
otherwise it fails because internal links between the spreadsheet records 
and schematic primitives have been lost. One can see these links if one 
copies the spreadsheet data into Excel.

We'd like to be able to update schematics with spreadsheet data where the 
links have been lost, perhaps because the files were closed, or perhaps, 
even, because the links never existed since the spreadsheet data came from 
outside. To do this, the new spreadsheet data must be linked, somehow, to 
appropriate schematic primitives.

At 08:24 AM 1/31/2002 +1100, Ian Wilson wrote:
>>Well, having the facility to create the links based on designator would 
>>be useful. That way one could use the spreadsheet to manipulate all other 
>>aspects. The other way to recreate links would be through physical 
>>location. In other words, if one had a spreadsheet where designators had 
>>been changed, one could still restore links through physical location. 
>>This would be *very* useful to recover schematic-PCB correspondence where 
>>someone had reannotated the schematic.
>
>And when we have changed designator and location we are broken.  Why add 
>the limitation on how we are to operate?

*** Reality Check ***

What is being proposed is the *addition* of facilities, not limitations. 
Right now, if designators are changed, we are stuffed. 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. Whatever cannot be recovered by these means would be 
ignored. In other words, if you have a spreadsheet with ten parts in it and 
nine of them can be relinked to parts on the schematic, nine would be 
linked, the tenth would be ignored. A message would presumably be issued 
giving some information about the ignored part, ideally its data would be 
dumped to an error file.

This would mean that you could modify parts on the schematic directly from 
spreadsheet data from some outside source, presumably linking based on 
reference designator.

The facility to link based on schematic sheet coordinates would allow 
recovery from reannotated schematics. It wouldn't have much other use.

>My fundamental issue with the sorts of solutions you are proposing is that 
>they tend to be adding restrictions that we do not have in order to remove 
>a restriction we do currently have.  I would like a solution that removes 
>the current limitation without adding another. Making the handles 
>persistent would allow this (though the persistent part can't be a real OS 
>handle of course.)

Handles could themselves be restrictive, because they would need to be 
supplied for data import.

Suppose a schematic has been drawn with no values for the resistors, and 
there are a lot of them. After extensive experimentation, Engineering 
supplies us with a list of resistor values on a spreadsheet and asks us to 
import them to the schematic. Right now, I would generate a spreadsheet 
from schematic and then stuff the values and update. Not too bad, but it 
could be better. (Its easy to say, but there are presently many little 
gotchas in working with spreadsheet data; for example, to paste the values 
in, I need to have both spreadsheets in the same order.) With what I am 
proposing, I could take the spreadsheet supplied to me by Engineering, name 
the fields according to what Protel expects, link it keyed on refdes, and 
update. I could have sent Engineering the spreadsheet in the first place 
(with blank or dummy values), so the field names would already be correct.



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

Reply via email to