. But, as I mentioned, Clear can wipe out some of your work if you > use any primitives with net assignments that are not explicitly connected > with positive copper to pads with that net.
Nah, Nah Abdul Clear will not wipe out any of your work. Load the netlist again, run connect copper, run drcs.
Mike, read what I wrote -- and you quoted -- again. Connect copper will not assign the net to the described primitives. What is it supposed to do, read your mind? Connect looks at copper primitives in contact with pads; if the pads are assigned a net, Connect will assign that net to them, and it does this recursively until all contacted primitives are assigned the net. Since there are kinds of primitives which may not be explicitly connected, but rather are connected through a plane -- which depends on net assignment -- these primitives, upon clear, will lose and not regain their net assignment.
Stitch vias and grounded mounting holes are two examples. You might place the mounting holes on the schematic and make them footprints -- I usually do -- but only a maniac would place stitch vias on a schematic. If a copper pour is connected to a plane with stitch vias only, well, see below.
The regular plane vias would also lose their assignments except that they are connected to component pads and so, with Connect, pick up the net assignment from them, plus Protel does not really clear out all net information; the names, and, apparently, the net assignments of inner planes remain, and these names are used to reassign the planes to the same net. Every wonder why the Stack Manager names the planes, at least by default as, for example, GND (GND). You can name the planes differently from the net which is assigned to them, however; and the plane still recovers its original net, so it must remain in the database (I haven't checked what happens if the file is saved and reloaded). Net-based rules created within PCB could also be a problem. They also seem to recover their nets if the net list is reloaded.
Remember the reported bug with copper pours, that there seemed to be some kind of memory of previously assigned nets? This might well be the source of that. In order to maintain the rules and plane assignments, it appears that Protel does retain some net information after Clear. This *might* allow poured copper to recover its net, I have not verified that.
But unattached primitives do not recover their nets. You could design around this by using free pads instead of vias and giving them the net name as a pad number, global edit would then restore them. Free copper, i.e., track, will never have a net assignment of its own if unconnected to a pad (or net-assigned via), so it is only free pads and vias which could be a problem here.
Further, the clear process is unnecessary. Clearing out the net assignments of pads is sufficient, i.e., (Global edit all pads to NoNet)/Load Netlist. The basic function of this process is to ensure that there are (1) no deleted components and (2) no oscillating assignments due to duplicate pad names. Other than that, we would not need to do any of this. If no macros are created, it is not necessary to reconnect copper, which, by the way, can be time-consuming with a complex board. It is not necessary because nothing has been changed!
These four steps will outperform the synchronizer 1000 out of 1000 times. at least in 99SE.
If you must load the net list, perhaps. There are a number of synchronizer settings, I have not seen nor verified the long synchronizer times, so I can't confirm the report, but neither can I deny it. But simply to confirm a design at the end, the synchronizer works fine; i.e., if no macros are created, no problem, the schematic matches the PCB. The synchronizer carries exactly the same information, as far as I know, as a netlist, it is merely that the netlist is not explicity written. It is much faster, going back and forth, so the following is more likely to reflect on Mr. Regan's unfamiliarity with the synchronizer, since he can't use it with customer-supplied netlists or netlists from other CAD systems.
I was a netlist maniac before discovering the synchronizer. I'm sorry, but in most circumstances, *if you are working with a Protel schematic*, the sychronizer substantially outperforms the netlist load process. Large designs *may* be an exception, but I think this is only for original load, if at all, not for resynchronization.
I also disagree with you the synchronizer works better for the following reasons: I use the netlist to trouble shooting errors, change footprints on the fly, find single nodes, we run utilities to find broken busses, find duplicate signals, broken nets, we run utilities to automatically ID pairs for paired routing so that we can extract a do file. I can also view gnds, Ana gnds , E gnds, etc and discuss gnd issues with my customers, if we both have a netlist. We even modify the netlist sometimes to make it connect to duplicate pins on BNCs, I have cut.pasted, and appended netlists. A netlist is very useful tool if nothing else. Like I mentioned it is the only port to third party tools.
Of course. If Protel eliminates net lists, it would be a disaster. I'd be astonished to find that DXP will not write and read netlists.
If they have eliminated the oscillation in DXP by refusing to assign nets to duplicate pads, or somehow prohibiting duplicate pads, that would be a shame and a loss, but that is a different problem, one they could fix rather easily if convinced to do so.
If you are using Protel Schematic to design with Protel PCB, I highly recommend using the synchronizer. If you must interface with another tool, then, by all means, write a netlist; but still, to reassign a footprint, for example, it is really easy to go to the schematic, change the footprint on the part, and Update PCB. You don't have to preview; the process is almost instantaneous with every file I've seen, I'd be astonished to find it cumbersome even with large files. I think, instead, that the problem Mr. Reagan has with complex PCBs, where he finds Netlist Load much faster than Update PCB (from Schematic) is with original load, not with a change like a footprint. And if you do it this way, the schematic is automatically fixed, it does not take that extra step.
(But I do, with small changes, tend to look at the preview, so that I know what the Synchronizer is doing.)
Just today, I had an EMI house require a specific breakdown of critical nets. I wont define critical here but you get the picture, I need a netlist to provide him the information. I cant provide this information on a system that is not netlist driven.
But Protel 99SE *is* netlist driven. The Synchronizer is a little more automated, that's all, and it conceals the netlist exchange. Frankly, I don't need to look at the netlist 99% of the time. Sure, there are times when I need to, and I can create one from Schematic or from PCB. I can even, as mentioned by others, compare them or other netlists, the comparison tool, as I recall, will deal with differing net names (i.e., purely formal errors).
The Synchronizer may be doing a bit of work creating the hidden links that make resynchronization fast, this might possibly explain long first-load times....
In any case, if you don't trust the Synchronizer, just write a netlist and load it at the end. The only macros you should see would be oscillating assignments, and that only if you have duplicated pins. (Or if you have deleted a part, there will be a macro recreating it. This would be caught and fixed by the synchronizer as well, though.) You don't need to accept and run the macros, in fact you shouldn't, because if there *are* oscillating net assignments, netlist load under these conditions will produce the incorrect assignments.
And if you must work from customer netlists or other non-Protel netlists, fine. You have the tools to do so. But the synchronizer was one of the major advances with 99SE, an improvement for perhaps 99% of all designs being done with Protel. And they didn't take away net lists; had they done so, I'd be squawking along with Mr. Reagan.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *