On 09:02 AM 12/06/2001 -0500, Tim Hutcheson said:
>Hi, Ian.
>
> > so the program as I understand it cannot support this as there is only one
> > copy of a symbol stored in the schematic and each reference to the symbol
> > uses that one copy. Changing the pins about affects all instances of the
> > symbol. Since this can't happen with the existing sch structure there
>would
> > need to be changes to support it - pin editing on the sch was dropped when
> > Protel released their first Windows Sch package (from memory).
><...snip...> But in
>reality when I am looking at the PCB and the schematic I am doing nothing
>more than what I think the system could do by looking at the MASTER.NET file
>and the generated.Net file and reannotating the discrepancies.
This is the sticking point - how should the system do this re-annotation?
The re-annotation of the components is already provided at least for manual
re-annotation - this is done by the synchroniser (remember the sychnroniser
does not use the designator to match components - apart from the initial
suggested match).
There is a problem with rewiring or renumbering the pins. Renumbering the
pins is not an option (with the current schematic format). Rewiring would
most likely cause a great big mess. If all your resistors are individual
parts of a multi-part component then the back annotation by the
synchroniser could fix much of the problem if the synchroniser was
intelligent enough to be able to detect an implied designator change
brought about by PCB tracking. When the system detected possible gate/pin
swapping it could prompt for confirmation of the swaps - much like it does
when it tries to match Sch and PCB for new components by designator.
I agree that it would be great if the system was smart enough to do this
automatically. That is, by inspecting the pin numbers of the PCB part and
the matching Sch symbol the synchroniser should be able to re-map both the
designator and the part of the multi-part symbol. But to do this the
synchroniser would need to be made a lot more intelligent as it would have
to be able to understand that in some cases it should re-assign hidden
matching handles - this is where it would get dangerous. The synchroniser
can track arbitrary manual changes to designators with no synchronisation
issues (barring bugs) but it is not able to track implied designator
changes caused by routing.
Your suggestion may sound simple but any way I look I see complex issues
for an automated system. If enough of us ask for gate/pin swapping
capacity then Protel will see a need to implement something. They know the
file formats and the database structure so are in a better position to see
what can be done easily. But we are in a better position to thrash out
what it is we want.
I think I might drop the issue, at least until there is some fresh
perspectives on this whole issue, as I am boring people I think.
bye for now,
Ian
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
* - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[email protected]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
