At 10:21 AM 12/9/2003, Bagotronix Tech Support wrote:
Imagine if you were the Protel computer program. The user would need to tell you in an unambiguous manner how these double pins were instantiated. If they are given the same name, how can you tell them apart?
Well, they will normally have different locations and possibly other characteristics (such as size). If you have two pads, part of the same footprint, with the same name and same location and size, ... you only have one pad and you have a possible problem with drill file operation....
In the examples under consideration, the pads will probably be identical except for location.
The only way is if you, the program, assigns every object a unique object identifier, which is known only internally to you, and not to the user.
Not true. The Protel ASCII database allows duplicate Pad primitives, and other kinds as well. There is no unique primitive identifier in the ASCII database, which would be why synchronization is lost by using the ASCII, a minor problem. However, identifiers are, I think, exported to spreadsheet.
Does Protel do this? We don't know, and since we don't have the source code, we cannot find out. Therefore, we must use our own unique identifier. In Protel, the tools available to us to do this are pin names and numbers. So, we should assign a unique identifier to each pin in the pin pair.
I'm afraid this is logical-sounding nonsense. We've been using double pads for a long time, and we have no difficulty with them beyond some anomalous behavior, quite predictable, of the program. But we don't need to know the difference between them, it does not matter to us if they are swapped (unless they are different shapes and sizes, in which case those characteristics also distinguish them). This is true as long as the program always assigns the same net to all pads with the same logical identifier (i.e., REFDES-PINNAME), with the exception of free pads and -- possibly -- pads with no name.
As to the old question of how Protel treats pads with the same name/number: we don't know for sure, and cannot find out.
I don't know why Mr. Bagget would say this. We can find out by experimenting, which is what we have been doing for a few years. It is clear that the Protel engineers were trying to fix the problem, but they simply didn't go far enough. The problems that exist are a result of making an assumption when programming that there are no duplicate pads. As a result, the first behavior was that the net was assigned to the first pad with the name and others were ignored.
They fixed that, and on netlist load, in 99SE, both pads were assigned the name. Presumably netlist load now checked for additional instances. However, this created a new problem, because they did not check reload behavior. On reload, the program presumably noted that there was an extra pin in the net, and it created a macro to remove it. Then, because a macro was created to remove net XX from AA-B, and the macro implementation routine was fixed to handle double pins, the net was removed from both pins. This problem was fixed with the synchronizer in 99SE, as I recall but netlist load still exhibited it.
But still they did not consider all the logical possibilities; most notably, what if one of the double pads has the net and the other does not? The DXP synchronizer thinks all is well, because, apparently, it fails to check for double pads. It finds a pad and net that match the schematic and it ignores the extra pad. It's really the same problem all over again. My guess is that this same problem exists in 99SE, I don't have time to check it today.
It is not a problem that will arise unless one monkeys with the net assignments, deliberately or accidentally. It's unlikely, and DRC will catch it if the pads have been wired together. That's why I recommend wiring together double pads in the footprint, if they are to carry a net. If they are to carry separate nets, *then* they need unique names.
And anything we assume is likely to become incorrect across versions. So it's best to use unique pin names/numbers.
No, I think that if we assume that footprint pads with the same name get the same net, we will find that the behavior will be consistent with that, and minor bugs will be fixed.
If implementing unique pin numbers is at all cumbersome (as with BNC connectors), intrinsically connected pads are better handled with a single pin on the schematic and multiple pads on the PCB.
If a part has internal connections, however, so that, say, an SOIC has multiple grounds, the pins already have, normally, unique names, and using unique names would be the norm. Even there, an argument could be made for using multiple same-name pads, say with the name GND. But this is shakier, to be sure: I'd only consider it if it made the schematic easier to read, and it would require a unique footprint, which is its own complication.
Examples where multiple same-name pads are useful: fuses, some kinds of connectors and battery holders. These all are represented by a standard schematic symbol, and there is no good reason to require a unique symbol for each variety of battery holder (while technically the inserted part is a holder, the schematic normally shows a battery....)
On the other hand, kelvin pick-off points for a sense resistor should have unique names, because one may wish to control the exact position of the pickoff (and a virtual short or similar device would be used to separate the nets and thus implement the control).
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *