At 01:03 PM 1/2/2002 -0500, Bob Wolfe wrote:
>OK Here is the scenario, I ran through this today.
>Hopefully I have described it clearly enough.
I think Mr Wolfe has been quite clear here; I assume he will correct me if
I have misunderstood anything.
>I am running 99SE, SP6 on WIN98 Second Ed.
>Using the Database structure.
The "problem" he describes is generic to Protel. In fact, I find it
difficult to understand any other way that the program could operate.
>Create 3 footprints called KP1, KP2, & KP3 that could be used for this
>part in a library,
>Create a part for a contact pattern for a keypad in a library.
>Part named "KEY"
>In that part I have defined KP1, KP2 & KP3 as legal footprints for that
>KP1 the 1st on the list then KP2, then KP3.
This *could* mean that KP1 would be the default footprint, used if no
footprint were specified. Does it? We will see.
[... a moment of gratitude that I am now running with W2000, and I have two
monitors, which means I can work full-screen in Protel while I write mail
on the other monitor, and I have utterly no worries about running out of
resources. Frankly, if W2000 cost ten times as much as it does, I would pay
it to avoid going back to W98.... (W98 supports two monitors, but the
resource problems are serious.)]
>I create a new schematic put these parts on it and connect them up.
>Then I annotate.
>Then I run update PCB.
>Once in the board I see that the footprint that came out on the board
>is the first one on the list (KP1) in the part in the library.
When I do what Mr. Wolfe described, I get an error macro: Footprint not
found. This is because I did not assign a footprint to the part. The
library gave me three options, but I did not choose one of them, I merely
placed the part as it came from the library. The footprint field was empty.
However, if, during placement, I hit the TAB key and choose a footprint,
this footprint is automatically chosen for subsequent placements. Further,
subsequent placements also chose the first footprint for other parts. I am
testing this with a brand-new installation and there was apparently no
default setting for footprint. Protel Schematic remembers the last symbol
placed and presents it as a default for next placement, and this seems to
activate the choice of the first footprint for all subsequent placements,
even if the parts chosen are different. It's easy to see how a little
sloppiness in program initialization could lead to this phenomenon, which
Once Protel Schematic has been initialized by choosing a footprint during
placement, the first footprint in the list will be chosen by default. At
least this is what I saw. This is desired behavior.
>Later on at some point I need to change this footprint, I don't want the
>because it is physically different but I still want to keep the old
>even though I do not want it used for this part anymore.
>So I create the new footprint KP4 and edit the library for the part KEY
>to use only KP4 as a footprint, while both databases for board and library
You cannot edit the library to control footprint assignments. The library
only controls the list which is presented. Protel does not restrict you to
four footprints, you can use any footprint you like. Footprint assignments
are controlled from the schematic. Period.
Because the first footprint in the option list, which *is* from the
library, will be chosen by default (usually), it may seem that you are
controlling footprint from library, but you are really only controlling an
option list, and the first footprint in that option list will, for
convenience, is specially available for automatic choice. But this takes
place in schematic and the footprint can be unconditionally changed in the
schematic, what is in the library is *irrelevant.*
>While editing the part in library I select update schematic.
This will change the option list, nothing else.
>Save then go in to schematic, hit part properties and guess what the old
>is what is listed,
Yes. Exactly as expected. Changing a list of easy-choice options does not
change the actual footprint chosen. You might have a footprint which is not
on the list! This is, in fact, very common. One would not want to lose
footprint assignments because a user updated the part from library to
change some aspect of symbol appearance, pin electrical characteristics, or
>I can then select the arrow pulldown and see there is a choice for KP4 and
>once selected it now becomes the only choice for that part. But that means
>every unique part needs a global update, that's allot of needless work in my
Ahem... This only affects one single part, the one where the footprint
option list was edited. This can be globally implemented with one single
global edit. If you are going to your library and changing the footprint
option list for each unique part, yes, you will also need to do a global
edit for each unique part in schematic. (you could skip the library change
and just edit the schematics, since it is not necessary that a footprint be
in the option list, but if you want to make the new options available for
subsequent schematics, yes, you will have to edit your library.
There are two different processes here, and it is easy to confuse them.
(1) Setting a footprint option list.
(2) Choosing a footprint for a particular part.
Because the same symbol might be used for *many* different parts requiring
different footprints -- a PCB might have ten different kinds of
nonpolarized capacitors -- there is no direct connection between the option
list and the actual footprint chosen *except* that -- after some possible
initialization confusion as described above -- the first footprint in the
option list will be chosen by default.
This allows you, should you so desired, to set a different symbol for each
type of capacitor. In that case, one would have a single option for
footprint, and it would be routinely assigned. In the end, I suspect, this
is more or less what we will get when we get true library control.
For most of us, however, at this point, we are glad to have the flexibility.
>Problem here is each unique part needs to be touched separately and then
>to REALLY change the footprint. Other wise the old footprint will get put on
Yes. And this is not only the way Protel works, it is the way that it
*must* work. Each footprint that is to be changed must be changed once. The
only way to do less than this is to automatically change the footprint *and
quite often the user would prefer to leave them as previously assigned.*
If we had control of the footprint from the library (which means one
library symbol = one part, a huge step) then we would expect a library
update to update the footprints. But we don't have that control. Instead
the schematic is the command center.
Yes, "each unique part" needs to be touched separately. But if the parts
share any characteristic, such as all having the same reference designator
prefix, or the same original footprint, or anything else useable as a key
for a global edit, then only one edit need be performed. Usually this will
be the case. If not, then how would an automatic process decided what to
change and what to change it to?
If you have one symbol = one footprint, then a global edit keyed to the
symbol name will change all instances.
>And yes you could then change it in the board but why I already supposedly
>it in the schematic. Seems like allot of extra useless work.
No extra work is involved. Change it on the schematic and then update PCB.
I find it difficult to imagine a simpler way. If this is a revision of an
existing design, you will have some adjustments to make with tracks.
>In my opinion the update schematic function does not work properly, don't
>know whether Protel intends it to work this way or if it is a bug.
No bug has been described so far. The way it works is that one chooses or
enters a footprint in the schematic and this is carried to the PCB.
Alternatively, you can choose or change a footprint in PCB and carry it
back to the schematic. If you have done the latter, especially, your
footprints may bear little or no relationship to what is listed in the
library. And this is how it should be unless there is a very serious
library control system, something that we are not all eager to see.
I think it is a good idea in the long run, but there is a lot of work to
get from here to there.
>You might as well not have this update feature if it will not change this
>data in the schematic
>globally for you automatically.
It seems to me that there is some serious conceptual glitch here. Update
works exactly as I would want it to work. If Mr. Wolfe would want it to
work another way, what would he want? He has not described how he would
have update work. I suspect that if he takes the idea he has and reduces it
to a specific and clear process description, he would discover that he
would be creating more problems than he solved.
>Now for one or two parts this may not be that much extra work but if your
>library structure needs to change drastically this is a major issue.
>in a service bureau environment.
I work in a service bureau environment. For that very reason, I sometimes
make a client library, which contains all parts used for a particular
client. This can be done for schematic and PCB, and the make library
commands make it easy to create these libraries.
If you are changing all your footprints, yes, you must not only touch each
unique kind of part in your schematic, you must also *make a decision* with
regard to each one. This is why the process cannot be automated.
Ultimately, I predict, we will see a library part which is essentially a
manufacturer's part number. There will be a device for defining a series of
such part numbers as being equivalent. The complete part number will
include a manufacturer code, so the full part number will completely
specify the part for purchasing purposes. Then there will be families of
symbols and footprints assigned to each unique part. Yes, the part does not
change, presumably, but we may want to represent it on a schematic in more
than one way, and we may want to have wave-solder or reflow versions or
maximum density or best manufacturability versions.
It will be possible to edit a technology option that would, for example,
choose all the wave-solder footprints in one fell swoop. Another way to
look at this would be that what is now four options would become many
options, and the first set of these options would have defined names. So a
global edit could manage changing the technology for a whole design.
With *this* kind of a system, we will not be talking about choosing
footprints, except when we are just putzing around and want to put a
"resistor" on a board and not worry about where it comes from. It will be
made easy to do this, there will be generic parts.
There will be a web-accessible library that will contain *everything* one
needs in the way of library parts. We may, as users, help to build this
library; collectively, we can do a better job at lower cost than Altium
could manage on its own.
>Back to the part that calls out 3 footprints that can be used.
>"KEY" has all 3 footprints listed as legal footprints, and ALL 3 are in fact
>on a board.
Now, back to the schematic for a moment. Which ones should have been
changed to KP4 when the update from library was run? My answer is "None."
And that is how the program behaves.
>I go ahead and change the specific ones as needed to KP1, KP2 & KP3 in the
Yes, you can do that. Or you could change the ones you need to change on
the schematic and update PCB.
>Now I realize I have to make some changes to many other parts in the
>library at some point. Which would then logically say that I would want
>to update footprints next time I run the synchronizer on this board.
>However what happens is ALL of the parts on the board that are "KEY" change
>back to KP1, which was the 1st one on the list in the part in the library.
>This is not a good thing in my mind.
Sure, it is not a good thing. It is not a good thing to change footprints
on the PCB and then neglect to Update Schematic!
PCB: (Design/Update Schematic). This should change the footprints assigned
in schematic to those used on the PCB. (Note that the PCB must be
sychronized for this to work. I won't go into details on this at the
moment, but the summary is that one must have run Update in the other
direction. Turn off the footprint assignment options when doing this.) Once
this has been done, running the synchronizer will only change footprints
that have subsequently been changed in the schematic.
>One last statement, this all stems from my need & want to import an Orcad
>footprints names on the parts that I do not wish to use. Therefore I would
>thought the update schematic would have worked properly and forced the
>defined in my library to be placed on a new PCB.
Here is what I think Mr. Wolfe is expecting. He has a schematic imported
from OrCAD. The footprint assignments are next to useless.
He has created a project library from the schematic and wants to assign
proper footprints. He does this in the library, by adding them to the
option list. Then he wants these footprints to automatically show up in
schematic when he runs Update Schematic from library. As I think I have
shown, this behavior would create a huge mess with many designs which, I
think, would represent the majority of situations.
Now, what would serve the needs of Mr. Wolfe and many of us in similar
situations would be a small improvement to the Make Project Library
command. When a project library is created, the assigned footprints are
ignored. If there is an option list for a part (and there is no option
list, I am pretty sure, with imported symbols), that option list will be
used in making the library. But if one has merely assigned footprints to
the parts in the schematic, the symbol in the project library will be
without footprint options. If the project library creator were to examine
the schematic and look for assigned footprints, it could take at least the
first four it finds and stuff them into the footprint option fields. This
would accomplish what Mr. Wolfe desires, I expect.
He has been writing about double work. The double work is in creating a
matching library; most of us in his position simply do not create such a
library except piecemeal and perhaps we never put *any* footprints in it.
And then we have extra work that could be avoided.
Schematic has an ASCII database. It should be not too difficult, I'd think,
to write a program that would create footprint options from the used
footprints in a schematic. Once this is done, we could then make a project
library that would include the used options for footprints, making all
subsequent work for that client easier. I have written a simple schematic
as ascii and have appended it to this post. A part from a Protel standard
library called CON2 has been given four footprint options, as can be seen
in the library section at the beginning of the file. Later, this part has
been assigned a footprint of "0603". There is enough information here, in
fact, to write the utility, though one might want to experiment with a few
things. I'll do it if I have time. Perhaps I should have written "IF."
But it would certainly be useful.
>The PCB problem is less of an issue because I have just went ahead and made
>3 separate parts defining the 3 keypads so it will not rip them up when I
>update footprints during synchronization. But it still bugs me that the
>footprints do function as I would expect.
Once you have assigned the footprints in PCB, take them back to the
schematic with the Update Schematic function.
[begin schematic, the first line begins with "Protel":
Protel for Windows - Schematic Capture Ascii File Version 1.2 - 2.0
10 0 0 0 0 0 Times New Roman
10 90 0 0 0 0 Times New Roman
Rectangle 0 -30 20 0 0 128 11599871 0 1
Pin 0 0 4 0 1 0 20 0 -10 2 0 '1' '1'
Pin 0 0 4 0 1 0 20 0 -20 2 0 '2' '2'
Future 1 8 6
0 6 0 1 1 0 15269887 1 10 1 10 1000 800 0
PowerObject 2 150 260 1 128 0 'VCC'
Wire 1 8388608 0 3 150 260 150 220 170 220
Wire 1 8388608 0 2 170 230 150 230
Junction 150 230 0 128 0
Part 190 240 0 0 0 0 1 0 0 0 'CON2' '0402'
Designator 190 240 0 8388608 1 0 0 'J?'
PartType 190 200 0 8388608 1 0 0 'CON2'
PartDescription 190 190 0 8388608 1 0 1 '*'
PartDescription 190 180 0 8388608 1 0 1 '*'
PartDescription 190 170 0 8388608 1 0 1 '*'
PartDescription 190 160 0 8388608 1 0 1 '*'
PartDescription 190 150 0 8388608 1 0 1 '*'
PartDescription 190 140 0 8388608 1 0 1 '*'
PartDescription 190 130 0 8388608 1 0 1 '*'
PartDescription 190 120 0 8388608 1 0 1 '*'
SheetPartFileName 190 30 0 8388608 1 0 1 '*'
Part 210 290 0 0 0 0 1 0 0 0 'CON2' '0603'
Designator 210 290 0 8388608 1 0 0 'J?'
PartType 210 250 0 8388608 1 0 0 'CON2'
PartDescription 210 240 0 8388608 1 0 1 '*'
PartDescription 210 230 0 8388608 1 0 1 '*'
PartDescription 210 220 0 8388608 1 0 1 '*'
PartDescription 210 210 0 8388608 1 0 1 '*'
PartDescription 210 200 0 8388608 1 0 1 '*'
PartDescription 210 190 0 8388608 1 0 1 '*'
PartDescription 210 180 0 8388608 1 0 1 '*'
PartDescription 210 170 0 8388608 1 0 1 '*'
SheetPartFileName 210 80 0 8388608 1 0 1 '*'
Version 2.0 Sheet
Part 11599871 128 0 0 0
PartDescription 190 110 0 8388608 1 0 1 '*'
PartDescription 190 100 0 8388608 1 0 1 '*'
PartDescription 190 90 0 8388608 1 0 1 '*'
PartDescription 190 80 0 8388608 1 0 1 '*'
PartDescription 190 70 0 8388608 1 0 1 '*'
PartDescription 190 60 0 8388608 1 0 1 '*'
PartDescription 190 50 0 8388608 1 0 1 '*'
PartDescription 190 40 0 8388608 1 0 1 '*'
Part 11599871 128 0 0 0
PartDescription 210 160 0 8388608 1 0 1 '*'
PartDescription 210 150 0 8388608 1 0 1 '*'
PartDescription 210 140 0 8388608 1 0 1 '*'
PartDescription 210 130 0 8388608 1 0 1 '*'
PartDescription 210 120 0 8388608 1 0 1 '*'
PartDescription 210 110 0 8388608 1 0 1 '*'
PartDescription 210 100 0 8388608 1 0 1 '*'
PartDescription 210 90 0 8388608 1 0 1 '*'
Library Version 2.0
1 4 4 20 0
Version 3.0 Sheet
Easthampton, Massachusetts USA
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *