Re: [PEDA] Quickly checking sync status between PCB & schematic

[van de Werken, Matthew (DEM, PH)]

> -----Original Message-----
> From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 29 June 2001 4:59 PM
> To: Protel EDA Forum
> Subject: Re: [PEDA] Quickly checking sync status between PCB 
> & schematic
> 
> 
> At 03:58 PM 6/29/01 +1000, Ian Wilson wrote:
> 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.
> 
> Okay, here is an excuse: the designer does not necessarily 
> have control 
> over the schematic. This is not uncommon.

It's always true here, but I can see that it's not always the case.

> 
> In a consistent internal company environment, it is obviously 
> better that 
> schematics be reconciled completely with the PCB.
> 
> Another excuse is that the board must go out the door, and 
> the designer is 
> yanked to another project, but, with the synchronizer, this 
> is less and 
> less excusable.

This is all true, but it depends on the designer actually using the features
of the software rather than the export-import netlist because "I've always
done it that way and never had a problem" (the bit that doesn't get said
here is "...because you never have to clean up after yourself").

> 
> >>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.
> 
> Sure. By "monkeying" with the assigned footprints I mean 
> changing them 
> without being sure whether the PCB or schematic are more 
> correct. Making a 
> text file of deviations for future designers is certainly a 
> good idea. 
> Resolving all these deviations may be more trouble than it is 
> worth; it 
> depends....
> 

In my case, unfortuantely, all deviations should be reconciled at some
stage. For one, we fab straight from the pcb file (send a ddb to fab house,
they do gerbers etc), for another, we will always be needing to modify these
boards (it's a two-year project and nothing is in its final version).

> 
> >>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.
> 
> Problem is that if the schematic is massively unsynchronized 
> re footprints, 
> as easily happens with designers who make footprints and 
> place them on the 
> fly without going back through schematic, that macro report 
> will be so full 
> of changes that it will make little sense. By making a 
> project library, 
> which was the core of the suggestion, one at least has a 
> consistent set of 
> footprints that actually match what is on the board. The 
> basic assumption 
> here is that, since these boards were fabbed, they were good. 
> That is not 
> always true, of course. Then by taking that back to the 
> schematic, the 
> footprint fields in the schematic -- which are quite likely 
> to be incorrect 
> if left alone -- will be updated to reflect the PCB. BOM's from the 
> "before" and "after" schematics could then be compared. But I did not 
> express this correctly....

I hope I can automate this...

> 
> >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.
> 
> There is a high probability that the boards were *not* 
> created using the 
> Synchronizer....

This is probably true - most of the boards that have problems were not
created with the synchroniser...

> 
> Alternatives to the use of the Synchronizer were suggested because 
> sometimes the Synchronizer seems to take forever to come back with a 
> report. But let me repeat what I said at the very beginning 
> of my comment 
> in this thread. I do not know which process will be the fastest.
> 
> And getting 100 schematics cleaned up is going to be a big 
> task no matter 
> how you slice it. Yes, it would have been much better if they 
> had been 
> cleaned up immediately and everything rectified before the 
> boards when to fab.
> 

It's actually worse than that; the boards we do here are in a constant state
of flux. The only problem is that there are some who think it's ok to work
on the "current version" of a schematic - so the schematic might be newer
than the pcb, but will have no relation to what actually exists in hardware.
What actually exists in hardware sometimes doesn't have a schematic for it
*at all*. Very, very bad...

Cheers,
Matthew van de Werken
Electronics Engineer
CSIRO Exploration & Mining - Gravity Group
1 Technology Court - Pullenvale - Qld - 4069
ph:  (07) 3327 4685     fax:  (07) 3327 4455
email:  [EMAIL PROTECTED]
 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *