At 08:40 PM 28/06/01 -0700, you wrote:
>At 10:24 AM 6/29/01 +1000, Michael Beavis wrote:
>> >... If update footprints is selected, it will
>> > also detect if any footprints have been changed. It will not necessarily
>> > give an *error* if the schematic is different; rather it will create a
>> > macro to implement the change. If there are no macros the schematic and
>> > board match.
>> >
>>
>>I would assume the libraries used by the original designer are still in
>>play.
>>Checking created macros for footprint updates shouldn't be a prob but if any
>>changes to the pcb are required how do you tell if you're still linked to
>>the correct library ? More of a problem if the designs span several Protel
>>format versions.
>
>Remember, the objective here is to test to see if the schematic and PCB
>are synchronized. Fixing any differences is a different task, and the
>synchronizer or netlist load processes are not up to it unless you know
>that the errors are on the PCB and that the available and enabled
>libraries are also correct. In the case before us, not only is that not
>known, it is unlikely.
Abdulrahman, you said the above in a (divergent thread from the sync status
question.
You do realise, don't you, that the synchroniser works both ways? I have
assumed but I realise now that maybe this is not well known. One advantage
of the synch going from PCB to Sch (using the Update Sch process), is that
it will show differences between the PCB and Sch footprints, and between
the Sch part type and the PCB comment, as well as show any discrepancy
between designators. If we assume that the original PCBs were created
using the synchroniser then it is even more relevant to use the Update Sch
process as one can catch multiple iterations of designator changes. If
Matthew beleives a particular sch is correct then he can evaluate the
macors created by Update PCB. If he believes that a PCB is more likely to
be correct he can evaluate thos macros created by Update Sch.
>That there is a deviation between the schematic and PCB in *footprint* is
>a class of error or incompleteness that one might wish to set aside in the
>subject case, or to consider as a detail. *Many* designers don't bother to
>back-update the footprints. It could be argued that we should, but in the
>absence of good library control, there is not a great motive; the process
>could still go awry.
But it is simple do to - using, again, the Update Sch process. I will
throw back at a designer a sch that does not show the correct footprints as
used on the PCB. Parts lists are prepared from Sch no PCB (by us at
least). Would you like to be responsible for an incorrect footprint being
purchased. I see no excuse for not synching completely the Sch and PCB
before initial release of the PCB.
>If one has an approved company library and all parts must come from it,
>then discovering deviations will be relatively easy, though, with current
>Protel, if the names match there is no easy way to proceed beyond that.
>One could play tricks to do it: rename all the parts in a library as
>FNAME_x (add a _x to the name). Hopefully none of them are long enough to
>run into the string length restriction on footprint names. Then likewise
>globally edit all the footprints in the schematic to add that extension.
>Then update a copy of the board from the schematic, allowing footprint
>corrections. If everything was done properly, all the footprints will be
>replaced but no errors will be created. But there are lots of ways for
>this to go wrong.
>
>For example, sometimes a designer will alter pad specifications once the
>footprint is on the PCB. One reason for this would be to reduce the count
>of differing hole sizes. (A more sophisticated footprint library, instead
>of having a simple hole size, would be like a design rule: minimum size,
>maximum size, preferred size. This could be used with a utility to
>automate hole count reduction once the board is finished.)
>
>Bottom line: if boards have been designed in an undisciplined environment,
>and have been fabbed and work properly, don't monkey with the assigned
>footprints unless you want to review the whole design. And using the
>present update tools would be too crude.
Why? They would show a discrepancy between Sch and PCB and this would be
valuable. Then Matthew would need to investigate why there is a
discrepancy and make a judgement on if and how to fix. The fix may simply
be a text file stored with the PCB and Sch pointing out that the
discrepancies exist - to warn future suckers.
>Instead, a partial check could be done by making a PCB project library,
>back-updating the footprint names to the schematic, and then using that
>library and the schematic to check assignments. This would detect, for
>example, that the schematic usage of, say, 0805 and 1206 packages was
>consistent with the PCB.
Nah... let the Update Sch macro report show any footprint discrepancies -
one can even save the report for detailed analysis.
>To be careful, I would suggest first examining the files without changing
>anything (or, as others noted, making backups, but remember not to make
>any changes you want to keep on copies that you are going to abandon!).
>Then any differences which turn up would be examined to determine where to go.
>
>[EMAIL PROTECTED]
>Abdulrahman Lomax
Yep - this last lot of advice seems sensible to me.
I assume since I seem to be going against most of what you have to say that
I have mis-understood the fundamental point you are making. In essence,
you seem to be saying that the synchroniser is not satisfactory for
Matthew's task. I disagree, I think the Update Sch process is possibly
going to be the easiest and quickest method of comparing Sch against PCB -
particularly if the original boards where created using the synchroniser
and so have the magical hidden handles allocated.
Bye for now,
Ian Wilson
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
