On 02:35 PM 11/05/2001 -0700, Brad Velander said:
>Hi all,
> I know that this has surely been asked before but I am running into
>it now and can't force the P99SE to conform to my will.
>
>I have two connectors, in the original netlist they were miss numbered once
>I started the layout so I changed them in the PCB and then the schematic. I
>manually adjusted the netlists and carried on a while longer. Then it was
>time to bring in some more changes via the schematics. The schematics are
>100% correct and match my PCB 100% with regard to these connectors. The
>synchronizer does the following:
>
>1) disconnects the existing nets from both connectors. Even though they
>match the schematic circuit exactly.
>2) it then swaps the two reference designators with each other.
>3) then it connects the same two nets to the same two connectors(by ref des
>#).
>
>Result: I have the two connectors swapped for location and connections.
>
>How do I get the synchronizer to stop changing my reference designators back
>to the original configuration and then miswiring the nets?
>
>A while ago I mentioned that there seemed to be some hidden form of
>component matching between PCB and schematic, someone said I was mistaken.
>If I was mistaken, how does the synchronizer know what reference designators
>in the schematic to change back to once I have changed them?
Brad,
You are not mistaken at all about the hidden component matching - look up
synchonizer in the online help. The synchroniser works by maintaining a
hidden handle (32 bit integer I suspect) that is unique for every component
in the design. Matching components in the PCB and Sch have the same
handle. (I s'pose that this means there is a limit of 2^32 components in a
design - bah! Don't you hate software that limits ones creativity!). A
component initially has a null handle (I assume) and when you run the
synchroniser (in either direction) and it detects any null handles it will
pop-up the component matching dialog. This matching process is where the
handles are assigned to the PCB and Sch parts.
You can see the handle if you export a design to a spreadsheet and then
unhide the first (I think) column. Protel used to do forward and back
annotation using the designators but this is very likely to get out-of
-kilter if you overwrite an old was-is file before doing the
back-annotation. Now you are free to make designator changes without the
risk of confusing the software - it can always find which component needs
to be changed in the other view of the design (PCB or Sch). That is if all
goes well.
I have seen similar confusion from the synchroniser before.
I wonder if this remapping problem that you are seeing (and I have seen)
could be because two components have the same handle? Maybe under some
copy and paste conditions this could happen? Speculation on the code only
- I have no reason to think this is what is happening.
I have fixed the problem by deleting the components and then manually
re-adding them - it should be OK to do this in just either the Sch or the
PCB but it may be safest to do it in both. It is a pain and should be
fixed or the condition detected and repaired automatically. Another option
would be that of allowing a user to call-up manually the component matching
dialog to allow the user to re-map handles manually. I would like this
function in rare situations. I have never had to do more than one or two
components so the overhead is not great but it would be nice if the problem
never appeared.
Brad - can you recall (exactly or at least close to) the sequence you did
to these components before you noticed the swapping?
Do we have any more information as to how this confusion of the
synchroniser occurs? Protel CSC can you comment please?
Ian Wilson
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
