A moderately long post - with a possible workaround at the very end.
On 03:00 PM 11/05/2001 -0700, Abd ul-Rahman Lomax said:
>At 02:35 PM 5/11/01 -0700, Brad Velander wrote:
>
>>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.
>
>Now, I have not checked this, and I very often don't use the synchronizer
>but rather net lists (though I'm moving more and more toward the
>synchronizer; ultimately it is a time-saver), but....
>
>Had you changed the schematics alone, everything would have been fine. The
>synchronizer would then have propagated that change to the PCB. But you
>changed the PCB also. So the change which schematic is requesting, through
>the synchronizer, undoes what you have done to the PCB.
Simply changing the sch designator and the PCB designator to match is not
the issue. The synchroniser, in my experience, simply confirms that the
PCB component matches the schematic component, if updating the PCB from the
sch and visa versa if updating the Sch from the PCB. I ran a test just now
to confirm this. The synchroniser does not *need* to change anything - it
simply checks that the components with the same handles match (designator,
footprint and comment).
The synchoniser is not a stored list of edits - it merely takes a snapshot
of how the two documents compare right now and creates macros to make the
target document match the source.
The preceding is true for components and assumes the synchoniser is bug
free. It gets a little more complex when nets are involved. But the
principle is the same.
I am interested in the comment "manually adjusted the netlists".
Brad, can you elaborate further on this?
Simply, moving nets about on a component should not cause the problem Brad
has seen. It is deeper than that - there is something that has broken the
link between the components (the handles).
I just did a whole batch of confused editing including swapping designators
on the PCB, exporting a netlist, changing components in the netlist about,
and changing the netlist connections and various other things a number of
times. On re-importing the netlist the synchoniser still correctly
identified the component it was originally linked to even though it had
changed designators without it knowing and changed position and changed net
connections. I have found the synchroniser quite robust but occasionally
it does get confused and I think this is what Brad has come across.
>>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.
>
>Maybe, maybe not. I remember something about hidden links; but the
>behavior reported does not require such a link. It is only necessary that
>schematic remember what a refdes was before it was changed. In fact, if
>there was a link, there would have been no problem, because the
>synchronizer, if it worked that way, would have recognised that the change
>it was requesting had already been made.
But the behavior reported *is* unusual when you consider how the
synchroniser works and that the hidden links do exist. There is no need
for a component to remember what it used to be. You can randomly change
anything on the component, multiple times without intervening updates, and
it maps though OK. For instance I just changed, on a sch, a
CAP|CAP_RAD16_5X7X9_3X15|100p, to become a RES1|0805|10k in one go on the
sch and updated the PCB without trouble. And then back again from the PCB
to the Sch (though it was not possible to change the Sch symbol from the
PCB as this is not an attribute of a PCB component).
I will restate - when using the synchroniser the component designator is
not special in any way once matching handles have been assigned. Component
matching from then on is done solely by the matching handles. The
component designator is only used by the synchroniser to *suggest* a
possible initial match based upon designators. You can override this
suggested match if you wish.
>How to fix this? I'll assume you have the original ddb with the files as
>you edited them. Because the memory may not be persistent through
>sessions, this may not work exactly as I state it; but I'll assume that it
>will work.
>
>Change the PCB back to what it was, then run the synchroniser, which will
>now change the reference designators to the correct value.
This will not necessarily fix the problem - remember the synchoniser is not
confused by multiple changes, there is no list of edits stored by system
(apart from the undo stack and the synchroniser does *not* use that) and
handles are stored with the saved document. (Components matched through
the synchroniser stay matched between sessions - even if they have
different designators - try it.) (A side note: handles may not be constant
across sessions but certainly the component matching is - Protel may create
new handles as document(s) load. I am not in any way privy to the
implementation details.)
>[EMAIL PROTECTED]
>Abdulrahman Lomax
>P.O. Box 690
>El Verano, CA 95433
Abdulrahman, in another post on this thread you asked for more information
on why I requested more details on the sequence of events. I hope I have
made my thoughts clear - or at least made clear that the problem is
possibly not as simple as you may have thought.
I believe the best solution will be to delete the components and start
again. I am very sure that a copy-and-pasted component does not copy the
hidden handle (a cut-and-pasted one may not as well) - I think the paste
operation for an entity does not copy the handle. So a solution may well
be as simple as cutting and re-pasting all the components causing problems
and then running the synchroniser again - you should be asked to match the
components that were pasted again. Everything should be happy again and the
cut-and-paste operation is quick.
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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
